LinkShell Extension & ln.exe
Last Updated May 2, 2014
15th Anniversary It all started 15 years ago with a small project, just to play a bit with explorer and hardlinks. Over the years it grew into a project which reassembles a NTFS swiss army knife. It handles not just Hardlinks, but Junctions, Symbolic Links and Mountpoints and all the usecases one can do.

Unfortunatley Microsoft put Hardlinks, Junction and Symbolic Links primitives into the operating system but completley forgot the things which can be done with these primitives. As soon as you have used hardlinks, and e.g. wanted to copy them with Windows-means to a different drive, the mess would begin, because one would break all hardlinks during the copy. There are many other issues like this, and this is the point where LinkShellExtension and its commandline sibling ln.exe jump in.

But not only jump in, but also go ahead and implement uses cases, like the famous delorean copy, which is an incremental hardlink based backup solution. Some other vendors call very similar functionality Time Machine.... BTW: Have you ever guessed why it is called Delorean Copy? Knowing that a Delorean and a Flux Compensator was the first working time machine should give you a hint;-)

In the meantime I jumped deep into the Win32 filesystem API, sometimes deeper than it is allowed. LSE and ln.exe bypass the Kernel32 API in wide ranges and rely on Ntdll.dll to improve speed and do things which can't be done that easy otherwise.

I don't know how many times my tools have been downloaded, but Link Shell Extension and ln.exe are quite popular on many free/shareware download sites, like heise, CNet .... Both tools found its way also into many small articles of magazines and accompanying DVDs.

From the feedback and questions I received, I know that those two beasts are heavily used, even in semi-professional use cases and for sure hobbiest areas.

So .... enough said, use it have fun, be happy that these beasts save your time and celebrate!

15th Anniversary

Link Shell Extension


Creating and keeping many Delorean Copies in a Delorean Set is something which is fairly simple, and even when it comes to deleting a specific Delorean Copy from a Delorean Set it is easy. Simply press delete in Explorer, or use the --deeppathdelete option from ln.exe:

Deleting Delorean Copies

Wait! It is easy if a Delorean Copy contains not files with ReadOnly attributes. Otherwise it's getting sophisticated:
(Management summary: ln.exe --deeppathdelete can do it from 2.873 on)

Deleting Delorean Copies - Use Case

  1. A Source was used to create three successive Delorean Copies: Bkp1,Bkp2,Bkp3. File B is ReadOnly in the Source and in all Delorean Copies. So far so good.

  2. When it comes to delete Bkp2 the Readonly attribute of Bkp2/B has to be removed, otherwise deletion is impossible.

  3. Due to the fact that all siblings of a hardlink share the same attribute and the same date, the readonly attributes of Bkp1/B and Bkp3/B are also 'changed'. This is shown via the blue dotted lines. Called it 'Hardlink Attribute Teleportation'

  4. This results now in having a different attribute in Bkp1/B and Bkp3/B than in Source/B. This is shown via the grey dotted line.

  5. A fourth delorean copy with Source and Bkp3 as Backup to Bkp4 is created.

  6. Since the attributes of Bkp3/B and Source/B are different, the file Bkp4/B was copied over freshly from Source/B. So there is no hardlink between Bkp3/B and Bkp4/B, which is shown with the light red dotted line, and which is the basic problem.

So how to overcome this:
  1. Before deleting Bkp2/B retrieve at least one hardlink sibling, e.g. Bkp1/B

  2. Delete Bkp2/B

  3. Restore the attribute of Bkp2/B to one hardlink sibling, which has been retrieved in 1. e.g. Bkp1/B and rely on Hardlink Attribute Teleportation, so that it spreads the all other siblings.

Basically this is what the --deeppathdelete option does. Well this only works with Windows7 and greater, because retrieval of hardlink siblings is (currently) not that efficient with e.g WindowsXP.