[LispWorks] UIOP:DIRECTORY* follows symbolic links

Bug #1205653 reported by Piotr Kalinowski on 2013-07-27
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ASDF
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.

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.

Piotr Kalinowski (pitkali) wrote :

Unfortunately enough I have only Personal Edition here.

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.

Faré (fahree) wrote :

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

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)
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.

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

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

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.

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?

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.

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  Edit
Everyone can see this information.

Other bug subscribers