Hi. Can you recommend a tool for repairing broken lnk files (i.e. update lnk to moved target) ?
As always, if that exists, a TC-centric solution would be preferable (if possible for XP)
Many thanks.
Or is there a way to prevent broken shortcuts in the first place? I never quite understood how on Earth OS designers could come up with such a broken thing. As soon as you move/rename the target lnks are broken. There is a Windows service called "Distributed Link Tracking Client" which is supposed to "maintain links between NTFS files within a computer" when running in the background, but actually fails to do so. In fact the links are NOT maintained, but when the service is running, the broken link does no fail immediately but a background search is triggered. If successful the link destination is updated and cached *internally*, but the lnk file itself remains unchanged bitwise and thus is still broken. And the internal cache only stores a limited number of updated link targets.
So I guess this can only be done via file system logging but I am not even sure NTFS supports this to such an extent.
repairing broken lnk files
Moderators: Hacker, petermad, Stefan2, white
chrizoo
The problem is in the original design of one-way link. You cannot quickly get the complete list of all the links that point to some specific file, it is simply not stored anywhere. So, implementing what you ask for would require: a) some database or other storage where all the link files will be listed, b) a filter driver that will track all the file operations on low level, check the database for presence of any links pointing to the file being moved and update the database and links themselves. And don't forget about links which point to network locations and which may be physically unable to know that anything changed (because e.g. network was offline at the moment when moving took place).
All in all, that's a quite tough task, and I don't think anybody bothered to implement it, the gain just won't pay for the efforts (IMHO, of course). Unfortunately, Distributed Link Tracking Client is not exactly what you thought it is. You can read about it in MS KB article; generally it updates the link only when you try to resolve it, and the link is discovered to be invalid.
BTW, it's not a Windows-specific problem. In Linux there are desktop-files which play actually the same role as LNK files do in Windows, so when they contain some path, and the target is moved/renamed, these desktop-files become invalid too. The same concerns the *NIX symbolic links and Windows reparse points. It's all the same basic design: something that points to something else without back-reference.
The problem is in the original design of one-way link. You cannot quickly get the complete list of all the links that point to some specific file, it is simply not stored anywhere. So, implementing what you ask for would require: a) some database or other storage where all the link files will be listed, b) a filter driver that will track all the file operations on low level, check the database for presence of any links pointing to the file being moved and update the database and links themselves. And don't forget about links which point to network locations and which may be physically unable to know that anything changed (because e.g. network was offline at the moment when moving took place).
All in all, that's a quite tough task, and I don't think anybody bothered to implement it, the gain just won't pay for the efforts (IMHO, of course). Unfortunately, Distributed Link Tracking Client is not exactly what you thought it is. You can read about it in MS KB article; generally it updates the link only when you try to resolve it, and the link is discovered to be invalid.
BTW, it's not a Windows-specific problem. In Linux there are desktop-files which play actually the same role as LNK files do in Windows, so when they contain some path, and the target is moved/renamed, these desktop-files become invalid too. The same concerns the *NIX symbolic links and Windows reparse points. It's all the same basic design: something that points to something else without back-reference.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
Distributed Link Tracking Client is supposed to (direct quote from your MS KB link):
Normally the DLTC service should "maintain links between NTFS files within a computer": either on the fly in real time, OR upon demand when the user accesses a .lnk file pointing to an outdated location.
The only problem is ... it doesn't work (see OP).
So given that the OS doesn't do its job, I thought TC users here would know about a 3rd party program doing the repair work. After all TC makes creation of .lnk files very easy (CTLR+SHIFT+F5), so my guess was that many TC users have .lnk files and short of never moving files, .lnk files are BOUND to become outdated sooner or later ! So almost everyone of you ought to be confronted with this problem.
Just think of it for a second:
There are literally thousands of programs parsing the Windows registry, finding registry entries with invalid file paths (e.g. C://some_path//some_inexisting_file.ext) and then searching for possible file matches to the user:
http://images.snapfiles.com/screenfiles/regfirstaid.gif
It's the same principle:
(A) registry entry » points to path\filename
(B) .lnk file » points to path\filename
If there are programs which scan the HDD looking for files to fix (A) it's technically also possible to fix (B), so where is such a program and why is it so hard to find ??
That's exactly what I wrote in OP.track links to files on NTFS-formatted partitions. Distributed Link Tracking tracks links in scenarios where the link is made to a file on an NTFS volume, such as shell shortcuts [i.e. lnk files]. If that file is renamed, moved to another volume on the same computer, moved to another computer, or moved in other similar scenarios, Windows uses Distributed Link Tracking to find the file. When you access a link that has moved, Distributed Link Tracking locates the link; you are unaware that the file has moved, or that Distributed Link Tracking is used to find the moved file.
Normally the DLTC service should "maintain links between NTFS files within a computer": either on the fly in real time, OR upon demand when the user accesses a .lnk file pointing to an outdated location.
The only problem is ... it doesn't work (see OP).
So given that the OS doesn't do its job, I thought TC users here would know about a 3rd party program doing the repair work. After all TC makes creation of .lnk files very easy (CTLR+SHIFT+F5), so my guess was that many TC users have .lnk files and short of never moving files, .lnk files are BOUND to become outdated sooner or later ! So almost everyone of you ought to be confronted with this problem.
Just think of it for a second:
There are literally thousands of programs parsing the Windows registry, finding registry entries with invalid file paths (e.g. C://some_path//some_inexisting_file.ext) and then searching for possible file matches to the user:
http://images.snapfiles.com/screenfiles/regfirstaid.gif
It's the same principle:
(A) registry entry » points to path\filename
(B) .lnk file » points to path\filename
If there are programs which scan the HDD looking for files to fix (A) it's technically also possible to fix (B), so where is such a program and why is it so hard to find ??
Actually no. For me the only reason to use .lnk files is to launch some applications or to access a few important folders. And because in general there is no need to move them, there are no problems with links. And if from time to time I need to move some folder/app, updating its link manually is no problem at all.chrizoo wrote:So almost everyone of you ought to be confronted with this problem.
Also even if I found some tool, that would try to guess new targets of links, I wouldn't use it because I would still have to check all those links manually.
Windows 10 Pro x64, Windows 11 Pro x64