Ticket #953 (reopened defect)

Opened 2 years ago

Last modified 18 months ago

Can't load from logical pathname when *default-pathname-defaults* is logical

Reported by: fare Owned by:
Priority: normal Milestone:
Component: Compiler Version: trunk
Keywords: ITA Cc:

Description

touch /tmp/x.asd
ccl
(setf (logical-pathname-translations "FOO")
  '(("**;*.asd.*" #P"/tmp/**/*.asd.*")))
(let ((*default-pathname-defaults* #P"FOO:"))
 (ccl::FIND-LOAD-FILE #P"FOO:x.asd.newest"))

==>

Error: Illegal logical namestring "/tmp/x.asd"
> While executing: CCL::STRING-TO-PATHNAME, in process listener(1).

The file has to exist, and the *default-pathname-defaults* has to be logical.

Actually, if the argument is "/tmp/x.asd" instead of "foo:x.asd", there is a different error:

> Error: Illegal logical namestring "/tmp/**/*.asd.*"

This makes thing fail in ASDF when using logical pathnames (I suspect since asdf 2.017.6, that binds *default-pathname-defaults* around the loading of the .asd).

Change History

comment:1 Changed 2 years ago by gb

Simpler ways of provoking the same error include:

(let ((*default-pathname-defaults* #P"FOO:")) ; [a]
  (pathname "/tmp/x.asd"))

and

(let ((*default-pathname-defaults* #P"FOO:")) ; [b]
  (merge-pathnames "/tmp/x.asd"))

Of 5 implementations that I looked at (CCL, SBCL, CLISP, LispWorks?, and Allegro), all but CLISP erred on [b]; CCL and SBCL erred on [a] as well. In all cases when an implementation signals an error, the error message is essentially the same as what you observe (a physical namestring isn't a valid logical namestring.)

It might make some sense to bind *DEFAULT-PATHNAME-DEFAULTS* to a pathname consisting of only a logical host around some body of code if you know exactly what pathname operations that body of code performs. You don't know exactly what pathname operations LOAD (or the code that's loaded) will perform.

The particular error that you get comes from something like [a], and I suppose that the call to PATHNAME in that case could be surrounded by a binding of *DEFAULT-PATHNAME-DEFAULTS* to #P"" to defend against an inappropriate surrounding binding. I'm not sure that I see a CCL bug here though, and I suspect that you'll find that binding that variable as you do will have lots of unintended interactions with the implementation and/or the user-level code being loaded.

comment:2 Changed 2 years ago by gb

(In [15330]) NATIVE-TO-PATHNAME: bind *DEFAULT-PATHNAME-DEFAULTS* to #P"", in case it's already bound to something questionable.

See ticket:953.

comment:3 Changed 2 years ago by gz

  • Keywords ITA added

comment:4 Changed 20 months ago by fare

Note that your solution, which I've also been trying to use, of binding d-p-d to #p"" will fail miserably if #p"" was itself read while d-p-d was "logical".

I don't know if this can possibly happen during a normal (re)compilation of CCL (hopefully not), but it can definitely happen during a compilation of some of the software for which I've been using this workaround.

It is surprisingly hard to *portably* get a non-logical pathname at all. My current bet is basically on (make-pathname :host nil), though I was suggested (translate-logical-pathname (user-homedir-pathname)), which unhappily isn't as portably supported as it should.

Ticket 978 is possibly related.

comment:5 Changed 20 months ago by fare

That's ticket:978

comment:6 Changed 18 months ago by gz

  • Status changed from new to closed
  • Resolution set to fixed

(In [15744]) Don't merge with *default-pathname-defaults* in native-translated-namestring. Fixes ticket:953

comment:7 Changed 18 months ago by gz

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:8 Changed 18 months ago by gz

I got the wrong ticket number. [15744] has nothing to do with this here, sorry.

Note: See TracTickets for help on using tickets.