From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-10 12:38:15
|
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? Thanks! Bye, Erik. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-10 14:08:47
|
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 How about this change? (Which is supposed to have *no* impact on logical-pathnames.) Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-09-10 14:17:06
|
On Wed, Sep 10, 2008 at 5:08 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > 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? 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. Btw, the little that I've looked at our pathname handling, it contains quite a bit of windows/unix conditional stuff that tries to determine if the file separator is a slash or a backslash. If I remember correctly, there's a java property that contains this info in a cross-platform manner, which should simplify code at least on the Java side. It would then be possible to export a symbol/variable to the lisp side for the same thing. Quick googling shows that I do remember correctly, see http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#pathSeparator and http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#pathSeparatorChar |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-10 20:12:38
|
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. |
From: Marco A. <ma...@cs...> - 2008-09-14 19:45:33
|
You may want to have a look at (shameless plug) http://common-lisp.net/project/names-and-paths As for Java you want to check File.pathSeparator File.pathSeparatorChar File.separator and File.separatorChar. Also, you can look at the 'file.separator' and 'path.separator' properties (cfr. the System.getProperty(String) method). Cheers -- Marco On Sep 10, 2008, at 22:12 , XXXXXXXXXXXXXX wrote: > 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. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- Marco Antoniotti |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-14 20:10:58
|
On Sun, Sep 14, 2008 at 9:23 PM, Marco Antoniotti <ma...@cs...> wrote: > You may want to have a look at (shameless plug) > > http://common-lisp.net/project/names-and-paths Interesting read. Actually, this is mostly how I solved it, except for the "platform specifier" part. I have an interesting use case however: ABCL allows pathnames to be nested: A pathname can point to an entry in a JAR file. In that case, the device - i believe - is a pathname itself, pointing to the JAR, the directory, name and extension all refer to a directory entry within the JAR. This could be a nice extention to your specification. One question: Am I correct to assume that a UNC path would look like this: MS-WINDOWS|\\server\share$\directory\file.ext ? Nice idea! > > As for Java you want to check File.pathSeparator > File.pathSeparatorChar File.separator and File.separatorChar. Also, > you can look at the 'file.separator' and 'path.separator' properties > (cfr. the System.getProperty(String) method). Thanks! I've implemented UNC paths now, except that they're not a different class from any of the other classes. I guess having different classes isn't disallowed by the spec, as long as the basic specification still applies (pathname-p, pathname-host, etc). Bye, Erik - who now ponders rewriting pathname and logicalpathname support in ABCL, but not today. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-15 13:16:40
|
On Sun, Sep 14, 2008 at 10:11 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Sun, Sep 14, 2008 at 9:23 PM, Marco Antoniotti <ma...@cs...> wrote: >> You may want to have a look at (shameless plug) >> >> http://common-lisp.net/project/names-and-paths > > Interesting read. Actually, this is mostly how I solved it, except for > the "platform specifier" part. I have an interesting use case however: > ABCL allows pathnames to be nested: A pathname can point to an entry > in a JAR file. In that case, the device - i believe - is a pathname > itself, pointing to the JAR, the directory, name and extension all > refer to a directory entry within the JAR. > > This could be a nice extention to your specification. An additional remark/question: have you considered making it a CDR (cdr.eurolisp.org)? Bye, Erik. |
From: Marco A. <ma...@cs...> - 2008-09-17 22:34:28
|
On Sep 15, 2008, at 15:16 , XXXXXXXXXXXXXX wrote: > On Sun, Sep 14, 2008 at 10:11 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > wrote: >> On Sun, Sep 14, 2008 at 9:23 PM, Marco Antoniotti >> <ma...@cs...> wrote: >>> You may want to have a look at (shameless plug) >>> >>> http://common-lisp.net/project/names-and-paths >> >> Interesting read. Actually, this is mostly how I solved it, except >> for >> the "platform specifier" part. I have an interesting use case >> however: >> ABCL allows pathnames to be nested: A pathname can point to an entry >> in a JAR file. In that case, the device - i believe - is a pathname >> itself, pointing to the JAR, the directory, name and extension all >> refer to a directory entry within the JAR. >> >> This could be a nice extention to your specification. Yes. This may be an interesting addition. But things would get quite hairy. Moreover, JAR files always sort of imply a "relative" naming scheme. > > An additional remark/question: have you considered making it a CDR > (cdr.eurolisp.org)? > Yes. But the code (and the HTML in particular) in in a state of flux now and I don't have the time to polish it. I am looking for helpers. Cheers -- Marco |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-10-05 08:33:49
|
On Wed, Sep 17, 2008 at 11:47 PM, Marco Antoniotti <ma...@cs...> wrote: > > On Sep 15, 2008, at 15:16 , XXXXXXXXXXXXXX wrote: > >> On Sun, Sep 14, 2008 at 10:11 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >>> >>> On Sun, Sep 14, 2008 at 9:23 PM, Marco Antoniotti <ma...@cs...> >>> wrote: >>>> >>>> You may want to have a look at (shameless plug) >>>> >>>> http://common-lisp.net/project/names-and-paths >>> >>> Interesting read. Actually, this is mostly how I solved it, except for >>> the "platform specifier" part. I have an interesting use case however: >>> ABCL allows pathnames to be nested: A pathname can point to an entry >>> in a JAR file. In that case, the device - i believe - is a pathname >>> itself, pointing to the JAR, the directory, name and extension all >>> refer to a directory entry within the JAR. >>> >>> This could be a nice extention to your specification. > > Yes. This may be an interesting addition. But things would get quite > hairy. Moreover, JAR files always sort of imply a "relative" naming scheme. I've given this some thought, but if the jar file itself is considered a device, then I don't see much of a difference between a path in a jar file and a path in - say - Windows C:. There's one major difference: the fact that you can make Windows C: paths the 'current' path. However, from the point of a developer using Lisp, this fact can be easily hidden: the *default-pathname-defaults* could easily point into a jar file... Am I missing a detail you *have* thought about? >> An additional remark/question: have you considered making it a CDR >> (cdr.eurolisp.org)? >> > > Yes. But the code (and the HTML in particular) in in a state of flux now > and I don't have the time to polish it. I am looking for helpers. I haven't looked at the code. Is it built on top of existing path functionality? Or is it a replacement to be incorporated by implementors? Or is it a prototype implementation to be used for testing? How much code is it? Would it be easy to complete? If it is, how hard would it be to create a CDR for it? Bye, Erik. |