#340: DIRECTORY applied to symbolic links with non-existent targets returns errors -------------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.3.0 Component: interpreter | Version: 1.3.0-dev Keywords: | -------------------------+----------------------- Alan Ruttenberg notes [http://article.gmane.org/gmane.lisp.armedbear.devel/3048]:
{{{ Emacs creates files like this: lrwxr-xr-x 1 alanr staff 30 Jan 6 01:40 .#foo.sql <at> -> alanr@...
as lock files, IIRC.
In such cases, the target of link names a file that doesn't exist. #'directory calls #'truename on the filenames that are listed, and truename does a probe file. Incidentally It looks like that is done in the java as well as the lisp function making the latter redundant.
It seems wrong that there is a situation in which one can't call directory at all without getting an error.
The crux of the matter is how to interpret the documentation of truename in the presence of symbolic links. The doc for truename says: If filespec is a pathname it represents the name used to open the file. This may be, but is not required to be, the actual name of the file."
"actual name of the file" suggests that there is a file, but also suggests that it is the name that is important. Also whereas directory allows implementation-dependent keywords, truename is not so defined.
I'll take the position that truename should *not* depend on the file existing, but rather focus on what names are present in directory structures. So resolve-truenames nil should should return the names in the directory and for resolve-truenames t it should follow symbolic links as long as they can be followed without hitting a name that doesn't designate an existing file. }}}
Note that followup comments by Alan and Marco to the behavior of SBCL and CCL, and the relation to the Hyperspec were not picked up in the Gmane archives.
-- Ticket URL: http://abcl.org/trac/ticket/340 armedbear http://abcl.org armedbear