Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

According to the MSDN Documentation on Creating Symbolic Links, root relative symbolic links (those starting with "\") should resolve relative to the drive that the symlink is accessed from. I have a bunch of such root relative symlinks on a Windows Server, and am able to access them just fine from both within the server and from Windows 7 clients (at least, once the R2R SymlinkEvaluation was enabled using fsutil). That is, say the file is a .mp4, the symlink opens fine in Windows Media Player.

However, when one pulls up the Properties window (context menu > Properties), the value for the Target gets interpreted incorrectly, resolving the path to the current directory, rather than the current drive. Due to this, it becomes impossible to inspect other tabs of the Properties window (it opens with the Shortcut tab selected), responding to any attempt to select a different tab with a warning popup:

"Problem with Shortcut: The name [some incorrect path] specified in the Target box is not valid. Make sure the path and file name are correct."

I get this behavior both in Windows 7 and on Windows Server 2008 r2.

Has anyone else run into this issue? Might there be settings in Windows that I need to configure (beyond the fsutil tweaks) to fix this? Or, is this (gulp)... a bug?

I also noticed that certain programs choke on these symlinks, while others are fine. For example, Quicktime fails consistently, whereas VLC is a champ. Even more strange, some programs choke only on specific file types (Sony Vegas has no problem with symlink'd .mp4's, but consistently fails on .dv files). Is this strange to anyone else?

This all seems to be rather immature behavior for a file system technology that Windows has touted support for since Vista.

Note: All the links I've tested were created using the CreateSymbolicLink method in kernel32.dll. From my tests, it seems that neither mklink, nor PSCX's New-Symlink cmdlet are capable of generating valid root relative symbolic links (they both attempt to resolve the link to an absolute one before assigning it as the target).


For what it's worth, the tool I used to create the links is now posted on GitHub: PSLinkTools. Once the PowerShell SnapIn is installed, the following command would create a root relative symbolic link:

New-Symlink -LiteralPath 'C:\Users\Kurt\Desktop\NE.pdf' -Target '\Users\Kurt\Books\Leibniz\New Essays on Human Understanding.pdf'

where the target will point to the root of, in this case, the C drive.

share|improve this question
Noone has posted any suggestions. Maybe an example would help? I was't able to reproduce the error but then I'm not sure what the steps are. I can't offer any help but your question has piqued my interest in knowing what it is you're doing and the answer. – Ian Murphy Feb 6 '12 at 17:01
@Ian - Thanks for the comment. Were you able to create a root relative symlink in Windows? What tool did you use? Since the standard ones didn't work for me, I had written my own PS cmdlet, which I can post, if you think that'd help. I'm beginning to wonder whether others even use root relative links in windows. – merv Feb 8 '12 at 1:38
No idea what one is. Post a few lines of code if that demonstrates what you are doing. what with linux lacking windows' separation of devices in the file system, mapping from one to the other is always problematic. – Ian Murphy Feb 13 '12 at 14:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.