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 ufs: $ 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 [EMAIL PROTECTED] "The future just ain't what it used to be"
msg33327/pgp00000.pgp
Description: PGP signature
