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.
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.
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.
Just a user here, and from my view on this, the OS should NEVER delete files that I created without asking me. (And when it does ask me, I'd like the default response to be [no].)
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!
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.