I spent some time this weekend organizing a few files and source code repositories. As part of this process, I wanted to take advantage of NTFS hard-links and junction points, both of which are supported on Windows Server 2003/8 and Vista.
I had no problems with hard-links at all. I'm using the ln.exe tool from http://www.flexhex.com/docs/articles/hard-links.phtml to create them, and it worked great right from the start (I could also use the "fsutil hardlink create" command).
Junction points, however, gave me quite a bit more trouble. I've used Junction points in the past very successfully. I work with some code bases that for many reasons expect to have certain directories in the C:\ drive, but I keep all my code in the E:\ drive.
For this I've used cross-drive junction points to have the folder in C:\ point to the real folder in E:\ and it's worked great for a couple of years. One other tool I've used for this sometimes is Junction Link Magic.
Yesterday, however, I discovered that on Windows Server 2003, if the junction folder was on the same drive as the target folder, it just wouldn't work correctly. I could create the junction just fine, and I could even see the contents of the directory through the junction using explorer, cmd.exe or PowerShell.
Actually trying to access any of the children through the junction would result in the error:
The filename, directory name, or volume label syntax is incorrect.I tried both of the tools I mentioned before, and it just wouldn't work. I tried creating the junctions from WinServer2K8 (where they worked perfectly) and then using the drive from 2003, and it still wouldn't work. This was easy to test, by the way, since this is a VHD image I share between several virtual machines.
Eventually, fellow MVP Juan T. Libre insisted I tried the linkd.exe tool in the Windows Server 2003 Resource Kit. I was reluctant to it since the other tools could create working cross-drive junctions and I was starting to suspect an OS limitation, but I gave it a go.
Much to my surprised, linkd.exe was able to create working same-drive junction points on Windows Server 2003. My guess is that there's some (probably undocumented) detail about how the APIs need to be called that can affect whether this works correctly or not.
Looking at the junctions using the "fsutil reparsepoint query" command clearly shows that the Reparse Data is slightly different between cross and same drive junctions, but not sure what it means from the API point of view. Just something to watch out for.
The lesson: Use linkd.exe on Windows Server 2003 to create same-drive junctions.
