case sensitivity on Windows

[Mark Hammond]

> I'm guessing that the FindFiles api actually *does* have a way to give
> you the real name. Because it actually is doing a search, rather than
> just returning a single entry.
> 
> However, we run into this on Mac as well, and there isn't a win32 api
> there.

FWIW, Python's case_ok() function in import.c implements this check for most of the platforms we probably care about, but its not exposed in a usable manner.  http://svn.python.org/view/python/trunk/Python/import.c?view=markup

> There is a pretty well defined area in 'add' where we could do this
> sort
> of work, when we validate the user's arguments.
> 
> bzrlib/mutabletree.py around line 343:
> 
> # validate user file paths and convert all paths to tree
> # relative : it's cheaper to make a tree relative path an abspath
> # than to convert an abspath to tree relative.
> for filepath in file_list:
>     rf = _FastPath(self.relpath(filepath))
> 
> ^- If at that point, we could turn "filepath" into the real name on
> disk, we would prevent bogus data later.
> 
> On a side point, 'commit' also needs to be fixed, because it will probe
> for the state of "foo" and Windows is perfectly happy returning the
> information for "Foo" at that time.

ISTM that we might also need to guard against the case of a file being changed underneath bzr - eg, consider a dumb editor that decides it’s a good idea to use an all-lowercase version of the name (which could easily happen if the editor renames the old file before saving the new one with the adjusted name, for example).  OTOH, Python implements case sensitivity on Windows and it hasn't caused lots of bug reports about editors changing the case and breaking the module - but most are lowercase anyway...
 
What is the best way forward here?  test driven, so the first task would be to try and identify the semantics we desire?  Is there any hope of help from bzr dev's here, or is this something I would need to find the time for personally?

Thanks,

Mark