│               │ 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.

  • Do you have a link to the permissions difference info? That is quite the find. – surfasb Dec 9 '11 at 18:58
  • 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 won't make this a full answer unless requested, but if you are using a GNU or other non-Windows system to access the volume via mount.cifs, then symlinks will appear as such whereas junctions will be seen as normal directories — probably because of the point where the IO resolution occurs, i.e. locally on the Windows host. – can-ned_food Oct 14 '17 at 8:45

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.

  • 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).

  • 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
  • 2
    @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
  • So far as I know, this is more important if the volume will be accessed by older Windows OSes. – can-ned_food Oct 14 '17 at 8:40

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

  • But for files you could use a hardlink instead. – paradroid Dec 8 '11 at 22:48

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.

  • 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

Maybe I've missed it somewhere in the comments, but one very important difference between symlinks and junctions in Windows for me are the needed privileges to create both. While symlinks are by default only creatable using special permissions default users don't have, junctions can be created easily by all default users OOB and are therefore my preferred link type for dirs.

By default, members of the Administrators group have this right.


Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.