551

In the context of NTFS:

MKLINK [[/D] | [/H] | [/J]] Link Target

/D Creates a directory symbolic link. Default is a file symbolic link.
/H Creates a hard link instead of a symbolic link.
/J Creates a Directory Junction.
Link specifies the new symbolic link name.
Target specifies the path (relative or absolute) that the new link refers to.

  1. Isn't a directory junction the exact same thing as a directory symbolic link?

    What's the difference between mklink /D f1 f2 and mklink /J f1 f2 ?

  2. Since a "directory" is actually just a file, what would be the difference between a directory symbolic link and a file symbolic link?

Community
  • 1
Pacerier
  • 26,733
  • 82
  • 197
  • 273
  • 4
    Related: http://superuser.com/q/347930/24500 – surfasb Dec 29 '11 at 13:05
  • 7
    Warning: Windows 10 has serious holes regarding symlinks: e.g. deleting the junction is safe but just moving it to some dest empties the original directory! It leaves the junction at its initial location, and at the dest there will be an independent folder with the original contents. This can however be undone. Now, symlinks don't have this problem, (moving the symlink will carry its target). Still, moving it to another volume will make an empty independent folder and undoing this will move the independent folder at the initial symlink location. These are just a few behaviors. – mireazma Jan 13 '21 at 22:19
  • @mireazma on Jan 13, 2021 - Tried it and could not reproduce. This seems to be fixed in Windows 10 21H2 [Version 10.0.19044.2846], possibly earlier. – Lumi Apr 20 '23 at 13:56

4 Answers4

497

A junction is definitely not the same thing as a directory symbolic link, although they behave similarly. The main difference is that, if you are looking at a remote server, junctions are processed at the server and directory symbolic links are processed at the client. Also see Matthew's comment on the fact that this means symbolic links on the local file system can point to remote file systems.

Suppose that on a machine named Alice you were to put a junction point c:\myjp and a directory symbolic link c:\mysymlink, both pointing to c:\targetfolder. While you're using Alice you won't notice much difference between them. But if you're using another machine named Bob, then the junction point

\\Alice\c$\myjp will point to \\Alice\c$\targetfolder

but the symbolic link

\\Alice\c$\mysymlink will point to \\Bob\c$\targetfolder

(Caveat: by default, the system doesn't follow symlinks on remote volumes, so in most cases the second example will actually result in either "File Not Found" or "The symbolic link cannot be followed because its type is disabled.")

The difference between a directory symbolic link and a file symbolic link is simply that one represents a directory and one represents a file. Since the target of the link doesn't need to exist when the link is created, the file system needs to know whether to tell applications that it is a directory or not.

It should also be noted that creating a symbolic link requires special privilege (by default, only available to elevated processes) whereas creating a junction only requires access to the file system.

Harry Johnston
  • 5,754
  • 7
  • 30
  • 55
  • 22
    Just to be clear: there may well be other subtler functional differences between directory junctions and directory symbolic links. The remote vs. local thing is just the most obvious from a user (as opposed to a developer) perspective. – Harry Johnston Oct 05 '11 at 04:02
  • Sry I find the second paragraph quite ambiguous. If I create a symbolic link `testlink` on the client, which links to the `c:\test` folder on the server, doesn't `testlink` (symbolic link) also allow me to see the contents of the `C:\test` folder on the server? – Pacerier Oct 05 '11 at 05:31
  • 1
    @Pacerier the difference is where they are resolved. If you create a symbolic link on your local machine then you won't notice the difference. If you shared out your computer then a junction would resolve to your computer when viewed from another but a symbolic link would resolve to theirs – Matthew Steeples Oct 05 '11 at 07:43
  • 17
    @MatthewSteeples do you mean that if I create a symbolic link `C:\testlink` (which points to `C:\test` on my computer) and someone remote access my computer and clicks on `C:\testlink`, it would resolve to the `C:\test` on HIS computer, Whereas if I create a directory junction `C:\testlink` (which points to `C:\test` on my computer), and someone remote access my computer and clicks on `C:\testlink`) it would lead him to the `C:\test` on my computer? Or did I get it the wrong way round? – Pacerier Oct 05 '11 at 08:19
  • 3
    @Pacerier that's right. You've got it the right way round in your example – Matthew Steeples Oct 05 '11 at 08:41
  • I've edited my answer to expand on the example, hopefully it is clearer now. – Harry Johnston Oct 05 '11 at 22:38
  • 2
    @Matthew ic, so that means that symbolic links are useless – Pacerier Oct 06 '11 at 13:13
  • 11
    @Pacerier in this context yes, but symbolic links allow you to have a folder on your computer that points to a network share (because they're resolved client side). Eg C:\MyNetworkShare could actually point to \\Alice\Share – Matthew Steeples Oct 06 '11 at 14:57
  • 9
    @MatthewSteeples but couldn't we create a directory junction `C:\MyNetworkShare` which points to `\\Alice\Share` as well? – Pacerier Oct 07 '11 at 10:44
  • 13
    @Pacerier, no, junction points have to be local. – Harry Johnston Oct 08 '11 at 00:05
  • @HarryJohnston I see your point now – Pacerier Oct 08 '11 at 00:52
  • 1
    Also: suppose a machine has two network cards, and so is known on the network by two different names. (E.g. a subnet of high-end calculation servers, each with one 100MB card on the larger, main network, and each with 40GB cards on a smaller network connecting them to the file server for inter-calc cummunication). Consider a junction on the file-server Svr: G:\jnctn -> G:\trgt. If the server is known as SvrA on the 100MB network and SrvB on the 40GB network, and G:\ is shared as Shr, then \\SvrA\shr\jnctn and \\SvrB\shr\jnctn both resolve to G:\trgt on the server. – David I. McIntosh Jun 03 '14 at 18:32
  • 1
    And the key thing about this is: they resolve on the same network as the original access. That is, \\SvrA\shr\jnctn resolves, in effect, to \\SvrA\shr\trgt, i.e. resolves on the 100MB network, and \\SrvB\shr\jnctn resolves to \\Svrb\shr\trgt, i.e. resolves on the 40GB network. If you were to create a symbolic link that still works for external access, you would need to link as G:\jnctn -> \\SrvA\shr\tgt _or_ \\SrvB\shr\tgt, and so you are deciding the network access in the link itself. This may be desirable or may be exactly what you don't want! – David I. McIntosh Jun 03 '14 at 18:37
  • I'm confused about the junction link above. Is the source of that folder on Bob's computer? – Mallow Jul 24 '14 at 15:55
  • 2
    @Mallow I think everything is on *Alice*'s computer. *Bob* is merely a client accessing *Alice* – user193130 Jul 24 '14 at 16:10
  • 1
    Regard writing style, when comparing two things, it's clearer to unfamiliar people to explicitly state which goes with which. The following is confusing: "One is foo foo, and the other is bar bar"... (so... which one?) – ahnbizcad Aug 09 '15 at 21:08
  • @ahnbizcad: I really don't think it necessary to spell out explicitly that the directory symbolic link represents a directory and the file symbolic link represents a file. It's hardly likely to be the other way around! – Harry Johnston Aug 09 '15 at 21:20
  • @Harry Johnston, can you say more about " junctions are processed at the server and directory symbolic links are processed at the client" or where you got this from? – Daan Sep 14 '15 at 09:22
  • 2
    @Daan: the fact that symbolic links cross SMB is documented in [What's new in SMB?](https://technet.microsoft.com/en-us/library/ff625695(v=ws.10).aspx). I don't know of any documentation that explicitly states that junction points don't, but it is inherent in the way they are implemented and I did find [Create the SYSVOL Root and Staging Areas Junction Point](https://technet.microsoft.com/en-us/library/cc794939(v=ws.10).aspx) which otherwise wouldn't work. (Mostly though, it's just experience.) – Harry Johnston Sep 14 '15 at 19:52
  • @Harry Johnston, the reason I asked is because I had a problem with using junctions and symbolic links in my webserver, I posted the question here: http://serverfault.com/questions/722381/iis-server-directory-not-writable-via-symbolic-link-compared-to-directory-junct – Daan Sep 15 '15 at 08:33
  • was there something else about safety or not wit deleting them? – barlop Jun 11 '16 at 17:10
  • It's possible to create a file symlink to a directory though. This still works in Cygwin, however if you don't explicitly set it to a `/D`, then apps like Windows explorer doesn't realise it's a directory symlink and show it as a directory and allow traversal. – CMCDragonkai Feb 07 '17 at 02:43
  • apparently win xp and prior had a danger issue re deleting junctions. http://cects.com/overview-to-understanding-hard-links-junction-points-and-symbolic-links-in-windows/ Safest thing is a suggestion here that'd apply to symbolic links or junctions or whatever, https://superuser.com/questions/167076/how-can-i-delete-a-symbolic-link add an underscore or rename, the actual non-link target directory, then the link or junction thing, shows as empty and delete it with eg rmdir or – barlop Sep 22 '17 at 11:19
  • @barlop, AFAIK, you can always delete a junction or directory symbolic link with rmdir, you don't need to make it appear to be empty first. – Harry Johnston Sep 22 '17 at 22:04
  • @HarryJohnston I didn't say you had to. My point is that it's safer to temporarily rename the target. so that a)one is not deleting the wrong one(the target when one means to delete the junction and only the junction), and b)that link documents that XP and win2K3 and prior, had an issue where deleting a junction deleted the target directory itself too. So it's safer from the perspective of behaviour of prior Win OSs and human error. – barlop Sep 23 '17 at 05:59
  • @HarryJohnston Also do you know of a quick way to test if a directory is a link(unless one made a batch file with a command like this) https://stackoverflow.com/questions/18883892/batch-file-windows-cmd-exe-test-if-a-directory-is-a-link-symlink so without a quick easy check, I suppose if one can quickly check then one can do it safely (putting aside the issue with previous OSs like XP and Win2K3 and prior) – barlop Sep 23 '17 at 06:05
  • 1
    @barlop, `rmdir` should be safe, I'm pretty sure it only ever deletes the junction, not the target. It certainly won't delete any content unless you specify `/s`. I would normally just use `dir` (on the parent directory) to see whether something is a junction point. In some cases that might not be convenient, I suppose. – Harry Johnston Sep 23 '17 at 06:44
  • @HarryJohnston ah yes you're right. good idea re rmdir(without /s), and rm, and re dir on the parent.. I see even dir c:\blahsymboliclink will just show the symbolic link.. so it's not like with dir c:\windows which does dir c:\windows\*.* dir c:\blahsymboliclink will show whether it's a symbolic link or not. dir c:\blahsymbolic link is a bit like dir c:\windo* or `ls -ld blah` it won't list the contents of the symbolic link directory itself unless you dod ...\*.* or were within it. – barlop Sep 23 '17 at 07:40
160

Symbolic links have more functionality, while junctions almost seem to be a legacy feature because of their limitations, but the security implications of these limitations are specifically why a junction might be preferred over a symbolic link. Remote targeting makes symbolic links more functional, but also raises their security profile, while junctions might be considered safer because they are constrained to local paths. So, if you want a local link and can live with an absolute path, you're probably better off with a junction; otherwise, consider a symbolic link for its added abilities.

Comparison between Junctions and Symbolic Links

*The statement of difference in speed/complexity comes from an unverified statement in the Wikipedia entry on NTFS reparse points (a good read).

Other NTFS Link Comparisons

Here are some other comparisons on the topic, but these can be misleading when considering junctions because they don't list the benefits I list above.

Taken from here (a good introductory read)

NTFS Link Comparison

From SS64 page on MKLink

SS64 page on MKLink comparison table

Comments about Terminology

Junctions are Symbolic Links

Junctions and Symbolic links are really doing the same thing in the same way (reparse points), aside from the aforementioned differences in how they're processed. In fact, technically, a Junction is a symbolic link, and sometimes documentation might call a Junction a symbolic link, as is the case here. So, that's just something to be aware of regarding terminology.

NTFS

Even though the OP specifies this, it's worth pointing out that "symbolic link" is a very general term that is not specific to NTFS. So, to be specific, this comparison is about NTFS Junctions vs. NTFS Symbolic Links.

Greenonline
  • 2,235
  • 11
  • 24
  • 30
u8it
  • 2,099
  • 1
  • 11
  • 11
78

Complex talk hurts brain -- I like charts:

Assume any MyLink is a symbolic link and any MyJunc is a junction pointing at Target as created.

e.g.

mklink /D MyLink C:\T_Dir for creating a symbolic link to the target directory

mklink /J MyJunc C:\T_Dir for creating a directory junction to the target directory

Where syntax is mklink [/J,/D] [link path] [target path] as typed on local machine

 link path    |   target path   |         When accessed ..
              |                 |  (locally)    |    (remotely)
              |                 |               |
C:\MyLink     |   C:\T_Dir      |  C:\T_Dir     |  [leads back to local]
C:\MyJunc     |   C:\T_Dir      |  C:\T_Dir     |  [leads to remote]
              |                 |
\\Svr\MyLink  |   C:\T_Dir      |   C:\T_Dir    |  [leads back to local]
\\Svr\MyJunc  |   C:\T_Dir      |  *** Must create and point local ***
              |                 |
C:\MyLink     |  \\Sv2\T_Dir    |  \\Sv2\T_Dir  |   Error*1
C:\MyJunc     |  \\Sv2\T_Dir    |  *** Error - Must point local ***
              |                 |
\\Svr\MyLink  |  \\Sv2\T_Dir    |  Error*1
\\Svr\MyJunc  |  \\Sv2\T_Dir    |  *** Must create link using target device ***

Error*1 - If you unblocked access to remote symbolic links on your local machine, then this would work .. but only on the local machine where it's unblocked

Still.Tony
  • 1,221
  • 13
  • 25
  • 3
    That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directory `d:\_tmp\data`. Create link like so: `d:\_tmp>mklink /d data-link data`. Remote user has full access to `d:\_tmp` and all its subfolders BUT he will still not be able to open `d:\_tmp\data-link`. – Nux Aug 19 '16 at 11:18
  • 5
    That is because when a symbolic link gets evaluated client-side it would be pointing to d:\\_tmp\data on the client, not the server. – apraetor Sep 24 '16 at 12:13
  • I think the reason why it's weird is clear. But I agree with @Nux that it IS weird, at least in the case of relative symlinks. – Jon Coombs Mar 21 '17 at 22:36
  • 5
    `Complex talk hurts brain -- I like charts` I love this sentence, and the chart too. – Luke Jun 24 '19 at 01:08
1

Junction points store the volume as a GUID rather than as a drive letter. So if your drive letters change, the junction still points to the same target.

Dwedit
  • 241
  • 2
  • 3