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

[Richard Frith-Macdonald]

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 '~@server/directory/file.ext' and '@server' can be read as 'at 
server', which
should be quite clear.