Re: incorrect(?) errno value in msdosfs

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