Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)

From: Dan Muller (itd98ds02_at_sneakemail.com)
Date: 10/17/03 

Date: Thu, 16 Oct 2003 23:05:16 -0400

Thanks, this was a pretty informative reply...

In article <3F8F4CEE.B241E38C@setf.de>, james.anderson@setf.de says...
>
>
> Dan Muller wrote:
> >
> > In article <3F8F2F06.1FB5C1D2@setf.de>, james.anderson@setf.de says...
> > >
> parse namestring has a "standard" definition iff it is parsing a pathname with
> a known logical host. even then there are different opinions as to what this
> definition entails. despite which the variations are nominal enough to permit
> portable code.

I'm not so sure of that last point, at least not with the choice that
LW appears to make wrt treating the drive letter as a host name. The
host name has various special effects in the standard, such as having to
match a caller-supplied logical host, or being erroneous treated as a
logical host and causing unwanted translations to be attempted.

> if there is no logical host in the pathname namestring, i would predict
> nothing which i have not esablished by testing in the respective implementation.

Given the wording in the standard, I can see that. It's unfortunate that
implementations seem to vary this much on a single platform. That's why
I'm curious what other Win32 implementations do, since I've only seen
two so far.
 
> "reasonably"? asked rhetorically, as one cannot expect to roundtrip physical
> and logical pathnames. i do not know mk-defsystem internals, but i understand
> that it purports to be portable, and portability and parsing physical
> namestrings do not go together. should it be intending portable results from
> parsing physical namestrings it is a potential mk-defsystem bug. should it not
> be getting portable results from parsing a logical namestring it is an
> implementation bug.

I looked more carefully, and mk-defsystem does in fact create physical
namestrings from pathnames, then tries to turn them into pathnames
again. (compute-system-path forms the native namestring, and passes it
to append-directories, which tries to go back to logical pathnames.)
>
> note that logical pathnames cannot and were not intended to capture everything
> which any conceivable implementation might need to represent physical
> pathnames. information is lost in one direction and fabricated in the other.
> if one tries to go in a circle one is playing telephone.

Well, yes, anything's possible when a standard says "implementation-
dependent". But on platforms where there's no need for data loss, which
covers most of them (no doubt by design, since pathnames are pretty
information-rich compared to the simplest common file system models), it
certainly seems gratuitously surprising that a round-robin trip wouldn't
work.

>
> > Because LW
> > sees drive letters as logical pathnames, this fails.
>
> a view of the world with which, as i recall, it stands alone. thus my guesses above.
>
> > Perhaps if I set up
> > a translation for each valid drive letter ... yech.
> >
> > >
> > > > Assume that no logical
> > > > pathname translations have been specified by the user.
> > >
> > > that's like putting a bag over ones head and stepping out into traffic.
> > > why would one want to do that?
> >
> > Why do you say that? I'm interested here in how the implementations
> > handle the parsing of standard, native namestrings, not in how the
> > translation mechanism works.
>
> i say that because the phrase "standard, native namestrings" is a
> contradiction in terms. there is no such thing.

Ah, sorry, poor choice of word. "Standard" in this context meant
relative to the platform. Certainly, on Windows, there is a
specification of what UNCs and local pathnames look like and mean. But I
do get your point, that mapping the platform's meaning to the meaning of
the components in standard CL is unspecified. In fact, as my
understanding of this increases, my expectations of a good mapping have
changed. Originally, I assumed the host name in a UNC should map to a
host name component, but now I see that would likely be unwise. A UNC
would be better treated as containing no host or device components.

> > It's reasonable to expect (and even
> > necessary, if you're processing string coming from outside your program)
> > that they give a sane result for the platform they're implemented on.
>
> there may be reason to wish for, but i am not aware of a reason to expect this result.
> >
> > Just to be sure we're on the same page: I was talking about translations
> > specified via (setf (logical-pathname-translations host-name) '((wild-
> > from wild-to))).
>
> were i concerned with user/os origins for namestrings, i would consider the following
>
> - it makes no sense to specify logical pathname translations in terms of local
> pathname syntax, as the point of them is portability and local pathnames are
> not portable. i have been much more successful where i require either
> -- there to be enough of a local context defined in terms of logical pathnames
> outside of the immediate system, that all translation targets can be specified
> in terms of those logical hosts, or
> -- that a value such as *load-pathname* be relevant enough that one can rely
> on its values for the things like device and host as defaults and manipulate
> only values like directory, name, and type and only relative to those defaults.
>
> - use enough-namestring to extract those components which can be treated in a
> standard way across implementations - directory, name, type. in theory one
> should be able to extract them relative to a physical pathname and get
> consistent results. if with respect to directory one operates on the list for
> only and never attempts to use the string form, the chances of success are better.
>
> - in general, i would expect more predictable results from a user interface
> which constructed the pathnames from components, rather than from strings in
> the local physical syntax. in that case, it could construct logical pathnames directly.
>
> - the situation with pathname designators from os operations is different, in
> that some implementations endeavour to return logical pathnames were they can
> recognize the relevance of a known host, while others do not. for those
> implementations which do not, i would try to know the context of any return
> value and force the logical pathname abstraction in a wrapper function.
>
Thank you for this enlightening summary!

It seems like one might be best off not relying at all on the
implementation-specific parsing and creation of local namestrings, but
instead supplying one's own, which should not be too difficult in most
cases. This would give precise control over the mapping of native
concepts to logical components. At that point, though, it doesn't seem
like the logical hostname translation facilities of the standard are all
that useful any more; or perhaps I'm just not seeing how best to use
them yet.

Thanks, James.

Relevant Pages

  • Re: Logical pathnames on Windows (WAS: make-pathname in LW PE on Win32)
    ... > LW appears to make wrt treating the drive letter as a host name. ... >> that it purports to be portable, and portability and parsing physical ... >> namestrings do not go together. ... which tries to go back to logical pathnames.) ...
    (comp.lang.lisp)
  • Re: delete-file & probe-file on directories
    ... > Peter> And, in fact I think that current implementations mostly ... > Peter> the default host. ... > Just a note that in CMUCL, pathnames never have a NIL host ...
    (comp.lang.lisp)
  • Re: delete-file & probe-file on directories
    ... > Peter> And, in fact I think that current implementations mostly ... > Peter> the default host. ... > Just a note that in CMUCL, pathnames never have a NIL host ...
    (comp.lang.lisp)
  • Re: delete-file & probe-file on directories
    ... > "host colon" syntactic space to say that if there's a host name in the ... > PARSE-NAMESTRING's job is to parse a representation of a pathname + ... physical namestring, why shouldn't PARSE-NAMESTRING parse the string ... I didn't say that Unix-based implementations have no use for it. ...
    (comp.lang.lisp)
  • Re: Iterating through files in subdirectories in a directory
    ... and implementations' ... treatment of files, namestrings, wild pathnames, and truenames differ, ... This does give me all the subdirectories of C:/MyFolder/, ...
    (comp.lang.lisp)