gnustep-dev
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]