When attempting to create a shortcut to another shortcut, Windows XP assigns the target of the original shortcut to the new shortcut. This happens even when I enter the target path manually, and I am left with a copy of the original shortcut. This is not what I want.
How can make a .lnk file point to another .lnk file directly? This form of double indirection would be very useful for managing shortcuts to files that move frequently.
Best Answer
I completely understand the utility of linking to links, and I have been searching for an easy solution as well. The best one I've come up with is to simply use Hardlinks, which point to the shortcut.lnk file. I've tested symbolic links (junctions are just for folders, not files, so they weren't tested) and these do NOT work (they are basically broken files when created, which fail to open).
Hardlinks have a number of advantages and disadvantages. The primary disadvantage is that they are almost impossible to backup easily (you need third party software or scripting to back them up to another dive or even to another location on the same drive). The primary advantage is that they automatically update when you modify the original file, so changing 1 shortcut file (new path/icon) changes all associated hardlinks as well [names for the hardlink, however, are unique, so changing a filename doesn't change the hardlink name and vice versa]. Another feature which is both an advantage and disadvantage of hardlinks is that changing icon/path for the hardlink (changing hardlink data) ALSO changes THE ORIGINAL. This does NOT include 'deleting the link itself' (the link can be deleted as any other file; without deleting the original file itself). This is advantageous because it keeps all the associated links synchronized, but it's disadvantageous in cases where the hardlink is stored in a vulnerable location, and it's data is maliciously modified, or a user error is made in modifying a single link's data. This change will be carried through to all hardlinked partners including the original. Frankly this behavior is generally useful, except in cases where you'd want a 'stable source reference' (1-way modification)
I've tested copying individual hardlinks and folders containing hardlinks, in windows explorer, and the result just creates dissociated shortcuts to the original data (no longer associated hardlinks, and therefore, don't change with modifications to the original link). I find this lack of simple copying extremely annoying, and the primary reason I'd be reluctant to use them extensively, but, if you only have a few for a specific purpose (like synchronizing links from a stable directory, to the desktop/taskbar/startmenu) they may still be a good solution (eventhough, they aren't really portable to other systems, without writing a script to automate their directory building). They DO, however, move around without breaking (you can move them anywhere in the file system, once they are created. You just can't 'copy' them). You can also make as many hardlinks to a single source as you want, but again, you can't easily 'copy-and-paste' you have to make a new hardlink from scratch for each 'copy' you want.
To make a hardlink, just open an elevated command prompt (.cmd opened to system32, or run .cmd as admin) and type:
Example:
It's good to designate the hardlink with the filetype it links to (like, here, .lnk, but for notepad documents hardlink.txt, or similar), because it's basically a mirroring of the original file, and windows explorer treats it as if it were the original (again, a useful behavior). I should also directly state that they are ONLY created through command prompt (or 3rd party software which gives a shellExtension or gui for the command). Also, they aren't a 'mirrored copy' of the original, they may show the original object's file sizes, but they intrinsically take up 0bytes of space on the drive; they are actually references stored to the MFT of the drive (which is also the reason they can't be made between 2 different partitions [which is another feature of them worth mentioning; but which is easily overcome with a clever combo of shortcuts, junctions, symlinks, and hardlinks used together in unison])
Frankly, I believe this is exactly what you are looking for, and it is a very useful feature. If you can script well, I'm sure it's not difficult to write a program which simply builds a hardlink directory as you desire (and treat that as a 'backup' or 'portability solution' for other systems). You might also be able to find 3rd party software to make all of these tasks easier, and overcome the intrinsic unwieldiness of working with hardlinks.