Go to eject a removable media device and windows basically tells you something is using the device, but it doesn’t know what, and to try again later.
How the fuck did this get through? Why can’t it tell me WHAT THE GOD DAMN HELL is using the device. I’ve seen this behavior consistently since XP, so I know it’s not the work of some coy idiot who was promptly fired, beaten, and made to watch everything he ever loved burned before his eyes.
But some coy idiot they liked the work of. And from the looks of it prompted to design Vista.
Why is it too hard to tell me what’s using the media? What is the logic of not telling me?
Hence my joke about my fellow software engineers that “Most software engineers think data hiding is intended to describe their error messages.” (I had a HP printer that did something similar. I ended up literally throwing it out my back door into the back yard.)
And it’s not only Windows that suffers from useless error messages.
I prefer to keep my NAS read-only to prevent disasters from the kids and rogue viruses. I used to keep my iTunes library on this read-only NAS device.
A couple of years ago, Apple released a new version of iTunes that failed miserably with some strange error code (e.g. “iTunes failed with error code -51”).
I discovered that when I made the NAS writable this problem went away.
A couple of months later, in a new release, this problem disappeared completely and I was able to use a read-only NAS again. None of this was documented by Apple.
I chalk it up to overly casual treatment of error messages in low level drivers and such. Let’s say OS X has a network disk driver that works like a charm, but occasionally fails, due to things like “no permissions to write” or “out of disk space”
Rather than pass along verbose messages, they simply hand out a number (-21) and their documentation shows what the number means.
As other folks come along and write code that sits on top of the base driver, they might carefully address the main errors (e.g. the code for “out of disk space”) without addressing the more obscure ones.
And then when a weird error code comes up, they might simply pass the code on up to the calling program.
The end result is that iTunes had no way of understanding what error code -51 really meant. The iTunes developers couldn’t easily figure it out because their code was calling someone else’s code which hides the call to the OS X routine that caused the original error. They were likely calling standard file management routines that sat on top of a bevy of specialized code for handling each different type of device and each different type of file system.
This strikes me as more of an IMHO question, rather than GQ, but I’ll leave it to the mods to decide. That said, I will attempt (probably poorly) to answer it in a manner appropriate to each forum.
GQ:
The problem goes back to the very first version of Winblows, it didn’t start with XP. The OS never had a built-in means for a process to determine what other process is using a particular resource. If a process starts up and requests a resource, the right hand of the OS only knows it’s “in use”. The left hand knows who’s using it, but they don’t talk to each other. The process requesting the resource has no way of asking the left hand who’s using it. It can only ask the right hand. The right hand can’t ask, because Microsoft never gave it a way to do so, either. Consequently, all you can get is an error message to the effect of “sorry, it’s in use, but I can’t tell you who’s using it, or when it will become available. Why don’t you come back, later.”
IMHO:
Some wiseass I was reading years ago came up with the perfect description of a typical Microsoft dumbassery, of which this is a good example. Although I can’t quote it word for word, since it was years ago I read it, I’ve been paraphrasing it in these situations ever since:
Microsoft, as usual, when faced with a problem the computer industry already had a perfectly sound standardized solution for, that had been in use for decades, instead chose to reinvent the wheel. And, as usual, they opted for a shape other than round.
Others have done a good job of summarizing Microsoft’s rationale, so I won’t speak to that but as to the problem, it often turns out to be the recycling bin that is ‘using’ the drive. Right click the bin and set it to not be active for the removable drive. That means deleting a file from that drive will happen immediately instead of being undo-able, but if it allows you to eject the disk, at least you’ll know that was the culprit.
I’ve been using Unlocker precisely because of this problem. With Unlocker, I found that sometimes the file I need to change is actually “in use” by more than one process. Now I can “unlock” those with ease.
I’m not convinced that engineers or designers are to blame. Part of the Microsoft’s success is actually in not being perfect and being early to the market. Yes, it would be nice to have number of in-detail accessories but those take time and testing gets more complicated so they just stay away from it. Which means, blame sales.
Speaking as a software developer, the problem is that the part of the software that detects the error usually is far removed from the part of the software that has to report the problem to the user. Think of it a bit like a game of Telephone. The user send a command to the software, and it gets passed up the line until it finally reaches the end, who realizes that the command can’t done, and that message has to be relayed all the way back down the line. By the time it gets back to the user there’s little context remaining to give an indication as to what went wrong.
Even worse, the traditional way to denote an error is to return a number that corresponds to a generic error message like “Permission Denied”. There are a very limited number of these error codes so it can be quite difficult to tease out what went wrong.
Admittedly, a large part of the problem is laziness on the part of the programmer. When the user interface receives a cryptic error it really should do more work to try to narrow down the problem, but that can require significantly more work by the programmer.
Linux and Macs have a command called “lsof” that will list all the files that are open and the commands that have them open. For Windows, you should see this post on Stackoverflow.
Just uncheck most of the options when installing, they are lite-adware or something. The actual program seems to have none of that, and is very small and unobtrusive.
You can get version 1.85 here. It’s freeware.
Version 1.90 is out, but the author adds/links some sort of ad/toolbar of sort for eBay that I didn’t like so I re-installed 1.85 back on my system. You can get version 1.90 from cdnet or other software depository sites.
No but I totally should have afterwards. (Since it was just the last straw in quite a few WTF moments. Unfortunately it wasn’t the only piece of HP hardware where I wonder “How the hell did that get out of QA”. Guess it’s to be expected, between 2000 and 2005 alot of their consumer level stuff was junk.)
My understanding is that windows is bottom up. When the user starts an application, it takes what it needs from the system with the understanding that it will give it back. It is in control. Trusted with the keys.
Unix/Linux and probably the apple operating system are top down. The application(and devices) must ask the system for permission to do things and a record is kept.
For this reason when an app in windows crashes, it can hang up. Depending on what an application is doing, it might hang the whole system. When you make use of the task manager, it just sends a signal to the application to stop. Hopefully it can respond. If not, you restart the computer.
On linux, at least, you can almost always just click the close button. It doesnt normally hang. If its the process manager thats being balky, you can just kill the X server - which handles all the graphics and thus all the user applications. This takes mere seconds. Barring this, do a restart. But needing to restart is uncommon because anything below the X server layer is out of the domain of the desktop user applications.
The trick is to have an OS and environment such that the details are not lost along the way. When the low level error is raised it should be logged in the OS facility for error logging for that process with all relevant details and passed back up the chain. At all levels should be universal error monitoring capabilities at which point action can be taken, or the message gets passed further up the chain as well as additional messages indicating what it means at this intermediate level.
If the error is severe enough to cause the app/process to stop, the information provided should allow for a much easier time troubleshooting.
For example:
Lowest level initial message - Write operation failed, disk is full
Medium level additional message - Failed to save simulation results in file SIMDATA1.dat
High level additional message - Simulation was stopped due to problem saving data
With the above info, at the very least a tech person wouldn’t be randomly trying things to figure out the problem, and potentially the application would have enough info available when at the high level to provide a nice exact message to the user.
This. And it’s not just Windows - the problem is the same in many different types of operating systems. I’m doing Android development now, and it has the same problem.
Not always the programmer. I can’t tell you how often I’ve asked for more time to put in better error tracking, and have been overruled by the Powers That Be. When it comes right down to it, most organizations will spend money on new features, not making the old stuff more robust.
Ironically, Microsoft was one of the better companies in this regards. But they’re the bad guy now, and it’s much more fun to dis them that remember that way back when, Microsoft was the new cool innovative company.
Most of you not being programmers, you probably don’t realize it, but what you are asking for is contradictory.
You want multiple programs active at once, some even multi-threaded. And you want them to work together efficiently, sharing system resources & devices among all the programs. From a programming viewpoint, this means designing the system resources as independently as possible, minimizing the inter-connectedness between the system resource/device and any program which might want to use it. That is a major point to making them robust, so that even a badly written program won’t damage the device (or the data on it).
But at the same time, you are asking for very specific, detailed error messages about interactions between the system resource/device and any active program. That implies a close connection between these programs. Which is something antithetical to the design of an interrupt-driven, event-responding OS like Windows, Unix, Linus, OS X, etc.
It can be done (see the mentioned Isof or Win Process Explorer). But that kind of coding is complicated & difficult, and it would be inefficient (and error prone) if every program had to include this kind of coding.
So what you are asking for is really 2 opposing things, at the same time.
Rather like saying “I want my new car to get fuel economy of at least 40 miles per gallon. Oh, and I also want it to be so solidly built that it just bounces back from minor accidents with no body damage at all.”