From owner-freebsd-fs@FreeBSD.ORG Tue Feb 6 08:14:40 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14A2116A400 for ; Tue, 6 Feb 2007 08:14:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id A232713C481 for ; Tue, 6 Feb 2007 08:14:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so88236nfc for ; Tue, 06 Feb 2007 00:14:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rESWgtAU8T+ycPM+VLXDdmLzvJHjy8eOQkaZp7TO/NVoRXN5tsnSgxdJ7w8V0s1qxRaifzGW74yyu6twn6jHt7C9Dg3uyE5Gu5fVQOmGSw8yBsVr6Q0msntpasYKfdFHQuo623NhcfFOVK7nfoe4JGQ4z9WPRdjSOKBKfIU6dSI= Received: by 10.82.165.1 with SMTP id n1mr1837449bue.1170749677890; Tue, 06 Feb 2007 00:14:37 -0800 (PST) Received: by 10.49.27.4 with HTTP; Tue, 6 Feb 2007 00:14:37 -0800 (PST) Message-ID: Date: Tue, 6 Feb 2007 11:14:37 +0300 From: pluknet To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, pluknet@gmail.com In-Reply-To: <200702060752.l167qhup068391@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200702060752.l167qhup068391@lurza.secnetix.de> Cc: Subject: Re: incorrect(?) errno value in msdosfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 08:14:40 -0000 On 06/02/07, Oliver Fromme wrote: > pluknet wrote: > > I have discovered an unexpected behavior. If I perform a search > > operation in the directory for non-existing files, then I get > > the EINVAL value on msdosfs filesystem instead of > > the ENOENT value returned. > > EINVAL should be returned if you try to lookup an invalid > file name. ENOENT should be returned if the file name is > valid but does not exist. > > Remember that MSDOSFS is a lot stricter than UFS, as far > as valid file names are concerned. For example, the only > characters forbidden in UFS file names are '/' (slash) and > '\0' (zero byte), because slash is the directory separator > and zero byte is the string terminator. On the other hand, > quite a lot of characters are not allowed in MSDOSFS file > names, including the wildcards '?' and '*'. > > > For example if I run the next command on msdosfs filesystem, > > this is what I get: > > > > bash-2.05b$ ls /mnt/msdosfs/*.nonexistent > > ls: /mnt/msdosfs/*.nonexistent: Invalid argument > > That's correct behaviour. Let me explain: > > When your shell encounters unquoted wildcards ('*' in this > case), it retrieves a directory listing and tries to match > the entries with your pattern. If there is no match, the > default behaviour of most bourne-compatible shells > (including bash) is to use the pattern as-is, i.e. as if > it was quoted. In other words, it tries to look for a > literal file name of "*.nonexistent". > > As I explained above, the '*' character is illegal in > MSDOSFS file names, so the lookup function returns EINVAL > without even trying to locate that file name in the > directory. > > > instead of: > > > > bash-2.05b$ ls /mnt/msdosfs/*.nonexistent > > ls: /mnt/msdosfs/*.nonexistent: No such file or directory > > That would be incorrect behaviour. > > Try to look up a file name that's valid (but doesn't exist > either). You will certainly get ENOENT. If you still get > EINVAL, it's time to submit a PR. :-) > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 > Any opinions expressed in this message are personal to the author and may > not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "And believe me, as a C++ programmer, I don't hesitate to question > the decisions of language designers. After a decent amount of C++ > exposure, Python's flaws seem ridiculously small." -- Ville Vainio > Thanks for the explanation. I have forgotten about a not allowed wildcards :( wbr, pluknet