From owner-freebsd-fs@FreeBSD.ORG Tue Feb 6 07:52:51 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 7C33616A403; Tue, 6 Feb 2007 07:52:51 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id DCAE813C474; Tue, 6 Feb 2007 07:52:50 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (cxinax@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l167qikS068392; Tue, 6 Feb 2007 08:52:49 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l167qhup068391; Tue, 6 Feb 2007 08:52:43 +0100 (CET) (envelope-from olli) Date: Tue, 6 Feb 2007 08:52:43 +0100 (CET) Message-Id: <200702060752.l167qhup068391@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, pluknet@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 06 Feb 2007 08:52:49 +0100 (CET) Cc: Subject: Re: incorrect(?) errno value in msdosfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, pluknet@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 07:52:51 -0000 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