> Sorry to be the bearer of bad news, but as far as I know, NTFS allows for
> completely arbitrary equivalence tables (in Unicode).
ok, but this is a per-character thing, can be considered a 'feature'.
Also, this can be done lockless as well and doesnt change the length of
the name. (something like this is already handled by transname.c i think).
What is a killer is the '.' rule (depending on wether we are at the end of
the name or not, it's legal or not, and it's discarded, thus changing the
length+hash of the name). This is a rule stinging into the middle of Linux
lookup assumptions ;) If we could talk ourselves into ignoring this rule,
it would simplify things largely. The complexity of the 'alias patch'
comes mainly from this rule, not character aliases!.
so i think either we find a nice way to integrate 'different lookup rules'
into our lookup system seemlessly, or we go and solve only the largest
problem, the 'character alias' thing. [the character alias rule is a quite
simple variation of our lookup rules, can be integrated seemlessly]. And
forget about the ->dotsOK flag?
The first (harder) way would be nice, we could really accept 'hardcore'
names as well '/dos\temp\file.' Also, it would make the lookup system
flexible enough to accept new rules. NTFS has some really crazy
compatibility rules, i think the lookup rules are different for
_file lookup_ and _file creation_. Ie. you create two different filenames,
which are equivalent, then when you look the name up, you will get only
the first one. [the ntfs-linux list was talking about such a rule, i'm not
sure wether it's a real one]
from this standpoint, the 'easiest' solution is to pass unresolvable names
to the filesystems that are 'different from the Linux way'. Although there
are tricky things:
'/dos/temp/../TEMP/../../etc/PASSWD.'
a naive per-filesystem tranlator would change 'PASSWD.' to 'passwd', which
it shouldnt do, obviously. [coz say the attempt to read the password file
wont be logged because the logging logic sees 'PASSWD.' only].
Maybe a per-filesystem 'canonize next path component' function could be
used? This about what Alain's patch does ... ;)
-- mingo