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.


$ ls foo* 
ls: foo*: Invalid argument

$ ls foo*
ls: foo*: No such file or directory

Using strace tracked this down to lstat of foo* returning EINVAL, which
would appear to be incorrect, as EINVAL is not listed as a possible error
for lstat.

Now, since I'm not familar with the innards of freebsd's fs code, here is
where I get a little bit lost.

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.

The call on line 152 of msdosfs_lookup.c appears to be the one causing the
current problem, but I'm not sure if simply replacing EINVAL with ENOENT
would affect things other than lstat.

However, I'm also not sure if the behaviour of the other two calls is correct.

OTOH, I'm not sure what syscalls are supposed to return in the case of an
invalid character in a filename.

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?

David Taylor
"The future just ain't what it used to be"

Attachment: msg33327/pgp00000.pgp
Description: PGP signature

Reply via email to