discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug handling UNC pathes on windows in NSString.m/NSFileManager.m


From: Richard Frith-Macdonald
Subject: Re: Bug handling UNC pathes on windows in NSString.m/NSFileManager.m
Date: Mon, 21 Jul 2003 14:17:51 +0100


On Monday, July 21, 2003, at 01:38 PM, Roland Schwingel wrote:

Hi...

There is a bug in gnustep-base of not being able to deal with UNC pathes correctly on windows.

Since a while all pathes are converted to an internal format, this applies especially for windows pathes. But the functions in NSString/NSFileManager dealing with this are having problems with direct UNC pathes...

So imagine a path  \\server\share\some\more\pathcomponents
Currently this is transformed to /server/share/some/more/pathcomponents if it is transformed back again it gets converted to \server\share\some\more\pathcomponents. Missing an initial backslash and nothing works anymore on windows.

My applied patch fixes this in NSString.m and NSFileManger.m by leaving an additional / in front of the internal representation.

That won't work ... having an initial '//' in the internal representation is just wrong and would screw up lots of code ... because the slash character is the path separator and any application splitting the path into components and reassembling it would
get confused.

I think that what is needed is some improved way of mapping UNC paths to/from
workable internal names.

I've tried adding a new convention for UNC paths ... the '//' is held internally as '~@' This matches the existing convention for drive letters ('C:' maps to '~C') and is also (I hope) readable with respect to network drives .... as '//server/directory/file.ext' maps to 'address@hidden/directory/file.ext' and '@server' can be read as 'at server', which
should be quite clear.





reply via email to

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