Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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


│               │ Absolute │ Relative │ File │ Directory │ UNC │
│ Symbolic link │   Yes    │   Yes    │ Yes  │    Yes    │ Yes │
│ Junction      │   Yes    │    -     │  -   │    Yes    │  -  │


Let's assume we're creating a reparse point to create the redirect C:\SomeDir => D:\SomeDir

Since this scenario only requires local, absolute paths, either a junction or symlink would work. In this situation, is there any advantage to using one or the other?

Assume Windows 7 for the OS, disregarding backward-compatibility. (Prior to Vista, symlinks are not supported natively, though there is a 3rd-party driver that provides symlink support on Windows XP.)


I have found another difference.

  • Symbolic Link - Link's permissions only affect delete/rename operations on the link itself, read/write access (to the target) is governed by the target's permissions
  • Junction - Junction's permissions affect enumeration, revoking permissions on the junction will deny file listing through that junction, even if the target folder has more permissive ACLs

The permissions make it interesting, as symlinks can allow legacy applications to access configuration files in UAC-restricted areas (such as %ProgramFiles%) without changing existing access permissions, by storing the files in a non-restricted location and creating symlinks in the restricted directory.

Update 2

Windows 8.1 will resolve symbolic directory links when navigating into one via the textbox in a Save As... dialog box. Junctions are not expanded.

share|improve this question
Do you have a link to the permissions difference info? That is quite the find. – surfasb Dec 9 '11 at 18:58
@surfasb - I discovered it myself via experimentation on a Windows 7 system. All tests done on clean 32-bit and 64-bit installations. I looked online to see if I could find any relevant articles, but was only able to find a brief mention of symbolic link permissions in this Wikipedia article. As far as I know, no one has taken the trouble to document this behavior as of yet. – Unsigned Dec 9 '11 at 23:40
@surfasb - Found another link where a user comments on junction point permissions. Junctions seem to be the oddball here, as Linux/Unix handle symlinks similarly to Windows. Read/write permissions on the link itself are ignored, and the target's permissions are applied. – Unsigned Dec 10 '11 at 2:32
My testing confirms that read access to the target directory (i.e., listing directory contents) is restricted by the permissions on the junction point in addition to those on the target directory. However, no other access appears to be affected. In particular you can create files and subfolders if the target directory permissions allow it, regardless of the junction point permissions. – Harry Johnston Dec 11 '11 at 19:45
@HarryJohnston: Initially, I suspected some inconsistency as I block delete and write permissions to juctions but items and subfolders underneath do just fine. – surfasb Dec 12 '11 at 16:27

I understand NTFS symbolic links to be a replacement for Junctions on newer Windows OSes (Vista/7/8) as they function the same way but also provide additional functionality (remote points). So provided you're only working with newer operating systems, then there's no reason not to use the symbolic link option.

share|improve this answer
By default, symlinks on servers will be ignored, and even if followed are restricted by the server's share-level access rules: so, for example, you can't symlink to a location on the server that isn't shared, or if the share doesn't give the user access. So symlinks can't replace junction points in all contexts. – Harry Johnston Dec 11 '11 at 6:42

I think junction points is has wider support in backup software than symbolic links. You should check with whatever backup program you're using what feature is supported.

If unsupported, the symlink/junction point will either be backed up as a separate directory (and restored as such), or not backed up at all.

Other than the backup issue, I don't see a reason to prefer one over the other, in your specific case (local directory).

share|improve this answer
Junction points and Symlinks are both implemented through NTFS using reparse points. According to MSDN, they both are treated the same way by file operations through the API. – surfasb Dec 9 '11 at 10:31
@surfasb: However if the symlinks are not specifically supported (and recognized as such), they won't be recreated as symlinks during the restore from backup. – haimg Dec 9 '11 at 19:28
Ah, very good point! I didn't think far enough ahead. – surfasb Dec 9 '11 at 19:36

NTFS junctions can only be pointed to directories, while symlinks also work on files.

share|improve this answer
But for files you could use a hardlink instead. – paradroid Dec 8 '11 at 22:48
@paradroid - Only if it's on the same NTFS volume. – Unsigned Dec 8 '11 at 23:39

Here is one difference which I have noticed:

I have a synced directory of scripts, portable apps, etc. I use a batch script to make a Junction in the Start Menu directory which points to a directory of shortcuts for the portable apps.

A Junction allows the shortcuts to appear in the Start Menu. When I use a Symbolic Link instead, it does not work.

share|improve this answer
Strange, this works fine for me. I've also got symlinks to flash drives plugged into my machine. – surfasb Dec 9 '11 at 10:22
@surfasb: Are you sure you are doing what I described? Shortcuts within a directory pointed to by a symbolic link with the Start Menu directory do not appear in my Start Menu. They do when a Junction is used instead. – paradroid Dec 9 '11 at 13:35
Not sure if I read that correctly. So in the start menu, a symlink that points to a folder that contains shortcuts? I tried it just now. I even got the symlink to point to another symlink on a unc path that pointed to the folder on an UNC path with shortcuts. Of course that breaks the shortcuts. But a "remote to remote" symlink traversal is disabled by default in Windows. – surfasb Dec 9 '11 at 13:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .