The incredible world of NTFS Junctions... And the associated "issues"

[(Shovel)]

I though I was on to something with this... erm, no such luck though, as I shall explain. This may be of some interest to some of you though, so I'll just write this up to let you know.

Many (most?) of the Tech Forum regs will be familar with symbolic links in *nix - on an external level it allows you to jump from one part of the system to another transparently. I think a similar effect can be implemented by mounting various separate parts of the filesystem to folders within itself. That is *nix though.

A while back I was attempting to move the entire "Documents and Settings" folder from the default C:\ partition to a separate disk on XP Home. The installation doesn't allow anything clever in this respect, you just have to do as you're told, so you load up with your first user account stuck on the C:\. You can aparently use a registry tool to rename every reference to C:\Documents and Settings to a different path, but this has issues and is not bullet proof. Absence from Windows is the above mentioned "synbolic links" - or so I thought.

Enter a Windows 2000 Resource Kit program called "linkd.exe". I have no idea whether it is Microsoft or not, though it may as well be. It's a sensible command line tool taking a minimum of arguments:

linkd Source Destination

Visually, it creates a folder (Source) and makes it physically point to the path "Destination". This is not a Windows shell shortcut type either, it's all based in the lower reaches of the NTFS file system - therefore it is fairly transparent to Windows. Well, almost.

Here's a demonstration:

D:\bmpw\Documents\Resources\Resource>linkd D:\Linkd E:\
Link created at: D:\Linkd

If I now go to the root of D, and dir I get fed:

D:\>dir
 Volume in drive D is FILES
 Volume Serial Number is 9CB4-8421

 Directory of D:\

02/06/2003  22:42    <DIR>          All Users
02/06/2003  22:41    <DIR>          bmpw
02/06/2003  17:54    <DIR>          Lin
03/06/2003  00:43    <JUNCTION>     Linkd
               0 File(s)              0 bytes
               4 Dir(s)   6,073,053,184 bytes free

D:\>

Windows does recognise it then, it's a "Junction" aparently. I'm yet to hunt through Microsoft Technet to see whether they acknowledge the existance of Junctions, but as a "useful future prospect" I think it ranks highly.

And so to the enevitable downfall...

Using linkd.exe, a fresh install of XP Home, an aquired copy of the Windows XP OEM Preinstallation Environment CD (this boots a WinXP Pro Command Prompt, stand alone from any installed system). I booted to the OEMPE to copy my user files from "C:\Documents and Settings" to the root of D:\ (xcopy is a fantastic little tool with the /h modifier to copy hidden and system files).
Then, I removed the "Documents and Settings" directory. Now, using linkd as above, I create a Junction called "C:\Documents and Settings" and make it point to D:\.
If I cd to C:\Documents and Settings, the path reads "C:\Documents and Settings", and it's as if it is a folder on the C: Drive. So far, so clever.

Reboot into the installed XP system and it logs in seemlessly, as if XP didn't even know the difference, and I'd argue that it probably doesn't.

I don't know what the performace hit is like - e.g. I don't know how much processing is involved to link from one place to another. It's done in the File System, rather than a response by the Windows shell, so it should be pretty quick - well, comparatively.

Initially it worked - I could browse "C:\Documents and Settings" as if nothing had changed, safe in the knowledge that it was jumping to my second disk transparently. However, there's BIG problems.

It works fine when browsing in Explorer, you can create, open and delete files as normal. However, there appears to big a bug with deleting folders. At every attempt it reports "Access Denied". Going to to true path on D:\ had no issues with deleting though.
Then I came to install some drivers into my fresh system. On go some Detenator FX, then reboot when prompted. Sadly, the machine wouldn't boot. It froze on the startup screen. Going back into the OEMPE and carefully putting everything back how it was let me boot up again, again as if nothing had changed, but minus my once seemless Junction.

This probably all seems a bit pointless now, seeing as I've written an awful lot and then told you all that it doesn't work after all. There's a reason for it. Firstly, have any others come across Junctions before? And does anyone know if MS are actually going to implement them fully in the future?

I think that maybe they may still be of some use, but not for system critical operation like "Documents and Settings" and "Program Files".

If anyone is interested in seeing if my problems are the rule, rather than exceptional, linkd.exe is available in various places, though I sourced it from: http://www.dynawell.com/reskit/microsoft/win2000/linkd.zip
The source page: http://www.dynawell.com/support/ResKit/win2k.asp is packed full of admin level utilities for NT5.x (2000/XP) tweaking. I've not played with the others yet though.

I hope this interested someone, cause I think I've just written far to much for something that doesn't work right...

 

[Testin da Cable]

it's a bit rancid that you're not allowed to move stuff like that imo. reeks of too much ezzefuse. that linkd program sounds like a step in the right direction though; if I'd had a penny for every time I've wished windows had a properly implemented soft/hard link facility I'd be a rich man today.

 

[xane]

I've encountered this situation before, where I work we use "unified" make files to build applications and thet are supposed to work on a wide range of platforms, including *nix (Solaris) and Windows (NT).

Whilst it is true NTFS supports softlinks, there is no way we could get it working satisfactorily with Windows NT.

Things have probably moved on a bit, this was using NT 4.

I was wondering if linkd.exe has both "soft" (symbolic) and "hard" linking, maybe if it does you could try using the other one to what you used before.

One of the reasons why I think this is so difficult is that normally Windows uses variables for all its "root" directories, like %windows% to designate the main Windows directory, etc. Whereas in the registry "Documents and Settings" looks to be hardcoded.

 

[MYstIC G]

Originally posted by (Shovel)
A while back I was attempting to move the entire "Documents and Settings" folder from the default C:\ partition to a separate disk on XP Home. The installation doesn't allow anything clever in this respect, you just have to do as you're told, so you load up with your first user account stuck on the C:\. You can aparently use a registry tool to rename every reference to C:\Documents and Settings to a different path, but this has issues and is not bullet proof. Absence from Windows is the above mentioned "synbolic links" - or so I thought.

On XP, right click, properties, "Target", change the folder..... of course this has to be done for every fucking user, but it does the job

 

[(Shovel)]

Mystic G: That must be another one of the "Home users would never want to do that" things, that XP Home neglects to provide.

 

[(Shovel)]

Originally posted by xane
I was wondering if linkd.exe has both "soft" (symbolic) and "hard" linking, maybe if it does you could try using the other one to what you used before.

From what I've been able to find, it only does the one type. I'm assuming that it is soft - though I concede that I don't know the difference.

 

[FatBusinessman]

I was under the impression (from my Operating Systems lecture course) that you couldn't span hard links across partitions anyway?

 

[Testin da Cable]

A hard link to a file is indistinguishable from the file itself. When a hard link is made, then the i-numbers of two different directory file entries point to the same inode. For that reason, hard links cannot span across file systems. A soft link (or symbolic link) provides an indirect pointer to a file. A soft link is implemented as a directory file entry containing a pathname. Soft links are distinguishable from files, and can span across file systems.

 

[xane]

The main difference is when you delete a soft link it only deletes the link itself, but when you delete a hard link you actually delete the file (and all the links).