From owner-freebsd-current Mon Dec 31 7:50: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 650A837B42C; Mon, 31 Dec 2001 07:49:59 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA04467; Tue, 1 Jan 2002 02:49:49 +1100 Date: Tue, 1 Jan 2002 02:49:39 +1100 (EST) From: Bruce Evans X-X-Sender: To: David Taylor Cc: , Subject: Re: msdosfs_lookup returns EINVAL, not ENOENT In-Reply-To: <20011230161108.A76653@gattaca.yadt.co.uk> Message-ID: <20020101021821.J6835-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 30 Dec 2001, David Taylor wrote: > Whilst poking around on my msdosfs (trying to find an MP3 I thought I had), > I discovered that, if there are no files matching "foo*", ls foo* will > return the wrong error. > > msdosfs: > > $ ls foo* > ls: foo*: Invalid argument > ... > I _think_ I've tracked down the source of the error to the point where > unix2dosfn is called in msdosfs_lookup, which would be expected, since '*' > is an invalid character in msdos filenames, but is fine for ufs. This is the correct diagnosis. > OTOH, I'm not sure what syscalls are supposed to return in the case of an > invalid character in a filename. Me too :-). > e.g. touch foo\\ fails with EINVAL currently, yet open(2) states EINVAL > means you have used an invalid combination of O_RDONLY, O_WRONLY, and > O_RDWR. But no error is listed in the manpage for an invalid filename, > other than ENAMETOOLONG, which is clearly inappropriate. > > Perhaps the correct fix would just be to document the use of EINVAL? I slightly prefer this, but it would have to be limited to non-POSIX filesystems (there are no invalid characters for POSIX filenames except '\0', and '\0' is not really part of a filename; the POSIX error for the completely invalid filename "" is ENOENT). I just remembered some history: most of the manpages for syscalls that deal with pathames used to document setting errno to EINVAL if "The pathname contains a character with the high-order bit set". They did this long after the syscalls stopped actually doing this (e.g., in 4.4BSD-Lite). I find msdosfs's handling of attributes that have no meaning for msdosfs much more inconvenient than this. E.g., "cp -p" usually fails to preserve ownerships (because msdosfs's fake ownerships are usually different), and it fails to preserves file mtimes unless run by root (because utimes()'s permissions checks depend on ownwerships in a slightly different way than creat()'s permissions checks). OTOH, failure to set nonexistent file atimes and ctimes are silently ignored. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message