RSS Feeds
Symbolic links on Windows: why and how
Is it possible to use "symlinks" in Windows? Maybe. If you don't know what they are, or do and are surprised by the news, I'd like to pass on a tip someone shared with me and some additional info to help anyone who may want to investigate this further.
Folks in the Linux world are quite accustomed to creating what they call "symbolic links"; in other words, a virtual name for a directory path (\bob really points to \somedir\somesubdir\realbob, or the like). This sort of indirection can have lots of value. Of course, it shortens references to long paths but more important it abstracts file/path references so that if the real path underlying the link changes, one need only change the definition of the link, not any code that might use the link. Also, it allows a remote drive to be referenced as if it's just a directory on your local drive.
This notion is similar in concept to declaring alias directory mappings in a web server, or using "cf mappings" in the CF or BlueDragon administration console for declaring an alias for use in CFINCLUDEs and CFMODULEs. But each of those is limited (the first to CFML tag references and the second to URL references.) Symlinks at the file system level bring that flexibility to a much wider range of uses. (For those still not quite getting it, an even more abstract similarity is how a datasource name hides the real path to a database, so the programmer need not worry about it in their code.)
Anyway, Linux users have long used the notion of these symlinks in the file system to create such aliases for file paths. Most likely think it's a Linux-only thing, but in fact there is a similar concept available in Windows, at least Win NT, Win2k, XP, and above--if you know about it. Thanks to Mark Woods, who shared the tip on the BlueDragon interest list back in September. (Sorry, Mark, for the delay in writing up this blog entry.)
In Win2K, MS introduced what they call "junction points" or "reparse points" for NTFS 5.0-organized disks. These are effectively the same thing as symlinks, though not exactly as they only map to complete physical paths as opposed to Linux symlinks being able to be set relative to their target and can even be set for files, not just directories. (More on a solution for that later.) As an aside, in WinNT there was a similar if less flexible concept called "DFS" or distributed file system, which introduced file path abstraction to Windows users.
The Win2k Resource kit introduced a tool called "linkd" to create these junction points. For those without that tool, the folks at sysinternals offered their own free version, called "junction" that brings the feature to the masses. See http://www.sysinternals.com/ntw2k/source/misc.shtml#junction. Again, the feature can only be used with an NTFS 5.0-organized disk as the target of the link, and it seems that it works on any NTFS 5 disk, including XP and Win2k3). Still, it's worth exploring for those interested in the capability (and please leave a comment to let me know if you learn anything about using them, as I have not yet).
You can learn still more about the general concepts of Windows-based symlinks at places such as:
- http://is-it-http://is-it-true.org/nt/nt2000/atips/atips23.shtml
- http://www.codeproject.com/w2k/junctionpoints.asp
- http://aroundcny.com/technofile/texts/tec042802.html
- http://www.microsoft.com/NTServer/nts/downloads/winfeatures/NTSDistrFile/AdminGuide.asp
Finally, perhaps the best news for some, that page mentions yet another tool for enabling links to files as well as paths. This tool refer to them as "hard links":
On XP the command fsutil can create hardlinks.
The url is long:
http:/
/www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/WIND
OWSXP/home/using/productdoc/en/fsutil.asp
Perderabo
Thanks for that, Perderabo. In fact, I hadn't yet seen your comment and was
coming to add one myself to point out the FSUTIL command. You have to run
it as Administrator, but I too just found it and it can be used to query
and delete existing reparsepoints as well:
fsutil reparsepoint query
fsutil reparsepoint delete
More at http://www.microsoft. com/technet/prodtechnol/winxppro/proddocs/fsutil.asp.
I also just used junction finally for the first time. I'll soon be writing a blog entry about the experience and some cool benefits it can bring for BlueDragon testing.
charlie arehart [charlie@newatlanta.com]
A little more info. I tried to use the JunctionLink Magic GUI interface
that I listed at the end of my original posting above. While it was able to
quickly find and display links I'd created with the junction tool mentioned
prior to that, it for some reason WOULD NOT let me create a junction.
That's too bad. But again, it does have the great advantage of letting you
see junctions created with junction. Since it offers no easy means to show
them itself, the two together make a good team.
charlie arehart [charlie@newatlanta.com]
Oh, one other thing. The help file with JunctionLink does offer some
compelling reasons both to use junctions and to be wary of them. Indeed, it
raises some issues I'd not considered (and not mentioned at the other
sources I offered), so please take heed of them before using these tools.
(As they and I repeat, use these at your own risk.)
In the interest of protecting folks who may not get the tool and see the help, let me share the warnings:
(From the help in JunctionLinkMagic): We recommend you follow these rules closely when using junction points:
· Use NTFS security to protect junction points from inadvertent deletion.
· Use NTFS security to protect files and directories targeted by junction points from inadvertent deletion or other file system operations.
· Never delete a junction point using Explorer, a del /s command, or other file system utilities that walk recursively into directory trees. These utilities will affect the target directory and all subdirectories. Instead, use Junction Link Magic to delete junction points.
· Use caution when applying security ACLs or changing file compression in a directory tree that includes NTFS junction points.
· Do not create namespace cycles with NTFS junction points.
· Place all your junction points at a secure location in a namespace where you can test them out in safety, and other users will not mistakenly delete them or walk through them.
charlie arehart [charlie@newatlanta.com]
One more observation. The warning from the help file I pointed out in that
last comment got me worried: if I created a new directory link (reparse
point/junction) in directory a, pointing at directory b, their warnings
suggest that if I delete directory a (or the junction link itself), I'd
delete directory b (that it points to). I just tried it, and it didn't
happen. Phew! Had me really worried.
Still, I'll again assert that none of this is our software and you use it at your own risk.
charlie arehart [charlie@newatlanta.com]
In case anyone still is reading charlie arehart's comment above that
deleting a link does not delete the target of the
link:
BEWARE
DELETING THE LINK DOES, REPEAT _DOES_ DELETE ITS
TARGET
- just not necessarily right away.
Please see my article for
details:
http://shell-shocked.org/article.php?id=284
They're in the
Limitations section, a little less than halfway through the article.
Here's an update: the Win2k3 resource toolkit also has the linkd.exe tool:
Looks like Windows Vista will have support for symbolic links built in (as
well it should!):