“directory junction” vs “directory symbolic link”?Symbolic link typesHow can I delete a symbolic...
"before" and "want" for the same systemd service?
A Trivial Diagnosis
C++ copy constructor called at return
Is there a RAID 0 Equivalent for RAM?
Has any country ever had 2 former presidents in jail simultaneously?
How to preserve electronics (computers, iPads and phones) for hundreds of years
Stack Interview Code methods made from class Node and Smart Pointers
Is a Java collection guaranteed to be in a valid, usable state after a ConcurrentModificationException?
How do you make your own symbol when Detexify fails?
A variation to the phrase "hanging over my shoulders"
I found an audio circuit and I built it just fine, but I find it a bit too quiet. How do I amplify the output so that it is a bit louder?
Circuit Analysis: Obtaining Close Loop OP - AMP Transfer function
How can I write humor as character trait?
What are some good ways to treat frozen vegetables such that they behave like fresh vegetables when stir frying them?
awk assign to multiple variables at once
Why does AES have exactly 10 rounds for a 128-bit key, 12 for 192 bits and 14 for a 256-bit key size?
Will number of steps recorded on FitBit/any fitness tracker add up distance in PokemonGo?
Why should universal income be universal?
Change the color of a single dot in `ddot` symbol
What to do when eye contact makes your coworker uncomfortable?
Why the "ls" command is showing the permissions of files in a FAT32 partition?
Shouldn’t conservatives embrace universal basic income?
Microchip documentation does not label CAN buss pins on micro controller pinout diagram
Multiplicative persistence
“directory junction” vs “directory symbolic link”?
Symbolic link typesHow can I delete a symbolic link?Is it safe to delete from C:WindowsInstaller?What is the difference between Symbolic Link and Shortcut?What is the difference between NTFS hard links and directory junctions?What are the various link types in Windows? How do I create them?How to synchronize directories outside the Google Drive directoryAccess is denied on mklinkFollowing a remote symbolic link via Windows SharesHow do I figure out if a link is a symbolic link, a hard link, or a directory junction in Windows?Scenario - NTFS Symbolic Link or Junction?Use a symbolic link to create a new symbolic linkSymbolic link or Junction to a Networked Samba ShareWindows 8 Command Prompt Symbolic Link AccidentHow can I create a symbolic link from Windows that will work under Linux?What kind of links (symbolic, hard, junction pts…) for multiple cloud backups?Use Junction or symbolic link to “rename” NTFS directoryNeed symbolic link functionality WITHOUT symbolic pathnameCreate a relative symbolic link in Windows 10 for file copiessymbolic link for existing directory
In the context of NTFS:
MKLINK [[/D] | [/H] | [/J]] Link Target
/DCreates a directory symbolic link. Default is a file symbolic link./HCreates a hard link instead of a symbolic link./JCreates a Directory Junction.Linkspecifies the new symbolic link name.Targetspecifies the path (relative or absolute) that the new link refers to.
Isn't a directory junction the exact same thing as a directory symbolic link?
What's the difference between
mklink /D f1 f2andmklink /J f1 f2?
Since a "directory" is actually just a file, what would be the difference between a directory symbolic link and a file symbolic link?
windows filesystems ntfs symbolic-link
add a comment |
In the context of NTFS:
MKLINK [[/D] | [/H] | [/J]] Link Target
/DCreates a directory symbolic link. Default is a file symbolic link./HCreates a hard link instead of a symbolic link./JCreates a Directory Junction.Linkspecifies the new symbolic link name.Targetspecifies the path (relative or absolute) that the new link refers to.
Isn't a directory junction the exact same thing as a directory symbolic link?
What's the difference between
mklink /D f1 f2andmklink /J f1 f2?
Since a "directory" is actually just a file, what would be the difference between a directory symbolic link and a file symbolic link?
windows filesystems ntfs symbolic-link
2
Related: superuser.com/q/347930/24500
– surfasb
Dec 29 '11 at 13:05
add a comment |
In the context of NTFS:
MKLINK [[/D] | [/H] | [/J]] Link Target
/DCreates a directory symbolic link. Default is a file symbolic link./HCreates a hard link instead of a symbolic link./JCreates a Directory Junction.Linkspecifies the new symbolic link name.Targetspecifies the path (relative or absolute) that the new link refers to.
Isn't a directory junction the exact same thing as a directory symbolic link?
What's the difference between
mklink /D f1 f2andmklink /J f1 f2?
Since a "directory" is actually just a file, what would be the difference between a directory symbolic link and a file symbolic link?
windows filesystems ntfs symbolic-link
In the context of NTFS:
MKLINK [[/D] | [/H] | [/J]] Link Target
/DCreates a directory symbolic link. Default is a file symbolic link./HCreates a hard link instead of a symbolic link./JCreates a Directory Junction.Linkspecifies the new symbolic link name.Targetspecifies the path (relative or absolute) that the new link refers to.
Isn't a directory junction the exact same thing as a directory symbolic link?
What's the difference between
mklink /D f1 f2andmklink /J f1 f2?
Since a "directory" is actually just a file, what would be the difference between a directory symbolic link and a file symbolic link?
windows filesystems ntfs symbolic-link
windows filesystems ntfs symbolic-link
edited Feb 21 '18 at 17:43
Pierre Arnaud
3991521
3991521
asked Oct 5 '11 at 3:28
PacerierPacerier
11.2k62156242
11.2k62156242
2
Related: superuser.com/q/347930/24500
– surfasb
Dec 29 '11 at 13:05
add a comment |
2
Related: superuser.com/q/347930/24500
– surfasb
Dec 29 '11 at 13:05
2
2
Related: superuser.com/q/347930/24500
– surfasb
Dec 29 '11 at 13:05
Related: superuser.com/q/347930/24500
– surfasb
Dec 29 '11 at 13:05
add a comment |
3 Answers
3
active
oldest
votes
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
\Alicec$myjp will point to \Alicec$targetfolder
but the symbolic link
\Alicec$mysymlink will point to \Bobc$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.
13
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 5 '11 at 4:02
10
@MatthewSteeples do you mean that if I create a symbolic linkC:testlink(which points toC:teston my computer) and someone remote access my computer and clicks onC:testlink, it would resolve to theC:teston HIS computer, Whereas if I create a directory junctionC:testlink(which points toC:teston my computer), and someone remote access my computer and clicks onC:testlink) it would lead him to theC:teston my computer? Or did I get it the wrong way round?
– Pacerier
Oct 5 '11 at 8:19
9
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
5
@MatthewSteeples but couldn't we create a directory junctionC:MyNetworkSharewhich points to\AliceShareas well?
– Pacerier
Oct 7 '11 at 10:44
7
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
|
show 23 more comments
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]
| |
\SvrMyLink | C:T_Dir | C:T_Dir | [leads back to local]
\SvrMyJunc | C:T_Dir | *** Must create and point local ***
| |
C:MyLink | \Sv2T_Dir | \Sv2T_Dir | Error*1
C:MyJunc | \Sv2T_Dir | *** Error - Must point local ***
| |
\SvrMyLink | \Sv2T_Dir | Error*1
\SvrMyJunc | \Sv2T_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
1
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directoryd:_tmpdata. Create link like so:d:_tmp>mklink /d data-link data. Remote user has full access tod:_tmpand all its subfolders BUT he will still not be able to opend:_tmpdata-link.
– Nux
Aug 19 '16 at 11:18
2
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata 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
add a comment |
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.

**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)

From SS64 page on MKLink

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.
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
add a comment |
protected by Community♦ May 31 '16 at 3:50
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
\Alicec$myjp will point to \Alicec$targetfolder
but the symbolic link
\Alicec$mysymlink will point to \Bobc$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.
13
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 5 '11 at 4:02
10
@MatthewSteeples do you mean that if I create a symbolic linkC:testlink(which points toC:teston my computer) and someone remote access my computer and clicks onC:testlink, it would resolve to theC:teston HIS computer, Whereas if I create a directory junctionC:testlink(which points toC:teston my computer), and someone remote access my computer and clicks onC:testlink) it would lead him to theC:teston my computer? Or did I get it the wrong way round?
– Pacerier
Oct 5 '11 at 8:19
9
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
5
@MatthewSteeples but couldn't we create a directory junctionC:MyNetworkSharewhich points to\AliceShareas well?
– Pacerier
Oct 7 '11 at 10:44
7
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
|
show 23 more comments
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
\Alicec$myjp will point to \Alicec$targetfolder
but the symbolic link
\Alicec$mysymlink will point to \Bobc$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.
13
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 5 '11 at 4:02
10
@MatthewSteeples do you mean that if I create a symbolic linkC:testlink(which points toC:teston my computer) and someone remote access my computer and clicks onC:testlink, it would resolve to theC:teston HIS computer, Whereas if I create a directory junctionC:testlink(which points toC:teston my computer), and someone remote access my computer and clicks onC:testlink) it would lead him to theC:teston my computer? Or did I get it the wrong way round?
– Pacerier
Oct 5 '11 at 8:19
9
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
5
@MatthewSteeples but couldn't we create a directory junctionC:MyNetworkSharewhich points to\AliceShareas well?
– Pacerier
Oct 7 '11 at 10:44
7
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
|
show 23 more comments
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
\Alicec$myjp will point to \Alicec$targetfolder
but the symbolic link
\Alicec$mysymlink will point to \Bobc$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.
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
\Alicec$myjp will point to \Alicec$targetfolder
but the symbolic link
\Alicec$mysymlink will point to \Bobc$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.
edited Apr 24 '17 at 23:06
community wiki
8 revs, 3 users 72%
Harry Johnston
13
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 5 '11 at 4:02
10
@MatthewSteeples do you mean that if I create a symbolic linkC:testlink(which points toC:teston my computer) and someone remote access my computer and clicks onC:testlink, it would resolve to theC:teston HIS computer, Whereas if I create a directory junctionC:testlink(which points toC:teston my computer), and someone remote access my computer and clicks onC:testlink) it would lead him to theC:teston my computer? Or did I get it the wrong way round?
– Pacerier
Oct 5 '11 at 8:19
9
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
5
@MatthewSteeples but couldn't we create a directory junctionC:MyNetworkSharewhich points to\AliceShareas well?
– Pacerier
Oct 7 '11 at 10:44
7
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
|
show 23 more comments
13
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 5 '11 at 4:02
10
@MatthewSteeples do you mean that if I create a symbolic linkC:testlink(which points toC:teston my computer) and someone remote access my computer and clicks onC:testlink, it would resolve to theC:teston HIS computer, Whereas if I create a directory junctionC:testlink(which points toC:teston my computer), and someone remote access my computer and clicks onC:testlink) it would lead him to theC:teston my computer? Or did I get it the wrong way round?
– Pacerier
Oct 5 '11 at 8:19
9
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
5
@MatthewSteeples but couldn't we create a directory junctionC:MyNetworkSharewhich points to\AliceShareas well?
– Pacerier
Oct 7 '11 at 10:44
7
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
13
13
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 5 '11 at 4:02
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 5 '11 at 4:02
10
10
@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 5 '11 at 8:19
@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 5 '11 at 8:19
9
9
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
@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 \AliceShare
– Matthew Steeples
Oct 6 '11 at 14:57
5
5
@MatthewSteeples but couldn't we create a directory junction
C:MyNetworkShare which points to \AliceShare as well?– Pacerier
Oct 7 '11 at 10:44
@MatthewSteeples but couldn't we create a directory junction
C:MyNetworkShare which points to \AliceShare as well?– Pacerier
Oct 7 '11 at 10:44
7
7
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
@Pacerier, no, junction points have to be local.
– Harry Johnston
Oct 8 '11 at 0:05
|
show 23 more comments
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]
| |
\SvrMyLink | C:T_Dir | C:T_Dir | [leads back to local]
\SvrMyJunc | C:T_Dir | *** Must create and point local ***
| |
C:MyLink | \Sv2T_Dir | \Sv2T_Dir | Error*1
C:MyJunc | \Sv2T_Dir | *** Error - Must point local ***
| |
\SvrMyLink | \Sv2T_Dir | Error*1
\SvrMyJunc | \Sv2T_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
1
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directoryd:_tmpdata. Create link like so:d:_tmp>mklink /d data-link data. Remote user has full access tod:_tmpand all its subfolders BUT he will still not be able to opend:_tmpdata-link.
– Nux
Aug 19 '16 at 11:18
2
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata 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
add a comment |
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]
| |
\SvrMyLink | C:T_Dir | C:T_Dir | [leads back to local]
\SvrMyJunc | C:T_Dir | *** Must create and point local ***
| |
C:MyLink | \Sv2T_Dir | \Sv2T_Dir | Error*1
C:MyJunc | \Sv2T_Dir | *** Error - Must point local ***
| |
\SvrMyLink | \Sv2T_Dir | Error*1
\SvrMyJunc | \Sv2T_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
1
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directoryd:_tmpdata. Create link like so:d:_tmp>mklink /d data-link data. Remote user has full access tod:_tmpand all its subfolders BUT he will still not be able to opend:_tmpdata-link.
– Nux
Aug 19 '16 at 11:18
2
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata 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
add a comment |
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]
| |
\SvrMyLink | C:T_Dir | C:T_Dir | [leads back to local]
\SvrMyJunc | C:T_Dir | *** Must create and point local ***
| |
C:MyLink | \Sv2T_Dir | \Sv2T_Dir | Error*1
C:MyJunc | \Sv2T_Dir | *** Error - Must point local ***
| |
\SvrMyLink | \Sv2T_Dir | Error*1
\SvrMyJunc | \Sv2T_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
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]
| |
\SvrMyLink | C:T_Dir | C:T_Dir | [leads back to local]
\SvrMyJunc | C:T_Dir | *** Must create and point local ***
| |
C:MyLink | \Sv2T_Dir | \Sv2T_Dir | Error*1
C:MyJunc | \Sv2T_Dir | *** Error - Must point local ***
| |
\SvrMyLink | \Sv2T_Dir | Error*1
\SvrMyJunc | \Sv2T_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
edited Aug 3 '16 at 17:39
answered Oct 22 '15 at 19:03
Still.TonyStill.Tony
687718
687718
1
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directoryd:_tmpdata. Create link like so:d:_tmp>mklink /d data-link data. Remote user has full access tod:_tmpand all its subfolders BUT he will still not be able to opend:_tmpdata-link.
– Nux
Aug 19 '16 at 11:18
2
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata 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
add a comment |
1
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directoryd:_tmpdata. Create link like so:d:_tmp>mklink /d data-link data. Remote user has full access tod:_tmpand all its subfolders BUT he will still not be able to opend:_tmpdata-link.
– Nux
Aug 19 '16 at 11:18
2
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata 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
1
1
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directory
d:_tmpdata. 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:_tmpdata-link.– Nux
Aug 19 '16 at 11:18
That is so weird. Even relative symbolic links don't work remotely. E.g. I create a directory
d:_tmpdata. 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:_tmpdata-link.– Nux
Aug 19 '16 at 11:18
2
2
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata on the client, not the server.
– apraetor
Sep 24 '16 at 12:13
That is because when a symbolic link gets evaluated client-side it would be pointing to d:_tmpdata 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
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
add a comment |
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.

**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)

From SS64 page on MKLink

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.
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
add a comment |
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.

**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)

From SS64 page on MKLink

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.
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
add a comment |
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.

**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)

From SS64 page on MKLink

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

**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)

From SS64 page on MKLink

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.
edited 6 mins ago
answered Feb 2 '18 at 16:30
u8itu8it
54957
54957
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
add a comment |
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
Anyone tested the processing speed of Junctions vs Symbolic Links?
– 1000Gbps
Sep 1 '18 at 13:59
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
The pros/cons chart was extremely helpful, thank you!
– GordonM
Sep 20 '18 at 15:52
add a comment |
protected by Community♦ May 31 '16 at 3:50
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
2
Related: superuser.com/q/347930/24500
– surfasb
Dec 29 '11 at 13:05