Shortcut Tracking Problem and
Stop Shortcuts from Searching

Keywords: shortcut shortcutmake 

---

Here's some information from one of our users about the Windows Shortcut tracking problem:

Try the following experiment (you'll need a network and a windows application).

1. Create two shares on your network \SHAREA, and \SHAREB.
2. Copy notepad.exe to the root of both shares, renaming it to motepad.exe

Now from either a 95 or NT4 client do the following:

1. Make sure that you have no other connection to either of the shares.
2. Connect drive f:, for example, to \SHAREA.
3. Explore f:\, rightclick on motepad, copy.
4. Paste the shortcut to your desktop.
5. Start motepad via the shortcut.
6. Open a dosbox and type net use - you'll see that f: is connected to \SHAREA.

fine...now the plot thickens

1. In the dosbox, disconnect f: (it may complain about open files, yes, disconnect it)
2. Still in the dosbox connect f: to \SHAREB.
3. Start motepad from the desktop.
4. Go back to the dosbox and type net use. - \SHAREA is now connected to the first available drive.

interesting isn't it?

The official MS person says that this is by design: essentially although the user interface shows drive f:, the information is actually stored as a UNC so the user doesn't need to worry about stuff like this. There is, in the 95 RESKIT, a utility (shortcut.exe) that allows you to turn off 'tracking'. Unfortunately this utility only works under 95. Since my network has failover for application drives (i.e. connect M: to \\serverA\MSOFFICE, if that doesn't go, connect M: to \\serverB\MSOFFICE.) this is a minor problem. The major problem occurs when a user creates a shortcut when he is logged in in Geneva, pointing to a server that is local to geneva, and then returns to Zurich (Even with a 2M link, 5 people running office over it will easily shut it down.)

---

Article ID:   W13851

Filename:   Shortcut Tracking Problem.txt