[LispWorks] UIOP:DIRECTORY* follows symbolic links

Bug #1205653 reported by Piotr Kalinowski
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ASDF
In Progress
Undecided
Robert P. Goldman

Bug Description

UIOP:DIRECTORY* specifically disables following symbolic links on several implementations, but not on LispWorks, which results in returning true names of any links in a given directory.

Revision history for this message
Piotr Kalinowski (pitkali) wrote :
Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

Piotr, do you have a paid license for LispWorks that you could use to run our test scripts? I cannot test LW because there's no command-line version in the free edition.

I will try to apply your patch and push it today.

Revision history for this message
Piotr Kalinowski (pitkali) wrote :

Unfortunately enough I have only Personal Edition here.

Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

Patch is incorporated in my working copy. I will issue a new version with this patch by the week-end.

Revision history for this message
Faré (fahree) wrote :

It would be nice to have a portable way for users to explicitly specify whether they want symlinks resolved or not.

Revision history for this message
Piotr Kalinowski (pitkali) wrote : Re: [Bug 1205653] Re: [LispWorks] UIOP:DIRECTORY* follows symbolic links

There is a function for resolving symlinks afterwards. Although,
admittedly, it should be easy to implement something like that. Hyperspec
says CL:DIRECTORY should return true names, and it seems, looking at
UIOP:DIRECTORY*, that most implementations understand it means that links
should be followed.

On 29 July 2013 05:58, Faré <email address hidden> wrote:

> It would be nice to have a portable way for users to explicitly specify
> whether they want symlinks resolved or not.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1205653
>
> Title:
> [LispWorks] UIOP:DIRECTORY* follows symbolic links
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/asdf/+bug/1205653/+subscriptions
>

--
Intelligence is like a river: the deeper it is, the less noise it makes

Changed in asdf:
status: New → In Progress
assignee: nobody → Robert P. Goldman (rpgoldman)
Revision history for this message
Faré (fahree) wrote :

Avoiding the truename computation is a huge speedup on many implementations. Avoiding it on all implementations (assuming it's possible) makes for consistency and cleaner semantics.

Revision history for this message
pipping (pipping) wrote :
Download full text (4.1 KiB)

To explore the behaviour of `uiop:directory-files` and `uiop:subdirectory`, come up with a test-case and hopefully eventually put together something portable, I've created a sample directory with the following contents:

$ ls -RF
.:
actual-dir/ link-to-dir@

./actual-dir:
file link-to-file@
$

and run the following code:

     (format t "~{~a~%~}"
      (list
       (uiop:subdirectories "./")
       (uiop:subdirectories (uiop:getcwd))
       (uiop:directory-files "actual-dir/")
       (uiop:directory-files "link-to-dir/")
       (uiop:directory-files "./")
       (uiop:directory-files (uiop:getcwd))))';

(stored in another directory) via `cl` from cl-launch as follows:

for lisp in abcl allegro ccl clisp cmucl ecl lispworks mkcl sbcl; do
  echo "===== $lisp =====";
  env ABCL=abcl-1.3.3 ALLEGRO=alisp CCL=ccl-1.11 CLISP=clisp-2.49 CMUCL=cmucl-21a ECL=ecl-16.1.2 LISPWORKS=lw-console-7.0 MKCL=mkcl-git SBCL=sbcl-1.3.9 \
    cl -l $lisp --require asdf --load ~/foo.lisp
done

This prints the following for me (modulo tiny whitespace changes):

===== abcl =====
(/home/pipping/test/actual-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/file /home/pipping/test/actual-dir/link-to-file)
(/home/pipping/test/link-to-dir/file /home/pipping/test/link-to-dir/link-to-file)
NIL
NIL
===== allegro =====
(/home/pipping/test/link-to-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/link-to-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/link-to-file /home/pipping/test/actual-dir/file)
(/home/pipping/test/link-to-dir/link-to-file /home/pipping/test/link-to-dir/file)
(/home/pipping/test/link-to-dir)
(/home/pipping/test/link-to-dir)
===== ccl =====
(/home/pipping/test/./actual-dir/)
(/home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/file /home/pipping/test/actual-dir/link-to-file)
(/home/pipping/test/link-to-dir/file /home/pipping/test/link-to-dir/link-to-file)
(/home/pipping/test/./link-to-dir)
(/home/pipping/test/link-to-dir)
===== clisp =====
(/home/pipping/test/actual-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/file /home/pipping/test/actual-dir/file)
(/home/pipping/test/actual-dir/file /home/pipping/test/actual-dir/file)
NIL
NIL
===== cmucl =====
(actual-dir/ link-to-dir/)
(/home/pipping/test/actual-dir/ /home/pipping/test/link-to-dir/)
(actual-dir/file actual-dir/link-to-file)
(link-to-dir/file link-to-dir/link-to-file)
NIL
NIL
===== ecl =====
(/home/pipping/test/actual-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/file /home/pipping/test/actual-dir/file)
(/home/pipping/test/actual-dir/file /home/pipping/test/actual-dir/file)
NIL
NIL
===== lispworks =====
(/home/pipping/test/link-to-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/link-to-dir/ /home/pipping/test/actual-dir/)
(/home/pipping/test/actual-dir/link-to-file /home/pipping/test/actual-dir/file)
(/home/pipping/test/link-to-dir/link-to-file /home/pipping/test/link-to-dir/file)
NIL
NIL
===== mkcl =====
...

Read more...

Revision history for this message
pipping (pipping) wrote :

Launchpad makes such output very hard to read (and impossible to edit). Please see also https://gitlab.common-lisp.net/snippets/14

Revision history for this message
pipping (pipping) wrote :

I've put up the results in tabular form here:

  https://gitlab.common-lisp.net/epipping/asdf/wikis/uiop-and-symlinks

This would take a lot of effort to get right.

Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

Absent an API to detect symbolic links -- which I don't believe every implementation offers -- is it even possible to fix this?

I believe Fare has suggested relying on iolib for this, but of course that can only be done downstream of UIOP.

Alternative: could we prepare some kind of enhancement request to go to the various implementations, to ask them to support?

Revision history for this message
Faré (fahree) wrote :

I don't have the energy to go after each of 10+ implementations to get them to offer an semi-uniform interface, but if you do, that'd be the ideal situation.

While you're at it, you could also try to make sure pathnames and/or native-pathnames can properly handle wildcard characters, non-ASCII characters, non-UTF-8 sequences in namestrings, etc.

Not a fight for me.

Revision history for this message
pipping (pipping) wrote :

Allow me to post my warning to future generations about symlink handling in pure CL here as well:

I think anyone seriously hoping to fix anything here should take a look at

  https://gitlab.common-lisp.net/asdf/asdf/merge_requests/27

and realise the futility of an attempt.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.