WTF is it still "properly eject your USB device"

I don’t understand why we still have to deal with this primitive “properly eject your USB device” bullshit. Things sometimes get inadvertently disconnected. Why is there still such a big risk of losing data? Why hasn’t the hardware industry solved this problem? Any consumer device that is attached to something else–anything else–should be yankable without any rigamarole.

I believe cost may be a factor in some of these cases. The computer is the controller while the device itself is dumb, so if you are doing a writing procedure and you yank it you may get something not recoverable.

So nobody can get sued if you shoot yourself in the foot.

Do you mean to imply that if I start writing a 5GB file to my flash drive I should be able to yank it in the middle of the transfer and expect all the data to be intact?

Yeah, my understanding is the computers just saying “keep you pants on for a second while I make sure there’s no read/write going on…”

Am I missing something?

You can ignore that message as long as you’re not writing to the drive in any way, for the most part. More paranoid tech-savvy folks will probably disagree with me, but in reality, go ahead and pull the drive. Nothing will happen except an error message.

As long as the USB device isn’t a data storage device of some sort, you don’t have to worry about ejecting it properly. Even then, it’s usually not a big deal if you do, as long as it’s not actively writing data to it. It’s more of a safeguard for the relatively rare cases where it may cause data loss.

Here’s a link if you’re interested in the details:
LifeHacker: Do I Really Need to Eject USB Drives Before Removing Them?

Of course that wouldn’t be expected to work if you interrupt an operation in progress. But after the operation has completed, I should be able to remove the device.

I have lost data in the past when the copy had completed and I removed the device. In one case, the card wouldn’t even re-format and I had to send it back to Kingston. I believe early versions of XP would keep some of the data cached and you had to eject the device. Later updates to XP have not had this restriction.

The expectation is that once the operation is complete, I can unplug the device from the computer without any ill effect.

The whole point is: how do you know when the transfer is complete? I mean, you can usually make a good guess, but say I’m logging data to a USB drive - if I yank it without unmounting it first, I’ll lose data. As is often the case with computers, there are a lot of scenarios that could lead to loss of data, even though most users won’t have a problem.

I think it’s in the situations where I plug in a USB drive, open a PDF in Adobe Reader, close the file, close Reader, try to eject the drive, and still repeatedly get the “file in use, try again later” message. Meanwhile I’m shutting down every program and every process on my computer and am one step from shouting “What the hell is still using this goddamned file?!”

Ahem… sorry.

If you’re actively logging to the USB device, then the operation isn’t complete and you can’t yank the device. But if you’ve closed the log file, the expectation is that you can just yank the device. Or if I’m copying files to or from the device, once the copy has completed I should be able to yank the device.

If you open the file in an application (like Word or Photoshop), the file may be in use while the application is running. But once you close the application, you should be able to yank the device. That should be the way things work with these USB devices, but it doesn’t always work out that way.

I’ve noticed with external hard disks, they sometimes say “Cannot be disconnected” even when copying is done. I am guessing its indexing, or defragmenting, or something, but that’s only a guess. Anyway, I always click on the disconnect icon in the system tray, and follow instructions…

(“I was only obeying orders…”)

It’s because storage devices are absolutely glacial compared to the rest of your computer. To compensate for this, when you tell the operating system to write data to a disk, it doesn’t make you sit there and wait for every bit to make it to disk before letting you do anything else. Instead the operating system writes to the disk behind the scenes while you move on to doing something else.

As an analogy, you know how sometimes you’re surfing a website and opening every page is slow as you wait for the server to actually send you what you asked for? If the OS didn’t go to heroic lengths to hide disk latency from you, you’d get the same experience trying to work with files on your hard drive.

It was almost certainly waiting to finish flushing outstanding writes to the disk.

Exactly. In some cases, the point at which it tells you that it’s done copying/moving a file is the point at which the OS has finished writing it into a buffer, not the actual storage device. To be completely safe, you have to make sure the buffer is clear–which is part of what the eject function (or the sync function on *nix systems) does. It puts other stuff on hold and prioritizes writing everything in the buffers to the drives until they’re clear.

Even solid state drives? How much faster are those compared to your average disk hard drive?

Absolutely. Some quick Googling turns up a relatively recent press release bragging about their new SSDs with latencies around 100 us. A traditional spinning disk will have latencies more around 5-10 ms – about 100 times slower. DDR-3 memory, by way of comparison, has latencies between 10-15 ns – and to a modern CPU, that’s so unreasonably slow the CPU has to play tricks to avoid actually using RAM as much as possible.

Modern CPUs are incredibly fast compared to any other component in the system. The challenge, both for CPU designers and programmers, is to ensure that the CPU spends as little time as possible using those other components, lest the incredible speed of the CPU be wasted.

I found this interesting after looking up what a us was… (my brain didn’t immediately realize the u was a replacement for the micro symbol)

1 nanosecond (ns)
One billionth of one second
1 ns: Time to execute one machine cycle by a 1 GHz microprocessor

1 microsecond (µs)
One millionth of one second

1 millisecond (ms)
One thousandth of one second
4–8 ms: typical seek time for a computer hard disk

So just try to put in perspective that the average modern microprocessor hovers somewhere around the 3GHz range - per core. Huge difference.

Regardless of how fast the processor is, it’s the operating system which knows what’s going on. It’s the operating system which tells the copy operation it’s done. There’s no reason the OS can’t make the copy wait a bit longer until the data is fully written to the external device. That’s the point of the OP. In this era of modern computing, the expectation should be that data written to external devices is not buffered and you don’t have to call an external function to sync the data. It’s the OS which does the Eject functionality. There’s no reason the OS can’t just write the data out fully for each operation.

Of course file systems can be designed to be proof against random connection losses, but such a system requires an additional overhead in transfer speed and/or space. People tend to value both of those more highly than the minor inconvenience of scheduled disconnection.

And of course to solve your problem, you could always disable write-caching… but trust me… you don’t want to.