<div dir="ltr">Thanks Mark!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 9:14 AM, Mark Evenson <span dir="ltr"><<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Jan 10, 2014, at 15:51, Alan Ruttenberg <<a href="mailto:alanruttenberg@gmail.com">alanruttenberg@gmail.com</a>> wrote:<br>
<br>
> There are, I would offer, several arguments suggesting that the<br>
> current behavior should not be the default.<br>
><br>
> 1) Exceptions: Generally, listing the contents of a directory is not<br>
> considered an exception unless the directory structure is corrupted.<br>
> In some cases (e.g. unix "rm") you can't even do anything to the<br>
> target of the link. So ABCL signals an exception when most would not<br>
> expect it. Consider the case where the link points to a file on a<br>
> device that may or not be mounted. If the device is taken offline,<br>
> nothing in the directory changes, and yet the behavior does. It seems<br>
> that this situation is more properly handled by an exception when<br>
> opening the file.<br>
><br>
> The doc for truename says, about conditions: "An error of type<br>
> file-error is signaled if an appropriate file cannot be located within<br>
> the file system for the given file spec or if the file system cannot<br>
> perform the requested operation.". Whether or not the symbolic link is<br>
> a file or not. Certainly for some cases it is, for example when<br>
> handled by archiving or certain version control systems, or in the<br>
> cases I list in (4). In the case of "rm", the answer is yes, it is a<br>
> file, implicit from the documentation: "The rm utility attempts to<br>
> remove the non-directory type files specified on the command line.<br>
> [...] The rm utility removes symbolic links, not the files referenced<br>
> by the links. In ABCL, (directory "/") -> (#P"/"). This means that a)<br>
> ABCL is inconsistent in that it sometimes returns truenames for things<br>
> that can not be "opened" or b) ABCL admits that there can be truenames<br>
> for entities other than files, which makes it's treatment of symbolic<br>
> links inconsistent.<br>
><br>
> 2) Pragmatism: With the current default, the only possible<br>
> programmatic repair in the common case that you don't care about these<br>
> entries - for example if you are looking for a file whose name matches<br>
> a pattern not expressible using the directory wild card expressivity -<br>
> is to use an implementation-specific keyword. CCL's implementation<br>
> also has this property, which I also consider to be a fail. In<br>
> practical terms this means that the unsuspecting programmer must wrap<br>
> all calls to directory with a catch and have the handler respond in an<br>
> implementation-specific way. It is much more common to protect<br>
> accesses to a file than accesses to a directory.<br>
><br>
> 3) Truth in advertising:  The exception happens independent of the<br>
> value of the :resolve-symlinks keyword. If the function is told not to<br>
> resolve symlinks, one would expect it doesn't resolve symlinks. Yet it<br>
> does, since that's the only way that it could figure out that the<br>
> "file does not exist".<br>
><br>
> 4) File system operations other than opening: There are legitimate<br>
> operations on unresolvable links. For example, such files can be<br>
> removed, renamed, and there are retrievable dates and other metadata<br>
> retrievable about them. One would not expect directory to balk in the<br>
> case that you are retrieving file names for one of these purposes.<br>
><br>
> My conclusion:<br>
> - If resolve-symlinks is false, the behavior should be either that of<br>
> SBCL's (return the name) or CCL's (don't return the name) depending on<br>
> which answer the implementation takes towards the question "is a<br>
> symbolic link a file?".<br>
> - If resolve-symlinks is true then signal an error.<br>
> - The default should be :resolve-symlinks nil, because cognate<br>
> directory operations in every operation's default case that I'm aware<br>
> of is to not consider this case an exception.<br>
<br>
With a (hopefully) carefully done refactoring of the underlying Pathname.listDirectory() routine, the semantics of CL:DIRECTORY are now:<br>
<br>
  (PATHSPEC &KEY (RESOLVE-SYMLINKS NIL))<br>
  Determines which, if any, files that are present in the file system have names matching PATHSPEC, and returns<br>
a fresh list of pathnames corresponding to the potential truenames of those files.<br>
<br>
In the default behavior with :RESOLVE-SYMLINKS set to nil, a<br>
CL:TRUENAME call an individual pathname in the list may signal an error,<br>
i.e. the pathnames have been constructed as truenames, without calling<br>
the entire resolution routine of CL:TRUENAME.<br>
<br>
If RESOLVE-SYMLINKS is T, and any of the pathnames have truenames<br>
which do not exist, this routine will signal a file error to its caller.<br>
<br>
This should satisfy the basic issues here:  there may be some corner cases to chase down.  Patches are welcome.<br>
<br>
This should also (mostly) fix the ASDF BUNDLE-OP problem (which was a problem with DIRECTORY called with :WILD-INFERIORS in a symlinked directory, as ‘/tmp' is under OS X).<br>
<br>
[r14619]: <a href="http://abcl.org/trac/changeset/14619" target="_blank">http://abcl.org/trac/changeset/14619</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
"A screaming comes across the sky.  It has happened before but there is nothing<br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>