[armedbear-ticket] [armedbear] #340: DIRECTORY applied to symbolic links with non-existent targets returns errors

armedbear armedbear-devel at common-lisp.net
Fri Jan 10 11:10:38 UTC 2014


#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 at ...

 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


More information about the armedbear-ticket mailing list