"bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\*

[Mark Evenson]

John Pallister on #abcl reported problems with configuring ASDF via (asdf:initialize-source-registry '(:source-registry (:tree (:home "src/synchromesh")) :inherit-configuration)) for which he later traced down to problems with a pathname NAME containing a #\* character:

<synchromesh> Ooh, that's interesting - EXTENSIONS:PROBE-DIRECTORY has found a filename in the specified directory tree that contains a "*".
<synchromesh> Then (much deeper) org.armedbear.lisp.probe_file$pf_probe_directory.execute(probe_file.java:88) throws the error.   

The exact error cases here still needs to be determined.

TBD: What does it mean to PROBE-{DIRECTORY,FILE} on a PATHNAME containing #\*?

[Mark Evenson]

From discussion in #lisp, it seems that PROBE-FILE cannot accept pathname designators which contain wildcards, so the #\* character should be treated as a literal #\* in our PROBE-{FILE,DIRECTORY} implementations.

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Replying to mevenson:

From discussion in #lisp, it seems that PROBE-FILE cannot accept pathname designators which contain wildcards, so the #\* character should be treated as a literal #\* in our PROBE-{FILE,DIRECTORY} implementations.

The problem lies in that ABCL "overloads" the meaning of #\* characters in PATHNAME objects as both designating a wildcard for a string of zero or more characters, as well as a literal #\* object.

Surveying alisp, sbcl, and ccl reveal different strategies for dealing with this.

For alisp, #p"foo*" is not WILD-PATHNAME-P true.

sbcl replaces pathnames with wildcards with explicit objects

CL-USER> (describe #p"/tmp/foo*")
#P"/tmp/foo*"
  [structure-object]

Slots with :INSTANCE allocation:
  HOST       = #<SB-IMPL::UNIX-HOST {1000FDEC23}>
  DEVICE     = NIL
  DIRECTORY  = (:ABSOLUTE "tmp")
  NAME       = #<SB-IMPL::PATTERN "foo" :MULTI-CHAR-WILD>
  TYPE       = NIL
  VERSION    = :NEWEST
; No value

Lots of factors to consider here. Need to summarize issues more succinctly.

[Mark Evenson]

Directory entries with asterisk characters no longer cause errors. Ambiguities remain for what an asterisk character means for various parts of our CL:PATHNAME implementation

[Mark Evenson]

Apparently not addressed.

Recipe for failure.

1) Create a file with asterisk characters in a directory that ASDF will search

2) Attempt to load Quicklisp

CL-USER(1): (asdf:load-system :quicklisp-abcl)
#<THREAD "interpreter" {73C28A4A}>: Debugger invoked on condition of type FILE-ERROR
  Bad place for a wild pathname.
Restarts:
  0: RETRY                         Retry ASDF operation.
  1: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration.
  2: TOP-LEVEL                     Return to top level.

[1] CL-USER(3): :bt 50

  0: (SYSTEM:BACKTRACE)
  1: (INVOKE-DEBUGGER #<FILE-ERROR {7A02CBCD}>)
  2: org.armedbear.lisp.Lisp.error(Lisp.java:382)
  3: org.armedbear.lisp.probe_file$pf_probe_directory.execute(probe_file.java:88)
  4: org.armedbear.lisp.Symbol.execute(Symbol.java:803)
  5: org.armedbear.lisp.LispThread.execute(LispThread.java:814)
  6: org.armedbear.lisp.asdf_252.execute(asdf.lisp:2862)
  7: org.armedbear.lisp.Symbol.execute(Symbol.java:803)
  8: org.armedbear.lisp.LispThread.execute(LispThread.java:814)
  9: org.armedbear.lisp.asdf_254.execute(asdf.lisp:2862)
 10: org.armedbear.lisp.Symbol.execute(Symbol.java:838)
 11: org.armedbear.lisp.LispThread.execute(LispThread.java:872)
 12: org.armedbear.lisp.asdf_1611.execute(asdf.lisp:11614)
 13: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150)
 14: org.armedbear.lisp.Symbol.execute(Symbol.java:852)
 15: org.armedbear.lisp.LispThread.execute(LispThread.java:894)
 16: org.armedbear.lisp.asdf_1621.execute(asdf.lisp:11614)
 17: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:185)
 18: org.armedbear.lisp.Symbol.execute(Symbol.java:883)
 19: org.armedbear.lisp.LispThread.execute(LispThread.java:943)
 20: org.armedbear.lisp.asdf_1648.execute(asdf.lisp:11614)
 21: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98)
 22: org.armedbear.lisp.Symbol.execute(Symbol.java:803)
 23: org.armedbear.lisp.LispThread.execute(LispThread.java:814)
 24: org.armedbear.lisp.asdf_1650.execute(asdf.lisp:11614)
 25: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98)
 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803)
 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814)
 28: org.armedbear.lisp.asdf_1651.execute(asdf.lisp:11614)
 29: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89)
 30: org.armedbear.lisp.Symbol.execute(Symbol.java:793)
 31: org.armedbear.lisp.LispThread.execute(LispThread.java:798)
 32: org.armedbear.lisp.asdf_1652.execute(asdf.lisp:11614)
 33: org.armedbear.lisp.Symbol.execute(Symbol.java:803)
 34: org.armedbear.lisp.LispThread.execute(LispThread.java:814)
 35: org.armedbear.lisp.asdf_819.execute(asdf.lisp:7967)
 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814)
 37: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794)
 38: (PROBE-DIRECTORY #P"/Users/evenson/work/abcl/xx*xx")
 39: (UIOP/FILESYSTEM:SUBDIRECTORIES #P"/Users/evenson/work/abcl/")
 40: (UIOP/FILESYSTEM:COLLECT-SUB*DIRECTORIES

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Milestone renamed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Don Morrison notes in <​https://mailman.common-lisp.net/pipermail/armedbear-devel/2021-May/004197.html>

I don’t think I have the ability to comment on bugs in the issue tracker, or, if I do, I’ve not figured out how to do it. I hope sending mail to this list for the purpose is acceptable; apologies if not.

I note that #391 was opened six years ago, but remains unfixed, and, apart from apparently being pushed off from release to release, seems not to have received any love for four years.

I just wanted to add a note to it that it is still being encountered in the wild, and is, at least in one user’s case, causing some pain. File names containing asterisks may not be a good idea, but sometimes we have no control over the names of files we are given.

It also means at least one (uiop:subdirectories), and probably many, UIOP functions sometimes fail in what can appear to be mysterious ways on ABCL, but not other implementations.