[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
- "JUNCTION" directory mount points (created via "mklink /J LINK TARGET");
- "JUNCTION" directory mount points (created via "mountvol PATH
- ".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
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.