243937 - nsILocalFile.getRelativeDescriptor should be case-insensitive on windows

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Benjamin Smedberg]

Comment 1

[Benjamin Smedberg]

Attachment: use _wcsicmp

Comment 2

[Nicholas Allen]

Won't this break with case sensitive names on NTFS when someone tries to set
this descriptor?

Comment 3

[Darin Fisher]

nallen:

Are you saying that it's legal on NTFS to have two different directories, one
named "c:\foo\" and the other named "c:\Foo\" ??

It seems to me that if that were true, then a lot of Windows software would have
trouble making a proper distinction.

Even though NTFS preserves the case of file and directory names, doesn't it also
prevent two files (or directories) from being created that are case-insensitive
equivalent?  Or, maybe some higher level OS thing ensures this?

Comment 4

[Darin Fisher]

Comment on attachment 148744 [details] [diff] [review]
use _wcsicmp

r+sr=darin for the mechanics.  hold off on landing until we resolve the issue
raised by nallen.

Comment 5

[Nicholas Allen]

Yes, it's legal to have two file names differing only by case with NTFS.  Yes,
lots of Windows software has trouble with this.  See the quick overview at

http://support.microsoft.com/default.aspx?scid=kb;en-us;100625

Comment 6

[Darin Fisher]

Mozilla for Windows is a WIN32 application.

  "Even though NTFS and the POSIX subsystem each handle case-sensitivity well, 
   ... Win32-based applications do not."

  "In NTFS, you can create unique file names, stored in the same directory, that 
   differ only in case....  However, if you attempt to open one of these files 
   in a Win32 application, such as Notepad, you would only have access to one of 
   the files, regardless of the case of the filename you type in the Open File 
   dialog box."

Why does Mozilla need to handle file names any differently than Notepad?  The
Win32 convention is that file and directory names are case-insensitive.  There
doesn't seem to be any point in trying to make Mozilla solve a problem that the
rest of the applications on the system ignore.

Comment 7

[Nicholas Allen]

If no one is interested in supporting case sensitive names, then there's no
reason not to do this.  Maybe timeless has an interest but I don't particularly.

I was just bringing up the issue to inform people that there was a potential
problem.

Comment 8

[timeless]

Note that win32 apps can access the other files using CreateFile. I believe 
that notepad can actually open the alternate files even though it might not let 
you save to them.

Comment 9

[timeless]

oh well, poor notepad doesn't have access to the second one. yes i don't really 
like the patch as is. i'd much rather we cannonicalize in get and have a two 
pass process for set.

note that attachment 148744 [details] [diff] [review] does not help os/2 even though the problem applies 
even more so to os/2.

Comment 10

[timeless]

Attachment: draft of a better approach (requires MSL for U) - not for checkin

I think nspr uses a similar trick w/ findfirstfile

Comment 11

[timeless]

R:\mozilla\opt71-i686-pc-cygwin\dist\bin>xpcshell.exe

js> file=Components.classes["@mozilla.org/file/local;1"].createInstance( 
Components.interfaces.nsIFile)
[xpconnect wrapped nsIFile]
js> file instanceof Components.interfaces.nsILocalFile
true
js> file.initWithPath("c:\\DocUme~1\\usER\\Local SeTTings\\Temp\\MYFILE.txt")
js> file.getRelativeDescriptor(file.parent)
mYfiLe.txt
js> file.getRelativeDescriptor(file.parent.parent)
Temp/mYfiLe.txt
js> file.getRelativeDescriptor(file.parent.parent.parent)
Local SeTTings/Temp/mYfiLe.txt
js> file.getRelativeDescriptor(file.parent.parent.parent.parent)
user/Local SeTTings/Temp/mYfiLe.txt
js> file.getRelativeDescriptor(file.parent.parent.parent.parent.parent)
Documents and Settings/user/Local SeTTings/Temp/mYfiLe.txt

The advantage of something like this is that you can get friendly paths which 
are more likely to survive in the case the a ~1 becomes a ~2.

Yes, i really did name myfile with that funny caps. I'm not quite sure why 
Local Settings didn't get corrected (user really did).

Another reason *not* to use the code bsmedberg posted:
it breaks profile portability.

suppose you actually tried to share your windows profile w/ mozilla under linux.

now all your paths are lowercased even though the actual file paths are not. 
mozilla gets unhappy and ... oh well...

the converse also applies. for a path coming from unix, one would want the 
setter to be friendly and deal w/ the case where the directory name's case was 
corrupted (easiest example is all caps being coerced to lowercase by windows).

Comment 12

[Benjamin Smedberg]

Checked in on trunk.