Archive for July, 2006
OK, so I have to say it…
One of my biggest pet peeves is the Windows’ download logic.
So here I am, answering email. In the background, I’m downloading a 250 MB file. Upon making the download selection, I chose the target folder for the file to go. Of course when the download begins, Windows saves the file to the Temporary Internet Files folder instead of the folder that I designated for the download to go!
If you’re ever downloading something like a DL DVD image at 7 or 8 GB in size and your laptop’s C drive doesn’t have enough space for the file, the download will fail, but of course, not until you run out of space spending hours downloading the file!
Anyway, I’m downloading the file in the BACKGROUND and answering an email in the foreground. Then suddenly, once the download has been completed (to the location I did NOT specify) Windows will move the file from the Temporary Internet Files folder to the location I had previously designated. Of course, Windows will insist on popping the move process that was in the BACKGROUND back to the FOREGROUND and on top of that, set FOCUS to it as well!
1+1=2 and if you’re writing an email or doing anything actively when this stupid action takes place, you’re inevitably going to be pressing the SPACEBAR somewhere in there. If you know anything about the File Move dialog window, it is that the CANCEL button has focus and that pressing the darn SPACEBAR will abort the move of the file and effectively also kills your download!!!
So that’s why I want to know… Who the heck came up with this design anyway!?
Why not just save the darn file to the location I designated for it to go right from the get go.
When you’re creating a ZIP file, it has a temporary name and once complete, it’s renamed to the actual name.
Why couldn’t downloads work like that?
Oh well, at least I feel better now. Time to go and figure out which one of my downloads I killed leading to this rant…
If you’ve ever attempted to do a STSADM -o restore and the process got interrupted, then you KNOW what I’m talking about. When this happens and site data is not properly synchronized between the config and content databases, things get a little rough especially since you can’t restart the restore due to this state of the database.
According to this post by Keith Richie, there is some hope. Part II can be found here. In some cases, depending on the type of orphaned mismatch you have, the problem can be resolved by reattaching the content database. In the case where you have content data but not config data though, which seems to be the case most of the time, there are few options available. And if you’re thinking of just cleaning up the records yourself, for pity’s sake DON’T!!!
I REPEAT! DO NOT DIRECTLY UPDATE YOUR SHAREPOINT DATABASES! STEP AWAY FROM THE KEYBOARD!