On Wed, Jun 13, 2001 at 07:46:53PM +0100, Daniel Barlow wrote:
> :; cd /tmp
> :; mkdir sbcltest
> :; cd sbcltest/
> :; ln -s orphaned nonexistent
> :; ls -l
> total 0
> lrwxrwxrwx 1 dan dan 8 Jun 13 19:31 nonexistent -> orphaned
> :; sbcl
> This is SBCL 0.6.12.21, an implementation of ANSI Common Lisp.
> * (directory *default-pathname-defaults*)
> debugger invoked on condition of type SB-INT:SIMPLE-FILE-ERROR:
> The file "/tmp/sbcltest/nonexistent" does not exist.
> 0: [ABORT ] Reduce debugger level (leaving debugger).
> 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
> (TRUENAME "/tmp/sbcltest/nonexistent")
> This bug is present in 0.6.12.32 as well.
> So. DIRECTORY is supposed to return truenames. It is common for
> implementations to chase symlinks when resolving a truename, so we end
> up with a non-existent filename. The TRUENAME function is supposed to
> signal FILE-ERROR if the file does not exist. Problem.
> The reasonable solutions I can think of are (1) replace the call to
> (truename name) in DIRECTORY with (or (probe-file name) name), or (2)
> change TRUENAME to only follow symlinks as far as it can see them, and
> stop there. I don't think that breaks any invariants: people can't
> expect to do (and (truename p) (open p ... )) as it could be an
> unreadable file anyway.
> Anybody got any better ideas?
I'm not sure it's better, but how about (3) making DIRECTORY simply
skip dangling symlinks (and making an explicit call to TRUENAME on a
dangling symlink signal an error)? There seems to be nothing useful
(or at least nothing useful and unsurprising) that you can do with a
representing a dangling symlink in the Common Lisp world, so it might
be reasonable to ignore them.
The ANSI spec for DIRECTORY says
"Determines which, if any, files that are present in the file
system have names matching PATHSPEC, and returns a fresh list
of pathnames corresponding to the truenames of those files."
The ANSI spec for TRUENAME says
"An error of type FILE-ERROR is signaled if an appropriate file
cannot be located within the file system for the given filespec,
or if the file system cannot perform the requested operation."
As I see it:
* Solution (1) isn't good because it doesn't return the truename,
as required by the spec for DIRECTORY.
* Solution (2) would work, as far as I can see. I expect
users would find it a little surprising to have TRUENAME
return a dangling symlink, but since ANSI defines "file"
as "a named entry in a file system, having an
implementation-defined nature", it seems it should
certainly be allowed.
* Solution (3) would work too, taking the other side of the
"implementation-defined" freedom in the definition of "file"
to say in effect that dangling symlinks don't really exist.
I think this is slightly more convenient behavior than (2),
but it might also be more surprising. I don't think anyone
is likely to guess, at least without some fairly deep thought,
that DIRECTORY would silently skip over dangling symlinks.
On the other hand, no one is likely to guess that FILE-LENGTH
on a file will blow up with a weird error about it being
a dangling symlink. Also, as above, no one will guess that
TRUENAME on a dangling symlink will return the dangling
symlink. So maybe (2) and (3) are comparably surprising.
Another way of looking at the difference: Are dangling symlinks
Lisp files or not?
(2) Yes. TRUENAME and DIRECTORY can return them. But various other
file operations blow up on them more or less randomly (e.g. they
have authors and dates but not lengths).
(3) No. DIRECTORY skips them, and TRUENAME signals an error on
them. You can't do other file operations on them because they
don't have TRUENAMEs.
At this point I'm leaning toward (3), but there might be other issues
I'm overlooking, so I'll think about it for a while longer (and
William Harold Newman <william.newman@...>
pending patches from sbcl-devel:
null-*PRINT-LENGTH* bugfix from Alexey Dejneka (sbcl-devel
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C