Date: Tue, 1 Jan 2002 02:49:39 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Taylor <davidt@yadt.co.uk> Cc: <freebsd-current@FreeBSD.ORG>, <freebsd-fs@FreeBSD.ORG> Subject: Re: msdosfs_lookup returns EINVAL, not ENOENT Message-ID: <20020101021821.J6835-100000@gamplex.bde.org> In-Reply-To: <20011230161108.A76653@gattaca.yadt.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020101021821.J6835-100000>