We have symbolically linked files on one of the volumes on our server (Windows Server 2008 R2 Standard). The links use root relative paths in order to reference files within the same volume. So, these files have targets like "\archive\2012\02\30\mediafile.mts". This is all awesome and great. Both from within the server and from networked clients (as long as fsutil's SymlinkEvaluation has R2R enabled), all these symlinks work great and we save a ton of space consolidating duplicate files in projects. However, both Windows 7 and Windows Server have a serious problem if you attempt to inspect the properties of a file (context menu item Properties). The first tab that appears is the Shortcut tab, but in the form the value for Target: is incorrectly resolved. If one attempts to change tabs, the system throws a warning and refuses to change tabs: "Problem with Shortcut: The name [some path] specified in the Target box is not valid. Make sure the path and file name are correct." The path listed in there seems to be resolving the relative path into the current directory, rather than--as is stated in the Microsoft documentation on Creating Symbolic Links--to resolve relative links beginning with "\" as referencing the root of the current drive. This behavior makes it impossible to view the other properties of the file in the explorer GUI. This seems like a rather obvious bug that I would be surprised if others have not encountered before. All the symbolic link files that we have on our system were created using the CreateSymbolicLink method found in kernel32.dll. Any ideas?

Hi, Since this problem is a development related issue. I suggest that you could post you question to the MSDN forum then you could get more information there. http://social.msdn.microsoft.com/Forums/en-US/categories The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Best Regards, Della Li

Okay, thanks for the suggestion. I'll probably post it somewhere there also. For clarification, though, I wouldn't want it misconstrued that this is only limited to a development question. The fact that valid root relative symbolic links are getting resolved differently in different contexts tells me this is a bug in Windows and, honestly, I'm actually not sure where to file bugs for Windows. ;) Despite that, you are probably correct that this might not be the best place to solicit feedback, since it seems that none of the standard tools that admins use to generate symlinks are actually capable of generating valid root relative symbolic links. I suspect that fact might be good reason that other admins haven't experienced this issue before. For instance, if you attempt to create a root relative symbolic link using mklink, the resulting symlink exhibits similar behavior. However, in the case of mklink generated links, the incorrect interpretation of the root relative link (starting from the current directory) gets stored as an absolute path in the target value. So, it always fails, whereas at least the ones created use the kernel32.dll method work in most circumstances. The PSCX New-Symlink cmdlet, on the other hand, also fails to generate true root relative links, but it at least gets its absolute target path correct. Regards, Mervin