Talk:NTFS junction point

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Microsoft Windows / Computing  (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing (marked as Low-importance).
 

Example[edit]

See my edit titled "Incorrect Example".

SymLinks are not used in Vista or Server 2008 by Microsoft to maintain backwards compatibility with the directory structures of previous Windows versions. Instead, regular Directory Junctions are used, which have been present in NTFS since Windows 2000. I can only speculate why they chose to use Junctions instead of the new SymLink functionality, but I would guess it is tied into backwards compatibility. By using Junctions, if a user mounts a Vista/2k8 system volume on an older Windows version (e.g. due to dual-booting), the Junctions will still be visible and functional. This would not be the case with SymLinks, as only Vista and newer can interpret the NTFS metadata that corresponds to them. So, it probably comes down to not potentially confusing power users.


—Preceding unsigned comment added by 202.134.248.108 (talk) 16:22, 26 July 2008 (UTC)

Junction points seem to be a hidden feature of NTFS 5.0 :)

Please stop the FUD. They're documented in the standard Microsoft fashion. In short, that means it's not on Google (or MSDN), but in (for example) the relevant SDKs, one of them being the Platform SDK, as someone's already pointed out. I'll agree it's an underused and underdocumented feature though. --Ultomten (talk) 11:24, 26 November 2007 (UTC)

Undocumented by Microsoft as far as I know, and little documentation on the net otherwise, these can be used almost the same as symbolic links.

However since they are so underdocumented, it's hard to tell what happens when you perform file operations on them, eg copy, move, delete, etc... and whether the effect changes if these operations are instigated from explorer, console, programs, etc or different OS's (I believe WinXP uses NTFS 5.1, whereas Win2000 uses NTFS 5.0) - there could be hidden dangers which might risk your data.

That's the reason for the observed effects section, so please expand it if you get a chance to test things out.

Zarius 22:47, 23 Feb 2004 (UTC)


They are documented in Platform SDK, AFAIK. And NT Resource kit contained both the ln tool and the documentation for symlinks/hardlinks. --tyomitch 14:03, 10 September 2005 (UTC)


Regarding "Microsoft uses them internally to maintain backward naming convention compatibility for user's profile's among other things". This seems to be pure guesswork. On my Vista, NTFS Junction Points were created during installation to map folders like "Documents and Settings" to their new counterparts. However, they don't actually work, due to errors in the link targets, so I'm not sure what's up. This might be because I did an "upgrade" (from XP) and not a "regular installation", so I won't change anything on the page.

--Ultomten (talk) 11:24, 26 November 2007 (UTC)


Regarding the layout of the Observed effects section, I think it best laid out like this:

  • Win XP Pro -- Pro at the moment, since this is the OS I currently use & I can't test if XP Home has any different effects - given the data risk, I thought I'd play it safe and assume difference until proven otherwise)
    • deletion via blah has this effect
    • effect
    • etc
  • Win 2000
    • deletion via blah has this effect
    • move via blah has the same effect as Win XP Pro above
    • etc

This does involve some duplication of information, but makes it easier for someone to check out the effects on the OS they are currently running.

Zarius 22:47, 23 Feb 2004 (UTC)


Oops! :) On an earlier version of the page I stated that deleting via explorer was safe... it's not. The junction had just been transferred to the recycle bin, not actually deleted and therefore the files were still safe - until you empty the recycle bin :) Then *poof* there go all the files in the targeted directory :)

Zarius 23:36, 24 Feb 2004 (UTC)


Hmm... it seems a bit much to refer to them as junction points all the time (not to mention the typing :)) - but what's a better way to refer to them? I've been using both junction and JP's, leaning towards JP's.

Zarius 23:36, 24 Feb 2004 (UTC)


Here's some more info that might be relevant: (cut from Microsofts KB article Q262797)

The following technologies use reparse points:
  • Directory Junctions is a technology for a folder to be grafted into another folder on the same local computer. Directory Junctions work when they are mounted on the same volume. If a Directory Junction is mounted such that the target folder and host folder are on different Physical Disk resources, the resources must be in the same cluster group. The Physical Disk resource that contains the host folder should be dependent on the Physical Disk resource that contains the target folder. If the drive that contains the target folder does not come online, the drive that contains the host folder does not start.

Zarius 02:36, 25 Feb 2004 (UTC)


Vista does have the RMDIR command[edit]

Removed as this is incorrect:

  • Windows Vista no longer uses rmdir, but still has rd.
Confirmed on 7 here. 217.50.57.89 (talk) 11:18, 29 November 2010 (UTC)

Warnings?[edit]

I just noticed the warnings section on this page, is that really necessary? Some of it, like a mention of ACL could be included in the text, but since Wikipedia is not a manual, I don't think a disclaimer is appropriate. arienh4(Talk) 22:18, 29 July 2009 (UTC)

I like the warnings section, especially if you take into account the risk included and lack of documentation on the Internet.
The warnings section also shows, how the junction working changed over the NTFS specification 195.205.193.228 (talk) 01:47, 9 August 2009 (UTC)Czeciu

"Sync" terminology[edit]

I noticed a comment added into the page by TG2, concerning sync terminology: Note ** this "sync" idea is incorrect and should be removed. Sync refers to two distinct files, usually named the same and in different locations, which need to have the contents match. Junction points are references to a set of original files and file locations, not copies of files so this fails the "for all intents and purposes".

This is a fair point, but probably should have been placed here for discussion instead of directly on the page, so I'm removing it from there. Pj81381 (talk) 23:51, 11 December 2009 (UTC)

vs. hard link or symbolic link?[edit]

Could some add to the article how this differs (or doesn't) from the other two features that NTFS now implements? Also the "observed effects" section is WP:OR without refs. Pcap ping 09:35, 6 June 2010 (UTC)

One big difference I encountered is with shares. I created a symbolic link to another drive on the same server. It works on that server just fine. However the symbolic link was in a share. From the share, i.e. over the network, it didn't work. When I destroyed that symbolic link and created a directory junction instead, it works on the server, and from the share. However, since this is original research, I can't add it to the main article. --Rsberzerker (talk) 15:10, 23 October 2014 (UTC)

Symbolic links cannot be created with Disk Management; but junctions can![edit]

I don't know if this is useful to add in the article. AFAIK, symbolic links (in Vista/7) can only be created with built-in tools by using mklink on the command line, nothing else. Or you need to use external software for that. Junction points, however, can be created using the GUI provided in the Disk Management application (formerly "fileman.exe"). -andy 217.50.57.89 (talk) 11:15, 29 November 2010 (UTC)