[Openmcl-devel] Using :up in logical pathnames

[Gary Byers]

I have to confess that I can only think about CL pathnames for a few
minutes before getting a bad headache, so take this with a grain of
salt.

It seems clear that a directory component of

(:absolute :up)

is meaningless.  In Unix filesystems, that'd probably translate into a
reference to the parent of "/", which doesn't/can't exist.

It is less clear to me what an :ABSOLUTE directory component of a
logical pathname means and even less clear what it means for such a
component to contain :UP.  (:UP is supposed to be "semantic", e.g.,
"the parent directory in the filesystem" and it therefore can only be
resolved in terms of a concrete filesystem.)

We -could- process (:ABSOLUTE :UP) when dealing with a physical
pathname by asking the filesystem for the parent directory of the
filesystem root (and signalling a FILE-ERROR when the filesystem
tells us that that directory doesn't exist.)  (It's probably cheaper
to just recognize when the CADR or a directory component whose CAR
is :ABSOLUTE is :UP or :BACK, but the rationale for the complaint
would be the same in either case.)

It's also clear that (:ABSOLUTE "usr" :UP :UP) is bogus, but
it can be harder to detect this sort of thing syntactically.
(Whether (:ABSOLUTE "foo" :UP :UP) is valid or not depends on
whether "foo" is a link and on what it resolves to if so.)

If :UP is allowed in the directory component of a logical pathname
(and I don't see anything that prohibits its use there), it clearly
doesn't mean the same thing pre-translation as it would mean post-
translation.  (pre-translation, we don't have the option of asking
the filesystem to resolve :UP for us, since the untranslated logical
pathname doesn't likely map to a filesystem location.

If a logical pathname translates into a physical pathname with
a directory component of (:ABSOLITE :UP), then we should signal
an error.  I'm not sure if there's a compelling reason for doing
so in the case of a logical pathname whose directory component
starts with/is (:ABSOLUTE :UP) aside from the fact that 19.2.2.4.3 -
which discusses the syntax of pathname directory components - says
that this case should signal a FILE-ERROR.

Unless I can think of some reason for restricting things, I'm fine
with preserving the status quo (and possibly, pedantically, continuing
to violate 19.2.2.4.3.)

(There's a separate/related issue: I'm not sure if OpenMCL's pathname
code always fully appreciates the distinction between :UP and :BACK.)


On Sat, 6 Jan 2007, Andrew Shalit wrote:

> Should OpenMCL allow you to create logical pathnames that have (:ABSOLUTE :UP) as their directory component?
>
> Sometimes it does:
>
>
> ? (translate-logical-pathname #p"ccl:foo.lisp")
> #P"/Users/alms/openmcl/ccl/foo.lisp"
>
> ? (translate-logical-pathname #p"ccl:..;foo.lisp")
> #P"/Users/alms/openmcl/foo.lisp"
>
> ? (ccl::%pathname-directory #p"ccl:..;foo.lisp")
> (:ABSOLUTE :UP)
>
>
> But sometimes it doesn't:
>
>
> ? (setf (logical-pathname-translations "home")
>      '((#P"home:**;*.*" #P"ccl:..;**;*.*")))
> ((#P"home:**;*.*" #P"ccl:..;**;*.*"))
>
> ? (translate-logical-pathname "home:foo.lisp")
>  ==>> Error: Second element of absolute directory component in #P"ccl:..;foo.lisp" is :UP
>
> and:
>
> ? (make-pathname :host "ccl" :directory '(:absolute ".."))
>  ==>> Error Second element of absolute directory component in #P"ccl:..;" is :UP
>
>
> Allowing (:ABSOLUTE :UP) seems to violate the CL standard, but it's also pretty clearly useful when the host is logical.
>
> BTW, it appears to be easy enough to make the error go away by conditionalizing the error-check in make-pathname with a call to ccl::logical-host-p. (Although there may be other places that assume this can't happen.)
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>