Well, I don't think we need to put _new_ functionality into dosfs ...
> Maybe a per-filesystem 'canonize next path component' function could be
> used? This about what Alain's patch does ... ;)
A path component canonicalizer would IMHO be the best thing. If it wasn't
for that hidden <-> prepended dot (which I never liked but eventually gave
up fighting :-( ) rule, all canonical names would either have the same
size or they'd shrink, so one could change them in place. Naturally, the
FS-specific functions would have to translate between the canonical and
the FS name. That would be quite close to Linus' proposal to require
applications to use canonical names only.
BTW, I think one important issue is to avoid breaking current applications
in subtle ways. Just imagine how much somebody who has been running a
system that occasionally stores files with names needing mangling on a FAT
FS for years, and needs to upgrade to 2.2 because some card died and the
driver for the new one is only in 2.2, will appreciate it if his turn-key
application all of a sudden fails mysteriously. Just think of those guys
who bury Linux systems somewhere in Antarctica :-)
I admit not having examined the current name handling, but from what I've
read in this thread so far, I guess a "fast" canonicalizer that allocates
memory on the stack or that uses some static area protected by the same
spinlock(s) as the dcache and then calls the real dcache function (with a
possible shortcut if the FS needs no translation) is the way to go ...
(I guess that's more or less what Alain's patch does ?) That should also
serve the people working on other file systems from the dark side well
enough, right ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_133__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/