Richard M Kreuter wrote:
Gary King writes:
OK, I /have/ misdiagnosed this. The logic seems actually busted in directory-pathname-p. The problem is that, at least on allegro, you can get a valid directory pathname whose name component is neither NIL, nor :unspecific, but "" (the empty string).
Ugh,
(member (pathname-name pathname) (list nil "" :unspecific) :test 'equal)
A source of the problem are pathnames that arise from things like this:
> (make-pathname :name "" :directory '(:absolute "tmp")) #p"/tmp/" > (pathname-name *) ""Added a call to namestring seems to be another way to canonical things so I think this will also work and feels (to me) a bit more portable:
(defun directory-pathname-p (pathname) (let ((pathname (namestring pathname))) (and (member (pathname-name pathname) (list nil :unspecific)) (member (pathname-type pathname) (list nil :unspecific)))))
I see two problems:
(1) If the the host component of *DEFAULT-PATHNAME-DEFAULTS* is different than the host component of PATHNAME, the parse might fail or come out wrong.
(2) Pathnames with "" for the name component don't have namestrings under SBCL. (IIUC, the intent there is to try to have namestring parsing and unparsing be non-lossy.)
I think it might do just as well to say that "" for the name counts the same as NIL or :UNSPECIFIC for DIRECTORY-PATHNAME-P, unless somebody knows of implementations that don't work that way.
The problem with this is that it is open to the kind of attacks that Andreas and Zach propose. Note that those already break the existing directory-pathname-p assumption that one can check the name and type components separately....
[I am pleased to reveal that ACL, at least, throws away name fields of "."... Haven't checked SBCL, nor have I yet checked to see if these are acceptable name components.]