The entire drive was lost? That's really shameful firmware, even if you unplugged it mid-write.

Unplugging an idle drive should never lose anything.

But there's a lot of flaky hardware out there.

> Unplugging an idle drive should never lose anything.

Users aren't especially great at knowing when their drives are idle. This has honestly been true since we moved on from loud floppy drives.

At the time, I've met enough people that weren't able to tell if their loud floppy drives were idle too.

Some have a flashing light to help with it, but I think there are some that have no led

A flashing light tells you when the device is writing or reading. It doesn't tell you when an important cache on the operating system side has been completely flushed. Or that the OS will start writing to the device again in a fraction of a second. Or a dozen other things that are relevant to removing a storage device on a modern system.

A good UI would be to have the USB's normal state be "ready to pull", and have the icon in the tray turn red when there is unflushed data in the cache, and turn green when you can safely pull the drive. That way there is nothing to remember to click on. Then, in the case where another write starts up just before you pull the drive, give you the ability to plug the device back in to let the data flush to it (after the OS check the volume ID of course).

> A good UI would be to have the USB's normal state be "ready to pull"

That's completely wrong. If it were workable, that's how these things would have always been set up. We've got good reasons for not doing things this way.

> have the icon in the tray turn red when there is unflushed data in the cache

There's a lot more to worry about than data in the cache. Open or locked files are an issue regardless of whether or not the cache is empty.

> turn green when you can safely pull the drive

We have almost got this now, with the icon that indicates whether it's safe to pull the drive or not. The difference is that you have to unmount the drive manually to get the friendly "all clear" indication. (a lot of times it won't really matter if you pull the drive while it's mounted)

You could add a process to automatically unmount the drive, but simultaneously provide some kind of virtual drive such that applications could seamlessly remount it and use it. You've then got the possibility that an app will start using it in the moment between when you look at the screen to verify it is safe to pull the drive and when you pull the drive. To make THAT error go away you need to add a request to the user to put the drive back in...

> Then, in the case where another write starts up just before you pull the drive, give you the ability to plug the device back in to let the data flush to it (after the OS check the volume ID of course).

Of course it's not just writes, there are also reads to be contended with.

Anyway, after seeing a few of the new "Not ready reading drive A Abort, Retry, Fail?" error messages, people are going to wonder why your new feature is fucking with them.

I was thinking that at a minimum, have an the indicator be red if the write cache is dirty or there are open files on the drive. But I see your point, that in that case green wouldn't really mean that it is safe either. And having the indicator be green/yellow/read (for unmounted/clean cache, no open files/open files or dirty cache) might be a bit more confusing.

Windows doesn't delay writes to a non-fixed drive by default, so the blinking light works fine.

A new write is possible but unlikely if the user is done with the drive, and again shouldn't cause major damage.

File locking is still a thing.

The blinking light does precisely what it advertises. That's never really been the issue.

Damage certainly is unlikely if the thing is pulled while mounted. I wouldn't design the UI around that, though.

An unplugged drive doesn't need locks, and if a program puts a file into an inconsistent state and leaves it there because it has a lock? Have they ever heard of crashing or power outages?

You want "them" to use files more safely so that you can implement a less safe means of mounting and unmounting devices? I'm grateful Microsoft (and others) do not think that way.

If a program crashes when idle I don't want corrupt data. If I leave a program open in the background and I lose power or my video card driver takes down the system I don't want corrupt data.

I can somewhat excuse losing data if things go wrong during a save. At any other time it should be robust enough that my data is safe.

This is not just about unplugging drives, this is a general sanity measure.

I've had it happen to me as well. Bumped a USB drive to which I was copying files under OS X, and it disconnected. It left the drive in a really wierd state - I could see the files on the drive, but could not read or delete them. Using diskutil under OS X errored out when trying to format, and diskpart in Windows said the drive was read-only (but could not change that flag).

I ended up needing to use some low level tool from a USB drive manufacturer's website to get it working again.

... says someone that has clearly never used a Zip drive.

The only reason I could think of is the firmware is not performing writes the way the OS expects them to.

I thought this was a buffered-writes issue, where (perhaps based on the filesystem?) the OS may have buffered some of the disk operations in memory and by asking it to unmount you can ensure that everything gets flushed to the drive. Not sure how that would result in ruining/wiping the drive though.

Exactly this.

You can ruin entire filesystem, because not only file blocks are cached, but filesystem blocks too.

If you still do not want to eject the drive beforehand, turn on Optimize for quick removal option (should be default for flash drives now). You will lose write cache though (the write performance will be drastically worse).

It ruins the filesystem if you're in the middle of writing important metadata to the filesystem that can't be done atomically.

This is not an issue for modern filesystems, but most USB drives are formatted with FAT, which has no journaling or other defences against such issues. You could minimize the risk by doing synchronous writes to the drive, but that'd also incur a _very_ big performance penalty.

If you are writing the FAT, you could really screw things up

I understand why it's there, but it's a "systematic" warning appearing every time and which does not give the cause, only that there is an issue. Which means people learn to ignore it, case in point my brother and father.

Also it gets triggered by the dumbest of things, eg my linux laptop does not unmount it in a way that windows 8 consider good enough. At the very least windows itself could/should "clean slate" (aka unmount remount I guess) the thumb every once in a while if there has been activity followed by no activity and no opened descriptors for a few minutes since that would cover a majority of the cases.

You have a point with those dialogs. I didn't use Vista but I remember all the clamour about UAC and how it further trained users to click blindly without understanding what's going on. Setup.exe's next next next could have been the first serial offender of that kind.

I'm sorry for that other issue. How does Windows complain exactly?

Same thing can happen with newer versions of Windows if you mount your C:\ NTFS drive from within Linux, then go boot into Windows. The warning basically says in so many words, the drive has not been cleanly unmounted and it needs to be checked. I've seen it, but I don't have the exact text handy.

In a geologic time scale at least, I believe that was actually a "new feature" some time after Windows Vista and maybe even after 7.

Linux actually does this on purpose, and has for some time. The NTFS driver was kind of scary for a long time (not sure if it still is) - read/write support was beta quality at best. So, the developers of the driver made Linux mark every NTFS volume as dirty, once it was mounted read/write. Then, when you booted into Windows, it would see it as a dirty volume, and do a file system consistency check on it - which is what the Linux driver was aiming for.