> I checked the code for msdos fs, and the EINVAL error return on invalid
> filenames was introduced in the dentry changes. The original fs code was
> careful to map EINVAL to ENOENT on find and lookup operation, while
> keeping it EINVAL for create.
>
> The attached patch modifies the msdos hash and compare dentry operations
> to map EINVAL to ENOENT, which will restore the behavior on lookup/find
> operations. However, since the errors are detected at dentry-creation
> time, we can never actually create a dentry for an invalid filename, so
> an attempt to create an invalid filename will never make it as far as
> the msdos create code. If these changes have other side-effects, we may
> have to change the behavior again.
>
> The patch also incorporates some additional diagnostics for the fat and
> msdos code.
>
> Give it a test and let me know what you find ...
This patch works and now allows Unix tools to access MS-DOS file-systems
in a "compatible" manner.
Many thanks for a quick response.
Note to those who tried to help by explaining that "*" is not a valid
file-name under MS-DOS; The problem that I first observed was that a
NFS-mounted file-system, that contained a MS-DOS mounted file-system,
could no longer be properly backed up using `tar` from a server. I
isolated the problem to something that I could show with simple Unix
tools, i.e., `rm` and `ls`.
We need to return an error-code that such a configuration considers
"normal". Bill's new patch does this. I can now perform a complete
backup using the NFS mounted FS that contains a DOS FS.. so it fixes
the observed problem. There may be some bad side-effects somewhere, but
I have not seen any yet......
Cheers,
Dick Johnson
Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.1.70 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.