Seriously, who thought this was a good idea?

Analogy: I delete a music folder off my music share, MediaMonkey sees that and takes the album out of my library. I wouldn't see a reason for a prompt, and they didn't put one in.

It's another case of Windows trying to be clever and do stuff automatically when there is no automatic action that makes sense for every scenario.

And even if you want to argue that it's acceptable to delete broken shortcuts without prompting the user because that's the right thing to do 99% of the time, why in the name of great suffing **** does it not put them in the recycle bin? Who is that helping? The PM who came up with this is a complete jackass.

Instead of having shortcuts to files that might not exist yet, why not create the shortcuts when you create the files as part of the build/batch process?

The reason the file doesn't go to the recycle bin is because it's easier to delete a file with DeleteFile than it is to use COM to move it to the recycle bin. This is an example of "that feature isn't there because someone would have to program it", and anyone who thought that deleting the shortcut might need to be an undoable action would probably not delete the shortcut without a prompt.

Experiment:

Make a temp file.
Put a shortcut to it on the desktop.
Put a shortcut to it somewhere else. E.g. the root of your D: drive.
Delete temp file.
What happens? Do all shortcuts disappear? Does only the desktop one get wiped? Does the desktop one get wiped and the other ends up in the recycle bin? Etc.

Anyway, this happens as part of Windows 7's system maintenance which is controlled by a number of a Powershell scripts in %systemroot%\diagnostics\scheduled\Maintenance. Commenting out lines 28-36 in TS_BrokenShortcuts.ps1 will prevent it from being able to do this (it will cause the script to act on an empty list basically). You need to take ownership of the file first, then add permission to edit the file. Be sure to reverse the permissions change and make the owner TrustedInstaller again when done.

After several restarts and log-on/off cycles the desktop shortcut was still there (without me having reconnected to the VPN). I eventually deleted the shortcut manually.

So, as evildictaitor said, it looks like Win7 is smart enough to keep shortcuts to networked resources.

Herbie

46 minutes ago, AndyC wrote

@evildictaitor: Leaving aside the almost inevitable race conditions in determining that, it's still deleting files based on some external factor that is out of the control of the OS. What if the file on the server has been momentarily deleted with the intention of putting a replacement in? Or if there is some temporary issue that makes the file appear to have been deleted?

There's no race-condition here. If the file exists the shortcut stays. If it doesn't it goes. If the file appears slightly after the shortcut went away, well the shortcut wasn't pointing to something so it deserved to die. If the file disappeared after choosing to keep the shortcut, well you're no better off than before where the shortcut points into the ether.

Look, I'm not saying deleting shortcuts without a prompt is a good idea - I'm just saying that it's a valid action for the OS to take. The sole purpose of a shortcut is to take you to a target file. If that file isn't there then the only purpose of the shortcut has vanished, and hence leaving the shortcut around clutters up the folder. The reason will be that uninstalling programs often doesn't delete the shortcut files they inevitably dropped on the desktop during install, and this was an attempt to stop your desktop becoming a shortcut cemetery.

4 hours ago, evildictaitor wrote

Look, I'm not saying deleting shortcuts without a prompt is a good idea - I'm just saying that it's a valid action for the OS to take. The sole purpose of a shortcut is to take you to a target file. If that file isn't there then the only purpose of the shortcut has vanished, and hence leaving the shortcut around clutters up the folder. The reason will be that uninstalling programs often doesn't delete the shortcut files they inevitably dropped on the desktop during install, and this was an attempt to stop your desktop becoming a shortcut cemetery.

And what about the effort I put into manually changing parameters to run my program? That's why I have all these shortcuts.

So, deleting shortcuts to clean up after broken uninstallers is a 'valid action'. But that's not the only reason people have shortcuts on their desktop. Windows has just added more idiocy to fight idiocy and broken the general case: That the OS shouldn't delete user files without warning.

@Craig_Mathews Thanks for the tip. I managed to edit the file you mentioned but I couldn't change it's owner back to TrustedInstaller as there is no user called that which is weird.

@Dr.Herbie  This 'clean up'/'balls up' process only runs once a week (01:00 on Sunday night on my machine) - it might not have actually run during your experiment. As far I can tell from the PS script, it doesn't take any account of whether the drive the target is located on it available.

# Function to check whether the shortcut is validfunction Test-ValidLink([Wmi]$wmiLinkFile = $(throw "No WMI link file is specified")){    if(($wmiLinkFile -eq $null) -or ([String]::IsNullOrEmpty($wmiLinkFile.Target)))    {        return $false    }    return Test-Path $wmiLinkFile.Target}

10 hours ago, evildictaitor wrote

*snip*

There's no race-condition here. If the file exists the shortcut stays. If it doesn't it goes. If the file appears slightly after the shortcut went away, well the shortcut wasn't pointing to something so it deserved to die. If the file disappeared after choosing to keep the shortcut, well you're no better off than before where the shortcut points into the ether.

You have to take two decisions for network shortcuts, assuming we aren't going to delete them when the network drive isn't available.

1) Is the network drive available?

2) Is the target of the shortcut available?

A race condition is inevitable, since the availability of the network drive between steps 1 and 2 is indeterminate. It's the same anti-pattern that underlies all the IsBadXXXPtr type functions.

5 hours ago, rhm wrote

That the OS shouldn't delete user files without warning.

Actually what is this all about? I tried this on my desktop and I get a dialog:

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

Do you want to delete this shortcut?

[YES] [NO]

What more do you want Microsoft to do for you? The shortcut doesn't work, they gave you a dialog asking if you wanted to delete the file, you clicked YES and it deleted it.

EDIT: And if the file is in the recycle bin, Microsoft even give you the option to un-recycle it

EDIT2: And if your shortcut points somewhere in the same file and that file has been renamed, the shortcut will also update.

This code is going out of its way to make your life easier, and has no less than three different dialogs to help you out. It's really not the big bad evil Windows that you're making it out to be.

50 minutes ago, AndyC wrote

*snip*

You have to take two decisions for network shortcuts, assuming we aren't going to delete them when the network drive isn't available.

1) Is the network drive available?

2) Is the target of the shortcut available?

Those are the same step: Does CreateFile("\\networkpath\path\foo") fail with a file not found error code? If yes, then do something different.

It's the same anti-pattern that underlies all the IsBadXXXPtr type functions.

IsBadXXXPtr is a check, not a security check function. It is there to check that your arguments and the integrity of your application are valid, not to protect against malicious threads in your process changing things on the fly - because frankly if there's a malicious thread changing the protection of various bits of memory in your process, you've already long since lost your fight against those hackers.

10 minutes ago, evildictaitor wrote

*snip*

Actually what is this all about? I tried this on my desktop and I get a dialog:

*snip*

What more do you want Microsoft to do for you? The shortcut doesn't work, they gave you a dialog asking if you wanted to delete the file, you clicked YES and it deleted it.

The point is this happens as part of a default Scheduled Task, not how the shell handles it if you click an invalid shortcut.

8 minutes ago, evildictaitor wrote

*snip*

IsBadXXXPtr is not a security function, and hence this is not a real anti-pattern.

It's not about security. If IsBadXXXPtr fails, the pointer is invalid. If it suceeds, the pointer might still be invalid. So basically making any decision on it is entirely pointless.

Checking something global exists/is valid then following up by attempting to do something based on the assumption that it is valid is fundamentally flawed on a multitasking OS. The only valid way to do it is to perform the action and respond correctly to a failure, but obviously that's not an option here and as such there is no correct way to write this functionality and it shouldn't exist at all.

2 minutes ago, AndyC wrote

The point is this happens as part of a default Scheduled Task, not how the shell handles it if you click an invalid shortcut.

In that case, just remove the scheduled task that does this. It's in "C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1".

It's not about security. If IsBadXXXPtr fails, the pointer is invalid. If it suceeds, the pointer might still be invalid. So basically making any decision on it is entirely pointless.

On the contrary. If you define a method SetCallbackFunction(void* foo), you probably don't want to create a difficult to debug error where somebody gives you a bad code pointer and then later your program crashes. If instead you call IsBadCodePtr(foo) on the argument, you'll see the bad argument as it comes into your function instead of having to make guesses at who called SetCallbackFunction last.

Checking something global exists/is valid then following up by attempting to do something based on the assumption that it is valid is fundamentally flawed on a multitasking OS. The only valid way to do it is to perform the action and respond correctly to a failure, but obviously that's not an option here and as such there is no correct way to write this functionality and it shouldn't exist at all.

lock(object){   if(object.IsValid)   {      object.DoSomething();   }} 

Is entirely valid despite running on a multitasking OS - and is even valid if there is network traffic involved so long as the lock is a lock that is honoured by the client and the server. A case in point is SQL - because of transactions you are able to make a decision based on data in the SQL database and then update something else all atomically, despite the fact that there's a "race-condition" and network traffic involved

4 minutes ago, evildictaitor wrote

*snip*

In that case, just remove the scheduled task that does this. It's in "C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1".

I don't think users should be expected to hack about inside OS defined scripts to get decent behaviour.

*snip*

On the contrary. If you define a method SetCallbackFunction(void* foo), you probably don't want to create a difficult to debug error where somebody gives you a bad code pointer and then later your program crashes. If instead you call IsBadCodePtr(foo) on the argument, you'll see the bad argument as it comes into your function instead of having to make guesses at who called SetCallbackFunction last.

Except you don't know if it's valid or invalid. The most IsBadXXXPtr can possibly tell you is that it was valid/invalid at some arbitrary point in the past. So absolutely any code which ever uses foo still has to call it defensively and handle the situation in which it was a bad pointer. Thus making the IsBadXXXPtr call entirely redundant.

*snip*

1	lock(object){   if(object.IsValid)   {      object.DoSomething();   }}

Is entirely valid despite running on a multitasking OS - and is even valid if there is network traffic involved so long as the lock is a lock that is honoured by the client and the server.

If you can hold a lock on something, then it's no longer entirely out of your control, so that's fine (just as a similar pattern on entirely private objects is). Getting a lock on something that doesn't exist (or at best whose existance is indeterminate) doesn't work though and hence we find ourselves back at the IsBadXXXPtr anti-pattern.

1 minute ago, AndyC wrote

I don't think users should be expected to hack about inside OS defined scripts to get decent behaviour.

I've never come across this being a problem before. If you feel strongly about, file a bug.

The most IsBadXXXPtr can possibly tell you is that it was valid/invalid at some arbitrary point in the past.So absolutely any code which ever uses foo still has to call it defensively and handle the situation in which it was a bad pointer. Thus making the IsBadXXXPtr call entirely redundant.

Knowing that it used to be valid is still better than nothing. And any code which calls foo doesn't have to code defensively if the contract is anyone who calls SetCallbackFunction() must set a valid function (an example of this is the SetUnhandledExceptionCallback function). If that function used to be valid but no longer is, well all bets are off - the guy who unloaded the function could just have easilly unloaded all of the exectauble code in the process and then you'd definitely crash.

If you're trying to prevent people who can run arbitrary code in your process from being able to crash it, you're going to lose, and the IsBadXXXPtr isn't going to help you. If you want to put in debug assertions to help catch errors in development (which might be your or other people's code) then this is an entirely valid programming style.

If you can hold a lock on something, then it's no longer entirely out of your control, so that's fine (just as a similar pattern on entirely private objects is). Getting a lock on something that doesn't exist (or at best whose existance is indeterminate) doesn't work though and hence we find ourselves back at the IsBadXXXPtr anti-pattern.

You never get a lock on something that might not exist. You get a lock on the container of the object, and then you query for the object. The same is true in SMB/webdav.

1) Get a connection to the share (if that fails, fail with a NO_NETWORK error)

2) Traverse as far as you can down the folder heirarchy. If you fail, return a FILE_NOT_THERE error.

3) Lock the folder. If this fails, return a LOCK_FAILED error

4) Query for the file. If this fails, unlock and return a FILE_NOT_THERE error.

5) Do something with the file. The file will be there because you have a lock on it, and when you're done release the lock.

Try putting the user NT SERVICE\TrustedInstaller in the dialog. That should change it back.

12 hours ago, Dr Herbie wrote

I worked from home one day last week (an unusual event for me at the moment) connecting to work through a VPN. I created a desktop shortcut to an application on the server.

After several restarts and log-on/off cycles the desktop shortcut was still there (without me having reconnected to the VPN). I eventually deleted the shortcut manually.

So, as evildictaitor said, it looks like Win7 is smart enough to keep shortcuts to networked resources.

Herbie

http://support.microsoft.com/kb/978980

It's not something that happens immediately. It occurs as part of a scheduled weekly maintenance task. If there are more than four broken shortcuts on the desktop (it does not matter what the target is -- local file, local folder, UNC path, whatever), the scheduled task deletes them.

So when the CFO, with shortcuts to network locations (crystal reports folder, budget spreadsheets, department specific budget folders, whatever), goes on vacation and takes her laptop with her, she will come back to work, try to open the shortcut to a document, notice that the shortcut is gone, and have to find the target, wherever it is, on a network with tens or hundreds of file shares. For all 5+ of these locations.

@evildictaitor:

Deleting shortcuts should not be default behavior by a background maintenance task that requires manual deskside intervention by a system administrator to turn off.

And believe it or not, lots of business applications are both live and run from network locations. The CFO above would be mighty pissed if she can't find the shortcut to the fixed asset application that she needs to run after coming back from vacation.

You may not think there is a valid reason for shortcut targets to be temporarily unavailable (even if temporarily is 8 days or more), but that's simply not reality.

 Edit to add:

In Before "Shortcuts to network locations" and/or "vacations" are labeled as "corner cases" or "power user" (with 'power user' being defined as 'computer geek') features.

My org just changed a bunch of path names on our shared drives (every reorg/merger eventually leads to this).  Trying to open a shared/network folder just gave me the popup, and I reacted too quickly and deleted a shortcut. It didnt even put it in the recycle bin where I could recover it. Soon, many of them will start getting deleted by the scheduled cleanups some of you are talking about... grrrrrr.

If it had not been deleted, I'd at least have a starting point on rebuilding it.  Probably just need to change one letter in the path.  

It really drives me crazy that there are sys admins (dictators) out there who think this is OK!