Looking at case insensitivity - question

Paul Moore p.f.moore at gmail.com
Thu Apr 17 09:33:59 UTC 2008


On 16/04/2008, Mads Kiilerich <mads at kiilerich.com> wrote:
> I would avoid relying on a filesystem which is known to have strange
> semantics and "insanesitivity". Instead I would do something like this:

Speaking as a Windows user, and hence someone who relies on the
Windows filesystem all day for my work, I don't agree with you on
this.

[...]

Your proposal sounds pretty complex. As I don't agree with your basic
assumption (that the Windows filesystem behaviour is "strange" or
"insane") maybe I'm misunderstanding, but it sounds far more complex
than is needed, and seems to be based on the assumption that trying to
emulate the traditional Linux filesystem behaviour on Windows is the
correct approach.

> Some details or observations:
>
> Granted: Keeping track of what is filesystem names and what is internal
> names is hard.

I'm not sure it needs to be. Maybe it is now, as it appears that the
current functions mix things up (I have an outstanding question on the
-devel list, which no-one appears able to offer help on, about a
couple of low-level functions which seem to me to be clearly wrong).
But in theory it's reasonably easy (it can be done by code inspection,
it doesn't need runtime checks).

> Keeping the inverse mapping updated when files are removed or the working
> directory updated to new parents will be hard too.

This is hard, though. And that's why I believe your proposal is harder
to implement than mine.

> If the normalization function happens to not be defined for a name, then the
> file just can't be accessed in the working directory. And if two files
> normalizes to the same name, then the last one will win (or loose, depending
> on implementation). In both cases a warning should be given. But nothing
> prevents the normalization function from being extended by custom mappings
> specified by the user - or generated automatically (changes to the function
> will however be extra hard to track...)
>
> The functionality can also be used when developing cross-platform on unix,
> helping the developer to not introduce casing problems on other platforms.
>
> The functionality outlined can also be used to translate filenames between
> character encodings, similar to how a win32text-like extension could be (or
> has been?) written to translate file content between character encodings.
> This could perhaps replace the mbcs extension.

<head explodes> :-)

> IMHO ;-)

If you can offer code to implement any of this, I'll certainly take a
look. But if not, I doubt I'll implement things the way you suggest.

Paul.



More information about the Mercurial mailing list