Re: [j-devel] UNC paths?

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Wed, Sep 10, 2008 at 4:08 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
> On Wed, Sep 10, 2008 at 2:38 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
>> I don't have a UNC path to debug this with, but I'm getting a report
>> from someone that with-open-file doesn't work for non-existing files
>> (maybe also not with existing files, but that's hard to find out
>> without any :-) which reside on a UNC path like this
>> \\unc-server\share-name$\user\directory\filename.txt.
>>
>> Can someone confirm and maybe even help debugging?
>
> Reading the sources in Pathname.java I already found the problem: the
> code is plain UNC path incompatible. However, this raises an
> interesting issue: hosts in a logical-pathname are postfixed by a
> colon (":"). All of Pathnames.java seems to have been written with
> logical-pathnames in mind. Are there any other times we can expect
> hostnames in filenames, apart from the windows (UNC) case where hosts
> are part of the filename?
>
> If not, I'd like to change the meaning of hosts and devices in
> Pathnames (not being logical-pathnames):
>
> * On Windows:
>  A pathname with a Pathname as its device is a Jar file (existing behaviour)
>  A pathname with a String as its device is a pathname with drive
> specifier (existing behaviour)
> Now, if the hostname in the above cases is NIL (and it is), this new
> behaviour can be added:
>  A pathname with a hostname is a UNC path
>
> * On Unix:
>  A pathname with a Pathname as its device is a Jar file (existing behaviour)
>  A pathname with NIL host and device components is a pathname
>  Any other behaviour: unspecified

Well, it was both as easy as described as well as harder than it
looked: ofcourse there were other spots where the same assumptions
were used. Luckily all of them in Pathname.java.

So, to cut a long story short: I committed this to the repository (at
common-lisp.net). However, since it's under version control, nothing
is set in stone: if you think the idea is wrong: please speak up!

To address this remark by Ville:
"AFAIK only if you want to use KIOSLAVES (KDE) or GVFS/GIO (GNOME) on platforms
that support these libraries/virtual filesystems. There are ways
around that, such as
user tools that mount these ioslaves as normal paths, so I don't see
that as a stopgap issue.
"

Well, having looked at the specification of the KIOSLAVES "path"
specifications, I think they are modelled closer to URLs than to
paths. This probably means we should approach them as such (and not
try to squeeze them into pathnames).

Bye,

Erik.