Coffeehouse Thread

21 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Win7 deletes shortcuts on the desktop

Back to Forum: Coffeehouse
  • User profile image
    rhm

    Windows 7 deletes shortcuts from your desktop if they point on files that no longer exist. It doesn't prompt you to clean up the desktop like XP did, it just deletes them. It doesn't even put them in the recycle bin, FFS.

    Seriously, who thought this was a good idea?

  • User profile image
    Harlequin

    If they point to a file that no longer exists, why would Windows keep them?

    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.

  • User profile image
    AndyC

    @Harlequin: The problem usually occurs when they're pointing at a location which might be temporarily unavailable, such as a network drive.

  • User profile image
    rhm

    Or in my case, they point to build targets that might not have been produced due to compile errors.

    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.

  • User profile image
    evildictait​or

    It seems like you're doing stuff the wrong way round.

    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.

  • User profile image
    Harlequin

    You need to think of the scope of this. You could have an Excel file with 130 shortcuts to it, in multiple folders. You delete the Excel file...now what. Should the system "know" all shortcuts that pointed to the file? Should those all end up in the recycle bin if it does.

    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.

  • User profile image
    Craig_​Matthews

    I don't know where to start about an operating system deleting anything belonging to the user without knowing why it is there. As AndyC alluded to, there might be shortcuts on the desktop to network locations which may be temporarily unavailable. Notebook users who may not be on the network for days at a time is the most glaring example. And no, the user isn't "doing it wrong."

    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.

  • User profile image
    evildictait​or

    @Craig_Matthews: Windows won't delete a shortcut to the network just because the network is unavailable. It will delete it if the network is available and the file isn't.

  • User profile image
    Dr Herbie

    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

  • User profile image
    AndyC

    @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?

  • User profile image
    evildictait​or

    , 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.

  • User profile image
    rhm

    , 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}

  • User profile image
    AndyC

    , 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.

  • User profile image
    evildictait​or

    , 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.

  • User profile image
    evildictait​or

    , 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.

  • User profile image
    AndyC

    , 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.

    , 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.

  • User profile image
    evildictait​or

    , 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

  • User profile image
    AndyC

    , 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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.