Symlinks to directories in local-projects cause infinite loop with LispWorks

[tfeb]

If you create a symlink to a directory in the QL local-projects directory, then LispWorks will loop indefinitely when looking for *.asd files.

To reproduce (I can only try this on macOS):

1. create some directory outside the local-projects tree, say /tmp/zzz;
2. in local-projects do ln -s /tmp/zzz zzz, and remove the system index file;
3. (ql:list-local-systems) will now loop.

This is fairly obviously because of some confusion around getting the contents of directories containing links to other directories: there's a lot of implementation-specific code there. I've had a brief look at it but I don't understand it in detail yet. Since I have LW I will try to poke at it further and work out a fix.

[quicklisp]

Thanks for the report. I think I have a PR somewhere to fix it. I'll try to find it.

…

On Tue, Oct 17, 2023 at 7:35 AM Tim Bradshaw ***@***.***> wrote: If you create a symlink to a directory in the QL local-projects directory, then LispWorks will loop indefinitely when looking for *.asd files. To reproduce (I can only try this on macOS): 1. create some directory outside the local-projects tree, say /tmp/zzz; 2. in local-projects do ln -s /tmp/zzz zzz, and remove the system index file; 3. (ql:list-local-systems) will now loop. This is fairly obviously because of some confusion around getting the contents of directories containing links to other directories: there's a lot of implementation-specific code there. I've had a brief look at it but I don't understand it in detail yet. Since I have LW I will try to poke at it further and work out a fix. — Reply to this email directly, view it on GitHub <#226>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACPNLO3EO262JR4WVMCXLLX7ZUOXAVCNFSM6AAAAAA6DV7X32VHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2DOMRQGMYTINI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tfeb]

I think the existing PR is #222. I've just submitted #227 which I think may be better: it doesn't have problems with packages (I don't think #222 will compile in implementations other than LW as is) and it doesn't need to be conditionalized on LW version.

I've tested this against SBCL, LW (8) and CCL.

I think a longer-term solution might be to define a pathname-as-directory interface which, give a pathname known to refer to a directory, returns its name as a directory. This is by analogy with the Emacs file-name-as-directory function. I almost did that but I thought it would be too big a change as there are other places it should be called.