Some of that stuff is a result of legacy issues where Microsoft tried to handle badly made USB devices as well as possible. For example the reason Windows used to try and install the device again every time you switched ports was because USB device vendors really often didn't use a unique ID so identifying the device was tricky. Coupled with the multi-year release cycle that Windows had and Microsoft's mission to keep backward compatibility meant we had to put up with a lot of this stuff for a long time.

I'm wondering why Microsoft didn't add the unique serial number requirement to its WHQL driver testing, allowing vendors who realize too late that their shipped devices don't have a unique serial number to add the "magic registry key" (for ignoring the serial number) to their next WHQL driver candidate.

If the WHQL driver testing didn't exist at the beginning of USB then I imagine it would be for backwards compatibility.

"legacy issues"? If only. Some vendors still do this stuff today.

In Windows 8 its pretty fast(less than 5 seconds, just tried) but it did come up with a prompt saying new device found. I don't know if you realise that you are comparing an OS released in 2001(winxp) to Ubuntu, an OS that wasn't around until three years after XP's release.Chances are you are even comparing it to a version of ubuntu that is much more recent that it's 2004 initial release.

The initial Ubuntu release leaned heavily on Debian -- so I don't think the comparison is entirely unfair. Debian started in 1993, and Debian 1.1 "Buzz" was released in 1996.

Now, I can't really remember when I first came across an usb device -- but I also can't remember them ever causing me trouble in Debian.

Win 7/8: the device install process is still there but it's instant, you wouldn't even know if it weren't for the notification popup in the tray.

My issue on the other hand, is that it keeps asking to "scan and fix errors" when you plugin thumb drives if you take them out without using "eject" first.

I think that's a good idea. You can lose all the drive by pulling it out without stopping it first. It happened to me a couple of times. Even if that scan and fix thing was only a way to scare people into ejecting drives, I think it's worth it.

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.

What does the firmware have to do with it? I don't think the firmware knows anything at all about what you have stored inside the 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.

I thought the "scan and fix errors" is file-system dependent. IIRC, if you're using something ancient and dumb like FAT32, it doesn't show up, but if you use something non-ancient and intelligent like NTFS it does. (I don't know how exfat is handled).

Try pulling out a mounted ext4 drive on Linux, it will also be marked dirty and request fsck.

>if you take them out without using "eject" first.

That's not exactly true. That only happens if the NTFS volume has a dirty bit set. That happens when you corrupt something and some check fails. I pull drives in and out all the time without ejecting and almost never see the error you mention.

If you pull the drive when there's a write going on, then you'll activate the dirty bit and get that message.

I've noticed that OS X seems to flag a USB drive as needing to be scanned until it is ejected. More than once I've copied files off a USB device and unplugged without ejecting and as soon as it's plugged into windows it comes up with scan option.

It does get you into the habit of ejecting the drive first

There's also the dumbed down interface that prevents you from partitioning flash drives.

Possibly because it's a bad idea. You can do it, but it breaks some things which assume removable drives never have multiple partitions.

Also, many removable drives don't have a partition map.

But the same tool would let you create a partition map...

And erase all your data.

This is the behavior it has for non-removable disks. Why would it be different for removable ones?

That's shameful negligence. There's no reason the drive shouldn't be fully consistent seconds after activity on the drive goes idle. What responsible driver writer would leave uncommitted blocks indefinitely!

Said as a driver writer who always commits blocks on an activity one-shot.

Who said anything about "indefinitely"? It's very possible for a user to pull out the drive within seconds after hitting "save" - or even at the same time.

Everybody in the thread were talking about 'indefinitely' - you are forced to hit 'eject' to safely remove USB storage. This is required even if its many seconds or minutes after use.

Hm, I thought that was just in case some other process was using the disk. I mean most of the time, you can yank a FAT32-formatted drive out without losing data.

Others on the thread report otherwise. I'm with you; I will take my drive when I'm done, and never am going to ask 'mother may I'. If it fails, I'll file a bug report. Its a minimum standard of function in my viw.

Not only pen drives but also keyboards and mices. At home I often switch my keyboard from one laptop to the other and while it's always enabled near-instantly on linux it always takes a few seconds on windows (and especially the first time). It always annoyed me.

This is actually one of the few areas where linux is significantly superior to windows from an average "destktop" user's perspective. For instance getting PS3 controller to work on windows is (used to be?) very painful. On linux I plug it and it just works. Same for network-over-usb "RNDIS" devices but that might be more of a niche.

Same here. I normally work exclusively on macs & gnu/linux boxen, and when recently doing a stint in a windows 7 pro environment was in utter disbelief that plugging in a USB keyboard or mouse could occasionally require waiting over a minute before it became usable, often with a popup saying, "new drivers installed, you should probably restart" or similar. The environment is a bit odd - on a ship, so restricted internet and permissions, but even still. What the hell does windows need to go looking for drivers for a bog standard USB mouse???

It doesn't really know it's bog-standard until it looks up the USB VID&PID in the Windows Update database, right? I mean sure it could initialize as a basic HID device in the meantime but it would have to make you wait later when it uninstalled the HID driver and installed the new one, which seems like a pain as well.

Isn't it caused by different kernel designs? Or is it only user-space implementation that causes this? I mean how long does it take to recognize and initialize a device.

XP came out at the same time that Redhat 6.2 was out. I wonder how it recognized usb drives?

I've got a Redhat 6.2 CD. I wonder if it installs on some old laptop of mine but don't wait for news anytime soon :-)

I tried some old RHL and other Linux installs on qemu a while back, and it's hit and miss if they even work -- mostly miss in fact. (Back to RHEL 3 you're OK, RHL <= 7 didn't work). It seems qemu only emulates devices enough to work with modern Linux device drivers, which is natural because that's all most people test.

What?

Windows XP was published in October 2001. The latest Service Pack (SP3) was published in April 2008.

RHEL 6.2 was released in December 2011. So even the latest XP release is 3.5 years older than RHEL 6.2 (which does recognize USB drives quite fine).

He means this: https://en.wikipedia.org/wiki/Red_Hat_Linux#Version_history

Right, I just didn't expect anyone would compare to that since RH has been not really usable for quite some time (unlike Windows XP). (Usable in the sense of getting any recent application versions to install, not to mention getting security patches). Is there really someone actually running RH 6 from the year 2000?

(I was actually thinking that if the comment were referring to RH prior to RHEL, we were talking of a version that was still using a.out binary format, but that was not so, I was off by some three years, it came in RH3).

There were many versions of Red Hat before the RHEL run started. I believe that's what GP was talking about.

Red Hat Linux 6.2 ("Zoot"), not Red Hat Enterprise Linux 6.2.

My favorite similar WTF Windows behavior (I hope this is fixed by now):

Drag a file onto an application in the taskbar (as you would with a Dock icon in OS X), and it doesn't just fail to open it in that application—it actually gives you an alert saying "you can't drag things onto the taskbar" or something like that.

So they built in the ability to tell people they can't do it, instead of building the ability to actually do what people clearly already wanted to do. Classic Microsoft UX.

There's a discussion of this on the same blog: http://blogs.msdn.com/b/oldnewthing/archive/2004/11/24/26923...

The reason it's not allowed is probably because it's unclear what it should do. Windows doesn't have a means to do a generic drag-and-drop onto a whole application. They'd have to get every application updated to support it.

I'm not that hard on MS, I learned so late that you could drag icons on taskbar-minimized application to reopen them and then drag the file to use it. Saw that from an average guy dropping mp3 files in winamp. I was silently screaming in awe.

I switch between fedora, osx and windows 8.1 on the regular. It's not fixed, and drives me crazy every time I have to wait for the window to open before I can plop down my file.

Yeah, that one is annoying for the message and the non-effort by MS behind it.

To be fair, newer versions of Windows are much better in autodetecting devices when compared to XP.

I consult a lot which means I often have to use a Windows desktop because the IT staff needs it to run Office for people who only know one email client. I mostly work in Linux usually in a VM in these case. To you point, on a new machine designed to run Windows 7, 3 times in the past few months I plug in my external keyboard and it fails. The only resolution is to reboot the windows machine. At least once I've had my USB headset fail, had to reboot Windows. In the past year on a different machine also designed to run Windows I could not get it to detect my Android phone while my Ubuntu desktop has never failed on 3 different machines running Ubuntu.

When people say in any thread that Windows driver support is superior to Linux; the answer from my experience on a number of machines is still no.

From my experience with windows 8 is even slower, it consistently stays there for 5 minutes saying it is installing etc (but sometimes the drive is ready within 30sec, but the message stays)

Well this still happens in Windows 7.