Can an NTFS symlink have a volume guid target?

Question

Any way to specify e.g. \\?\Volume{f993747a-5d7a-4de1-a97a-c20c1af1ba02}\path\to\target.txt as the target of a symlink? Or does the absolute path always require a drive letter?

Answer 1

Can an NTFS symlink have a volume guid target?

You can use mklink to create a symbolic link of the form \\?\Volume{f993747a-5d7a-4de1-a97a-c20c1af1ba02}\path\to\target.txt

c:
md \test
cd \test
mklink testlink \\?\Volume{d1a54614-9369-11e4-b7ab-ccaf78b24c0a}\test\test.txt

Now the directory test contains a symbolic link (which in my case points to a file f:\test\test.txt on an external drive).

C:\test>dir
 Volume in drive C has no label.
 Volume Serial Number is C8D0-DF1E

 Directory of C:\test

29/03/2015  23:24    <DIR>          .
29/03/2015  23:24    <DIR>          ..
29/03/2015  23:17    <SYMLINK>      testlink [\\?\Volume{d1a54614-9369-11e4-b7ab-ccaf78b24c0a}\test\test.txt]
               1 File(s)              0 bytes
               2 Dir(s)  248,410,976,256 bytes free

...

C:\test>type testlink
this file is test.txt
C:\test>

...

C:\test>type f:\test\test.txt
this file is test.txt
C:\test>

Note

• This only works if you try to dereference the link from the command prompt, but not if you try to access it from the explorer interface.

Further Reading

• An A-Z Index of the Windows CMD command line - An excellent reference for all things Windows cmd line related.
• mklink - Create a symbolic link to a directory or a file, or create a hard file link or directory junction.

Answer 2

I have noticed only a single issue after years of using 10,000's of cross-drive hard links extensively. How significant it is will depend on your specific situation. Note that my application is using hard-links ("directory junctions," created with linkd.exe) only, so the following may or may not apply to the other types of symlink.

The only issue I've had is that chkdsk behaves badly in rare cases. If chkdsk.exe runs automatically on boot in response to a drive being previously shut down with a pending dirty flag, then it seems to remove all the cross-drive junctions in some cases. Besides removing the junctions, however the chkdsk.exe bug doesn't corrupt anything.

There are various workarounds and strategies for addressing the chkdsk.exe problem, which are beyond the scope of the original question, so suffice it to say that yes it works... with the one caveat I've encountered having been mentioned.