Directory Symbolic Link or Junction

Forums Operating Systems Windows Server 2008 R2 Miscellaneous Directory Symbolic Link or Junction

Viewing 6 reply threads
  • Author
    Posts
    • #44170
      hoak
      Participant

      Which of these is more appropriate when linking directories locally across different volumes and/or partitions? Both seem to work virtually identically, and from the information I’ve been able to find the differences are low level and quite technical. So say I have a boot VHD on an NTFS partition (I actually do) and want to use a ‘Directory Symbolic Link’ or ‘Junction’ to offer access to an application on the main NTFS partition, again both work, and appear to do so identically, but is one method (mklink /d vs /j) better then the other in this example?

    • #51428

      @hoak wrote:

      Which of these is more appropriate when linking directories locally across different volumes and/or partitions?

      Either one will create a symbolic link between local directories. The difference between them is the mklink /d uses a soft link while mklink /j uses a hard link. A few restrictions for hard links is that both links must be on the same file system and remote sharing is not supported. Soft links allow access across remote storage shares but there is increased disk I/O overhead as a consequence. If you plan to use symbolic links to offer access to an application, the mklink /J link is preferable in your situation.

    • #51429
      hoak
      Participant

      @halladayrules wrote:

      Either one will create a symbolic link between local directories. The difference between them is the mklink /d uses a soft link while mklink /j uses a hard link. A few restrictions for hard links is that both links must be on the same file system and remote sharing is not supported. Soft links allow access across remote storage shares but there is increased disk I/O overhead as a consequence. If you plan to use symbolic links to offer access to an application, the mklink /J link is preferable in your situation.

      Hey halladayrules, thanks for responding, I appreciate it and you do ‘rule‘!

      😀

      I do understand these difference between Directory Symbolic Link and Junction as far and as in depth as your recitation goes, it’s pretty much the same info I was able to glean from Microsoft’s documentation on TechNet. What I don’t understand is your reasoning for saying a Junction would be better in the application described, where none of the differences I’ve been able to glean between a Directory Symbolic Link and Junction really matter in this instance? Please say more!

      😉

      Just reread your post; is the increse in disk i/o why you’d recommend going with Junctions in this example? I’d think the disk i/o difference would be neglagable, but don’t have any experince here…

      :geek:

    • #51430

      @hoak wrote:

      @halladayrules wrote:

      Either one will create a symbolic link between local directories. The difference between them is the mklink /d uses a soft link while mklink /j uses a hard link. A few restrictions for hard links is that both links must be on the same file system and remote sharing is not supported. Soft links allow access across remote storage shares but there is increased disk I/O overhead as a consequence. If you plan to use symbolic links to offer access to an application, the mklink /J link is preferable in your situation.

      Hey halladayrules, thanks for responding, I appreciate it and you do ‘rule‘!

      😀

      I do understand these difference between Directory Symbolic Link and Junction as far and as in depth as your recitation goes, it’s pretty much the same info I was able to glean from Microsoft’s documentation on TechNet. What I don’t understand is your reasoning for saying a Junction would be better in the application described, where none of the differences I’ve been able to glean between a Directory Symbolic Link and Junction really matter in this instance? Please say more!

      😉

      Just reread your post; is the increse in disk i/o why you’d recommend going with Junctions in this example? I’d think the disk i/o difference would be neglagable, but don’t have any experince here…

      :geek:

      My experience with this command line parameter is limited as well but I’ve seem to grasp and understand at the basic level like you have. A soft link is in essence a shortcut to the original file. If you delete the original file, the soft link is useless. A hard link is like a clone, if you delete the original file the file will not be deleted because the hard link is still pointing to the same bit of information of the hard drive. The information does not get deleted until both hard links and originals are gone. I think the website i got the research from has to be wrong. If the mklink /J was truly a “hard link” parameter then deleting the original file would still allow me to see it in the hard link. This is not the case. The test file gets deleted from both ends, which means the /J and /D parameters are both soft links!

      In this case they both use the same disk I/O usage, behave the same, so the only difference is their features. I would recommend using /D switch hence you have support across different partitions (C:,D:,E:,etc) remote shares, etc.

      Sorry for the inaccurate information.

    • #51431
      hoak
      Participant

      Well halladay, I’ve been doing more in-depth reading, and while still far from certain, I think the your first and intuitive response might be closer to the actual truth. Both of these are abstrats in the file system and do behave differently and probably have different i/o overhead, which is my biggest concern, though I haven’t been able to glean which way that goes.

      I think part of the problem is a lot of the documentation appears to be written by people that don’t really understand the vageries of Windows UNIX deravitives of symbolic links, junctions, and shortcuts — and they all are quite different at the low level. Still looking for some definitive documentation or word from ‘Thee Final Anuthority‘, will let ya know if I learn anything useful… Hopefully anyone else that beats me too it (which seems likely) will let me know what they discover as well…

      😐

    • #51432

      From what I have been able to gather from reliable sources:

      A hard link points to the actual file (it is cloned)
      A soft link points to just the pathname (aka a shortcut)

      The difference between the two is..

      A hard linked file can exist in multiple places at the same time.

      1 file… multiple locations. Let’s say you update a document in one location and hit save. Then all the other locations (hard links) will be updated as well. If one user with a hard link to that file accidentally deletes the file, it will not affect the other users and the data integrity and availability will remain.

      [attachment=0:lukjlb6o]hardlinkexample.jpg[/attachment:lukjlb6o]

      [attachment=1:lukjlb6o]softlinkexample.jpg[/attachment:lukjlb6o]

    • #51433
      hoak
      Participant

      @halladayrules wrote:

      From what I have been able to gather from reliable sources:

      A hard link points to the actual file (it is cloned)

      Yes but in the case of a directory, it appears to clone just the directory itself, not its contents, which works like a UNIX link on the FS level…

      @halladayrules wrote:

      A soft link points to just the pathname (aka a shortcut)

      Not quite from Microsoft’s and Mark Russinovich’s documentation, a shortcut is an actual file that includes direct path information, where as a soft link is still a low level file system junction that makes the ‘soft link‘ appear to the operating system as if the file or directory is on a local FS path…

      @halladayrules wrote:

      The difference between the two is..

      I’m aware of how the other differences are supposed to operate, what I want to understand is what’s going on at the FS level, and which perfoms better when used for local FS linking…

      :geek:

Viewing 6 reply threads
  • You must be logged in to reply to this topic.