Comment 8 for bug 1205555

Revision history for this message
Piotr Kalinowski (pitkali) wrote : Re: ASDF on CCL+mac does not follow symlinks in registry

1. (UIOP:SUBDIRECTORIES x), on CCL 1.9 does *not* list linked directories at all. The directories that are listed are returned as directory pathnames. So if X contains link L to an existing directory, L will not be in the output at all. As a direct consequence, COLLECT-SUB*DIRECTORIES never finds nor recurses into L. Thus none of the ASDs inside L gets detected by ASDF.

2. To be honest, ASDF will pick up all ASDs correctly with UIOP:SUBDIRECTORIES fixed. However, it turns out that because CCL does not check if links point to directories or files (with :FOLLOW-LINK nil, that is), and instead treats them always as files, that they are returned using file pathnames. This is not how it works on SBCL 1.1.9 or LispWorks 6.1, where disabling link following simply results in returning pathnames that do not correspond to true names of link targets.

I thought that the point of UIOP is to abstract away as much implementation specific behaviour as possible. This seems to be one such detail. The client code can deal with this by using DIRECTORY-EXISTS-P, which will behave properly even in case of links and CCL. So it is not really necessary to change DIRECTORY-FILES, but then I feel like it would be a good idea to document this.

However, if this is left like this, I suspect that it will end up with someone writing code that breaks on CCL. But maybe I'm just cynical ;)

3. That sounds like an overkill. I think that testing UIOP:SUBDIRECTORIES will be enough. Although Windows indeed does not have portable way of doing any sort of links. Windows 2000/XP with NTFS has something called junction point, and Vista+ does have proper symbolic links. I actually do have a virtual machine with Windows 7, so I could see how this behaves there.

For portable way of creating links, there seems to be a library called OSICAT that does have this, but it works only on Unix-like systems, so that does not seem to be any better than calling RUN-PROGRAM.

I can look into writing the test cases, although probably not today.