Date: Tue, 6 Feb 2007 23:36:43 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: pluknet <pluknet@gmail.com> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: incorrect(?) errno value in msdosfs Message-ID: <20070206225814.R31484@besplex.bde.org> In-Reply-To: <a31046fc0702052220sc5d201aj143f45bcc9795173@mail.gmail.com> References: <a31046fc0702052220sc5d201aj143f45bcc9795173@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Feb 2007, 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. Actually I don't know what is > the right value should be returned and thus maybe I'm wrong > and I'm sorry for annoying. But It simply differs from the value > normally returned on ufs2 filesystem. So I decide to write here. :) > It is observed on 6.2 and CURRENT. > > 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 > > instead of: > > bash-2.05b$ ls /mnt/msdosfs/*.nonexistent > ls: /mnt/msdosfs/*.nonexistent: No such file or directory This is an annoying difference, but EINVAL is the correct error for msdosfs, since "*" is invalid in msdosfs file names. In general, msdosfs can't always handle things as expected since it can't represent all ffs metadata. Here if you did something like `touch "*.nonexistent"' where the file "*.nonexistent" doesn't exist, then msdosfs would refuse to create the file since "*" is invalid, and ffs would create a file named "*.nonexistent" which is probably not what you want. OTOH, `touch *.nonexistent' might match a file named existent.nonexistent and work right in both cases. > This behavior is fixed with the next workaround in v1.47, > but I guess that perhaps it needs to fix in some another place. Rev,1.46 is about an especially annoying variation of this problem: suppose a file named "Foo" exists. Then lookups and globs of the file by name "foo" and "f*" should succeed, but most parts of the system don't actually understand case insensitive file names so lookups and globs tend to fail. Lookups for open() work but require a full pathname. Rev.1.46 is about the name cache not understanding case insensitive file names (it disables a completely broken part, but I think the name cache can still be thrashed by asking it to cache all 2^N spellings of a file name of length N). fnmatch(3) has a case-insensitive flag, but it doesn't seem to be used by shells (maybe there is a shell option for this). The problem seemed to be just as large using bash under Cygwin under Windows. I have sometimes used the workaround of mounting with -s so that all file names get mapped to lower case and long file names get truncated. Perhaps there should be options to truncate to all lower case or all upper case without truncation. That moves the problem a bit -- after mapping to either case but differently under different OS's, after a while you get an annoying mixture of upper and lower case for new files. IIRC, I used the workaround mainly to reduce the case clobbering on restore from a backup made with different case conventions. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070206225814.R31484>