Shortcut broken after moving file

If I create a shortcut to a file and then subsequently move the file,
the shortcut no longer works (error message: "The item ... that this
shortcut refers to has been changed or moved, so this shortcut will no
longer work properly.") When I do this on my XP-Pro machine, XP will
generally find the moved file and update the shortcut; if it can't find
the file, it will give me the option to browse for the moved file.
Vista, on the other hand, either makes no effort to find the file or
just isn't very good at finding it; furthermore, it doesn't give me the
option to browse; it just displays the error message with "Do you want
to delete this shortcut? Yes/No". Is there something that needs to be
set or turned on (a registry key, maybe?) to enable Vista to find the
moved file?
(Vista Home Premium)

No way. You are competely wrong there. It will NEVER find the moved
file.

True. But it never looked for the file anyway.

The PEBKAC needs to be turned off

Did you try it?
I have a shortcut to a game on my desktop. I moved the exe file it was
linked to into another folder, and the shortcut changed accordingly and
opened the file correctly.
I also moved a folder to a different drive, and the shortcut to it changed
accordingly.
It probably won't do it for most installed programs, but it should for
simple .exe, .bat, folders etc.

That won't work with shortcuts. You probably had the actual .EXE file
on your desktop. THAT would be followed when moved.

That is just like the above.

It will not do with a SHORTCUT.

You no doubt have the arrow removed from shortcuts so you can't tell
the difference between a shortcut and the actual file/folder.


Nope. It's a shortcut.
I don't remove the arrow.
And it works.
Try it.

Well, let's see. In XP-Pro, I create a shortcut to a PDF file, then move
the PDF file to another folder. I look at the properties of the shortcut
and they say the file is in the original folder. Then I double click the
shortcut, and lo and behold, the file opens up in Acrobat. I look at the
properties of the shortcut again and they have changed to say that the
file is in the new folder.

Gee, Paul, it sure -*seems*- like XP found the moved file. You might
want to consider getting a clue before you attempt to berate someone
else's post in the future.

In case anyone encounters the same problem...

After a little investigation, it turned out that the Distributed Link
Tracking Client was the culprit -- it was not running. Apparently this
is the Vista service that keeps track of files when they're moved. After
restarting it, Vista can now correctly find a moved file that a shortcut
points to and update the shortcut accordingly.

Hi, I'm having this problem also. I've tried restarting the computer, and went back to the file and opened it, yet I get the error again.

The item "....." that this shortcut refers to has been changed or removed, so this shortcut will no longer work properly.

Do you want to delete this shortcut?

I also tried system restore, which did not work.

Actually, what happened was I accidentally deleted my Pictures folder, containing more folders. I went to the recycle bin and restored it, thinking everything was fine. But instead, only a few folders were restored. Then I searched the lost folders, which Vista found, but when I tried opening it, I got the error.

Does anyone know the solution to this problem? Maybe I can simply use a free third party application to recover these folders? Thanks.

hey I got the same error message,. can any body help to fix this problem?

If you have a map to someone's home, and the people subsequently move, is
the map any good? Neither is the shortcut.

Create a new one!

Well, that's just not helpful. This is why I try to teach my users not to use shortcuts. They are unreliable. Any time you move the underlying hardware or network resources they are broken. And we need to move stuff all the time, like today when Windows Storage Server is mysteriously crashing.

I find that the shortcut becomes a crutch. The user never learns where the files really reside - because their co-worker can be called upon to fix their shortcuts. Don't get me started on hiding filename extensions!

Really, the O/S paradigm must be rethought around network computing, because there are no personal computers anymore. On a Windows domain, there should be a service that registers shortcuts.

Yes, I understand how it works. For a windows admin, it should be possible to change all of the user shortcuts in one place. It isn't, because they are in the file system. The nearest equivalent is using links to Sharepoint documents and establishing a redirect, or using DFS under which the actual windows share is abstracted from the network share that is published. Under a unix system I could just easily fix the symbolic links with a script, but its harder to do in Windows.

Sure I could do that. But how do you do that for 500 shortcuts at a time?

You have to remember that a shortcut is actually a pointer to where the
program file is.
If you change the location of the file, you need to reinstall the pointer to
the new location.

I'll stay out of the rest of your rant, but this line is patently false!

I've been using personal computers since the first TRS-80 in 1977. I've
always had ONE computer at a time - and I still do. I built my current rig
in 2006 for the new Vista RTM. I've never had a network at all - unless you
count the Internet. This personal computer is in our third bedroom, which
is my office, even though I'm long retired.

Yes, there still ARE some personal computers. Quite a few, I'm sure.

But your IT department probably doesn't realize that. Or care. :>(

You need to create a new shortcut to point to the relocated location of the file

This service is the one I think tracks.
--------------------------------------------------------------------------------

Distributed Link Tracking Client
Maintains links between NTFS files within a computer or across computers in
a network.
--------------------------------------------------------------------------------

From the Resolve method on shell links (Platform SDK)

--------------------------------------------------------------------------------
IShellLink::Resolve Method


Attempts to find the target of a Shell link, even if it has been moved or
renamed.

Syntax

HRESULT Resolve( HWND hwnd,
DWORD fFlags
);
Parameters

hwnd
Handle to the window that the Shell will use as the parent for a dialog box.
The Shell displays the dialog box if it needs to prompt the user for more
information while resolving a Shell link.
fFlags
Action flags. This parameter can be a combination of the following values.
SLR_INVOKE_MSI
Call the Microsoft Windows Installer.
SLR_NOLINKINFO
Disable distributed link tracking. By default, distributed link tracking
tracks removable media across multiple devices based on the volume name. It
also uses the Universal Naming Convention (UNC) path to track remote file
systems whose drive letter has changed. Setting SLR_NOLINKINFO disables both
types of tracking.
SLR_NO_UI
Do not display a dialog box if the link cannot be resolved. When SLR_NO_UI
is set, the high-order word of fFlags can be set to a time-out value that
specifies the maximum amount of time to be spent resolving the link. The
function returns if the link cannot be resolved within the time-out
duration. If the high-order word is set to zero, the time-out duration will
be set to the default value of 3,000 milliseconds (3 seconds). To specify a
value, set the high word of fFlags to the desired time-out duration, in
milliseconds.
SLR_NOUPDATE
Do not update the link information.
SLR_NOSEARCH
Do not execute the search heuristics.
SLR_NOTRACK
Do not use distributed link tracking.
SLR_UPDATE
If the link object has changed, update its path and list of identifiers. If
SLR_UPDATE is set, you do not need to call IPersistFile::IsDirty to
determine whether or not the link object has changed.
Return Value

Returns S_OK if successful, or an error value otherwise.

Remarks

Following link creation, the name or location of the target may change. The
IShellLink::Resolve method first retrieves the path associated with the
link. If the object is no longer there or has been renamed, Resolve will
attempt to find it. If successful, and the following conditions are met, the
file that the link object was loaded from will be updated to reflect the new
state of the link object.

The SLR_UPDATE flag is set.
The target has been moved or renamed, updating the internal state of the
Shell link object to refer to the new target.
The Shell link object was loaded from a file through IPersistFile.

The client can also call the IPersistFile::IsDirty method to determine
whether the link object has changed and the file needs to be updated.

Resolve has two approaches to finding target objects. The first is the
distributed link tracking service. If the service is available, it can find
an object that was on an NTFS version 5.0 volume and was moved to another
location on that volume. It can also find an object that was moved to
another NTFS version 5.0 volume, including volumes on other computers. To
suppress the use of this service, set the SLR_NOTRACK flag.

If distributed link tracking is not available or fails to find the link
object, Resolve attempts to find it with search heuristics. It first looks
in the object's last known directory for an object with a different name but
the same attributes and file creation time. Next, it recursively searches
subdirectories in the vicinity of the object's last known directory. It
looks for an object with the same name or creation time. Finally, Resolve
looks for a matching object on the desktop and other local volumes. To
suppress the use of the search heuristics, set the SLR_NOSEARCH flag.

If both approaches fail, the system will display a dialog box prompting the
user for a location. To suppress the dialog box, set the SLR_NO_UI flag.