On 8 Aug 2000, Bryan O'Sullivan wrote:
> k> Can you explain a bit more what those lines of code have to do? (I
> k> suspect I'm missing something obvious, but for whatever reason the
> k> simple answer is escaping me at the moment...)
>
> As far as NT and its filename-related APIs are concerned, "LEGOFLARK"
> is the same name as "legoflark". Thus, if you submit a change on
> client A that renames "LEGOFLARK" to "LegOfLark", you need to make
> sure, when client B gets the change, that you do whatever is required
> to make the name show up in the filesystem with the case changed.
> Otherwise, if client B tries to submit a change based on what is, as
> far as it's concerned, the same file (but with the old name), things
> will get weird.
>
> Does this clarify?
Danger Will Robinson!
I am very very leary of seeing any projects like this jump through hoops
to deal with the case-insensitivity and other issues associated with the
very very broken nature of Win32 filesystems. In the Apache project
we've had a tremendously difficult time trying to deal with naming issues
(for example, protecting resources by name using <Directory> at one
point could be worked around by changing the case in that directory path
in the URL, triggering a CERT warning), complicated the fact that *even
Microsoft* can't give us a safe algorithm to describe the conversion of a
path to a canonical form (we now suspect no such algorithm exists). If
you want to have fun, consider the implications of naming a file "COM" (I
think that was it, or some other magic reserved name that goes back to DOS
lineage).
If the brain damage necessary to support Win32 clients does not negatively
impact usage in a mixed case environment on Unix (consider the case where
both FOO and Foo exist in a directory) or overly complicate the source
code, if it can be contained to the Win32 client code, then that's
probably fine.
Brian
Received on Sat Oct 21 14:36:06 2006