[I did not send the previous e-mail as plaintext so it got gobbled. Resending. My apologies.] I am attaching code that illustrates ways to handle the following categories of Windows (Vista) 'reparse-points' in SBCL: - "SYMLINK" symbolic "soft" links (created via "mklink LINK TARGET"); - "SYMLINKD" directory symbolic links (created via "mklink /D LINK TARGET"); - "JUNCTION" directory mount points (created via "mklink /J LINK TARGET"); - "JUNCTION" directory mount points (created via "mountvol PATH VOLUME_NAME"); - ".LNK" windows shortcuts (as created by Windows Explorer). Note that there are two (slightly different) types of mount points in Microsoft-land, depending on whether the mount point is created by "mklink /J" or "mountvol". There are three types of "soft" symbolic links, and one type of "hard" link. I did not write code to handle Windows hard links. To test the code: create a symlink, load the code, execute the function WINLINKS:OVERRIDE-TRUENAME, and then apply TRUENAME to your favorite symlink. I have overridden TRUENAME in my version of :asdf with happy results. Should SBCL handle symlinks in a consistent manner across Windows and *NIX? If so, TRUENAME should return a resolved pathname when given the pathname of a link - in Windows as well as *NIX. Currently, SBCL does not understand Windows symbolic links. An advantage, beyond mere consistency, to supporting Windows symbolic links via TRUENAME out of the box is that the familiar system definition package :asdf would function as designed and documented for Windows as well as *NIX. There may be other advantages. The disadvantages to supporting Windows symbolic links are that the file system interface code would become more opaque, it may break existing applications, and some folks don't like the way :asdf follows links in the first place. There may be other disadvantages. I am too new to SBCL to have an opinion. Acknowledgements are in comments to the code.
Sign up for the SourceForge newsletter:No, thanks