[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Path separator in NSBrowser on MinGW
From: |
Richard Frith-Macdonald |
Subject: |
Re: Path separator in NSBrowser on MinGW |
Date: |
Sat, 4 May 2002 06:30:46 +0100 |
On Friday, May 3, 2002, at 11:23 PM, Fred Kiefer wrote:
Hi Richard,
great that you did start to resolve this issue. But I do have problems
to understand your new code. As far as I see, [NSFileManager
stringWithFileSystemRepresentation:length:] now replaces a MinGW path
of the form "c:\path" with "~c/path" which does not look sensible for
me. What happens is that when the file manager tries to revert the path
back to a windows path it finds ~ this is handled by [NSString
stringByStandardizingPath] by replacing it with the home directory.
That *shouldn't* be happening ... unless you have a user whose name is
'c' on your system. If it is,
there must be a bug in stringByStandardizingPath
The reason I mapped to ~drive is that doing so makes isAbsoluteString
work (since that considers a path
starting with ~ to be absolute) without causing problems with the path
component code management stuff.
Why dont we use "//c/path" instead?
Because various path manipulation methods are *supposed* to replace '//'
sequences ... so a path which
gets passed to something like stringByStandardizingPath would have
the '//' replaced for instance.
Or use the NT device name for the drive, e.g. //./c/path? (Ok, this
would lead to similar problems when stringByStandardizingPath
eliminates the "/./" part)
yes.
Or we add "/cygdrive/" even for mingw, this would save us from
inventing a private solution.
Currently I am not able even to run the defaults tool on Mingw, so we
have to urgently find a solution.
The MacOS-X documentation actually says you should add the drive letter
yourself! I think that's rather unfriendly,
and using the ~ notation is the only thing I could think of which
doesn't conflict with the MacOS-X specs.
I looked the the ~ expansion code ... and found a bug in
NSHomeDirectoryForUser() ... so it should work now.