Microsoft Drops 'Safe Removal' of USB Drives As Default In Windows 10 1809 (betanews.com) 171
Mark Wilson writes: Since the arrival of USB drives, we have been warned that they need to be 'safely removed' using the correct method in Windows, rather than just being yanked out — but now this changes.
With Windows 10 1809, Microsoft is changing the default setting that's applied to USB drives and other removable media. The change means that the default policy applied to removable storage devices is Quick Removal rather than Better Performance — so you can now just pull it out without a second thought.
With Windows 10 1809, Microsoft is changing the default setting that's applied to USB drives and other removable media. The change means that the default policy applied to removable storage devices is Quick Removal rather than Better Performance — so you can now just pull it out without a second thought.
Awesome (Score:2, Insightful)
Finally this annoying stupid misfeature will go away. Now if they only could with the horrible fake scanning for "fixing errors" after you've used a USB stick on Linux...
Re: (Score:2)
Finally this annoying stupid misfeature will go away.
This hasn't existed since 2001, the story is wrong. I am willing to bet you're not actually annoyed by this, or that you just use the remove hardware button because monkey see monkey do rather than actually understanding why you haven't needed to do it for 18 years.
Re: (Score:3)
Re: (Score:2)
NTFS is Microsoft's file system.
And they're welcome to it, since USB keys are formatted FAT32. Which is also a MS standard, but a documented, published one. So it should be fairly easy to check whether Windows complies with the FAT32 specification or not. Given Microsoft's track history of standards compliance, I'd say "not".
Who cares what MS says (Score:1)
Just pulling it out is not safe. Protect yourself.
Re: (Score:3, Funny)
Software is like sex. Make just one mistake and you've got to provide support for a lifetime.
Pull the other one (Score:2)
so you can now just pull it out without a second thought.
I get that the writer is trying to provide a simple description of the changes, but that is not good advice. Honestly? Just "No." If you yank your drive out in the middle of a write transaction, you're taking your chances. Not having the caching enabled just reduces the risk. Besides, wasn't the default for removable devices always "Quick Removal"? I could be misremembering, but I believe that's been the default setting when I've inspected a device for as long as a care to remember.
Re: (Score:2)
Besides, wasn't the default for removable devices always "Quick Removal"? I could be misremembering, but I believe that's been the default setting when I've inspected a device for as long as a care to remember.
That's how it has been from Windows XP to Windows 7 at least, that I recall.
Re: (Score:3)
That screenshot is from Windows 7. It's also the default on XP as well.
I smell BS (Score:5, Informative)
The only exception is when a drive is not the system drive but is connected to an internal potentially hot-swappable interface such as an AHCI SATA port. Those get set to "Better Performance" by default because they're almost always not in a removable tray nor connected by eSATA, even though they're technically hot-swappable. Of course, that's not what this Slashdot post is talking about at all, so again...WHAT IS THIS POST EVEN TALKING ABOUT?!
Re: (Score:2)
Beginning in Windows 10 version 1809, the default policy is Quick removal.
So MS at least thinks you are wrong.
Re:I smell BS (Score:5, Informative)
Re: (Score:2)
Yep, even the configuration window says it's the default (link to a screenshot from elsewhere): https://msegceporticoprodasset... [windows.net]
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
So MS at least thinks you are wrong.
MS can think what it likes. It clearly doesn't know it's own system. I still have an 1803 system here as well as Windows 7 and Windows XPs in VMs, and if I put any USB stick they come up with Quick Removal set as the default policy.
This was something introduced in Windows XP. Here you go, from the Windows platform design notes in 2001:
Operating System Write-Caching Policy for Storage Devices
Because of the possibility of data loss or corruption when storage devices are surprise-removed, removable storage de
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The only exception is when a drive is not the system drive
There's more exceptions than just this. It's actually in control of the developer. There's a variety of ACPI related settings or drivers that can set the removal policy to "ExpectOrderlyRemoval" from the default "ExpectSurpriseRemoval".
But I've yet to see a device do this.
Re: (Score:2)
Re: (Score:2)
Also, if you switch a drive's performance setting, it remains that way on that computer until its entry in Device
Re: (Score:3)
Windows XP [techjunkie.com]
Windows Vista [tomshardware.com]
Windows 7 [cnet.com]
Windows 8.x [trishtech.com]
Windows 10 [microsoft.com]
Re: (Score:2)
Those articles appear to discuss the *user* setting quick removal. I believe the OP is about MS making quick removal the *default* starting with Windows 10 1809.
Re: (Score:2)
pull it out without a second thought (Score:2)
Safe or not? (Score:2)
Whether it is safe to just yank your USB drive out at any random time, or equivalently, unexpectedly lose power, depends on whether the file system employs an accurate, reliable atomic commit, such that even if you pull the drive out in the middle of a DMA transfer, the data and metadata on the drive will always be consistent as at some recent point in time, even if incomplete.
You can rest assured that Microsoft has no such thing, but evidently that does not slow them down a bit.
Re: (Score:2)
You just never stop with the irrelevant bullshit do you. Literally no one here is talking about removing a device mid transfer other than you. I've told you before, replying off topic about things that no one is discussing is a sign of a severe mental condition.
Get professional help.
Re: (Score:2)
Ow! Something bit my ankle, I think it was you.
Re: (Score:2)
I feel kind of weird trying to impart knowledge to you, I should probably not bother. But why do you imagine there ever was a "safe to remove" mechanism, if not to avoid removing in mid-update? Try not to blow a fuse now.
Re: (Score:2)
I feel kind of weird trying to impart knowledge to you
I'm sure you did, but that "knowledge" just left your body through your ankle to try and spare us all the pain. It wasn't me biting you. But okay I'll bite now:
But why do you imagine there ever was a "safe to remove" mechanism, if not to avoid removing in mid-update?
You do realise that the safe to remove mechanism actually didn't work if you were mid-transfer right? The feature existed to flush caches and mark the file system as clean and would fail if you were stupid enough to try and use it while actively accessing the disc. Mind you no one was actually stupid enough to try and remove something mid copy which
Re: (Score:2)
It was *never* and is not now about atomic commits on a file system.
Yes, it is now and always was about atomic commit, you knucklehead.
No point (Score:2)
The real problem is that Windows writes to drives all the time by default (updating metadata such as "last accessed"). I hate having to mess with the automount settings every time I need to do some data recovery, because otherwise Windows will trash everything in sight once it gains write access to any device, even if the filesystem is known to be unclean. I once plugged a Win10 formatted hard drive into a Win7 machine, and in an instant, every file was invisible because Win7 can't handle Win10 security
No they didn't (Score:2)
The default policy for USB devices has been to disable write caching and set the "Quick Removal" policy since the days of Windows XP. MS even published a lengthy document about it in 2001 describing how drivers would need to override this behaviour.
This has remained the default policy through Windows XP's various service packs, Windows Vista, Windows 7, and I figured maybe they introduced a regression at some point recently so I decided to plug a whole lot of devices into my vanilla Windows 10 pro 1803 mach
Re:Good luck with that (Score:5, Insightful)
Sometimes customer and software availability does not give you a choice. But you already knew that answer. Being opposed to Windows use for anything is fine, I am too, but your childish stance is harming the cause.
Re: (Score:2)
Windows in a VM requires twice the RAM of Windows on metal. If you use a VM, you need RAM for both the host operating system and the guest operating system. If your laptop is already maxed out, that's not fun. Plus you're still paying $200 for a Windows 10 Pro license, plus data overage fees to your ISP when the PC downloads big updates twice a year on Microsoft's schedule.
Re: Good luck with that (Score:1)
Internet access has been cheap, fast and unlimited everywhere in the world for a good ten years.
Re: (Score:3)
Re: (Score:1)
Be thankful you do not need to put it into a caddy before inserting it into the drive.
Re: (Score:1, Flamebait)
If your data is valuable, why are you even using Windows?
Because with magic Onedrive integration my entire computer can melt into a puddle on the ground and be locked up by randsomware and yet all my data is still safe and I don't even need to use any of those complicated techie things that the nerds tried to explain to me. ... I think they used a word "backup". Sounds like something people did in the past before the clouds came over.
Now maybe you should back up and take a good look at the absurd and stupid arguments you're making given the critical wealth and kn
Re: Good luck with that (Score:5, Informative)
"Quick removal" means the OS will sync all data to disk BEFORE telling you the copy is complete. So if you wait until the OS says the data has been copied, you will be fine.
This is how floppy disks used to work. As soon as the copy completed the light would go out and you could eject the disk. It really should have been that way by default from the start with thumbdrives.
Re: (Score:2)
I know that. You know that, But the average user? Not so much.
Re: (Score:2)
Re: (Score:3)
A smart programmer would cache the copy and even IF the use yanked the USB out, the program that I wrote would know to warn that the data isn't completely copied and if they stuck it back in, it would pick up where it left off and copy the rest. Today's DVD players do something similar when you yank a DVD in the middle of play.
That's what I/we did way back when. But hey, I'm just a programmer and not an "engineer" or a "scientist". So, ignore what I say about some stupid issue that was solved 30+ years ago.
My bad.
Gee, if only Windows would throw up a prompt if you pull the drive out during a copy. Maybe title it "Interrupted Actions", explain that the copy was interrupted because the drive was removed, and give the user options like Try Again, Skip, or cancel. And if you put the drive back and click Try Again, it would continue the copy.
You are showing your age (Score:2)
that you even know about "Try again, Skip or Cancel?
Re: (Score:3)
Solved a long time ago (Score:5, Funny)
Yes, I agree that these problems already had solution a lon....
Disk access failure.
Abort, Retry, Fail? _
Re: (Score:3)
Better to phrase it "abort, retry, fail?" I think.
Re: (Score:2)
That really only works for OS-initiated disk activity. Think about what would have to happen with applications, which can (as they should) access disks in any way their programmers need or want to. Also, where does the state for an incomplete transfer exist? At what point is it invalidated, and for what reasons? In the real world, this is a lot harder than you're thinking it is...
Re: (Score:2)
Re: (Score:2)
When you look at how Microsoft implemented USB initially it's really painfully obvious that they didn't expect the "surprise removal" failure mode. Not just USB drives, things like USB serial ports would screw up pretty badly if not closed and ejected properly first.
Worst still they decided to use FAT as the filesystem, probably because that's what they had. FAT lacks journaling so a surprise disconnect can corrupt it easily. Their crappy solution was to have two copies of all the important FAT data so usua
Re: (Score:3)
Worst still they decided to use FAT as the filesystem, probably because that's what they had. FAT lacks journaling so a surprise disconnect can corrupt it easily.
Even with journalling, you can easily corrupt flash media, due to internal operations of the flash media firmware (wear levelling). Also, USB sticks are optimized for the particular preformatted FAT system. It's best not to change it.
Early gen thumb drives were slow as molasses (Score:2)
It always has been, with flash drives. (Score:2)
This change extends that behavior to USB connected hard drives.
Re: (Score:2)
Re: Good luck with that (Score:4, Informative)
I find it easier to use the sysinternals command line tool handle rather than procexp for this use.
C:\Temp>handle /?
Nthandle v4.21 - Handle viewer
Copyright (C) 1997-2018 Mark Russinovich
Sysinternals - www.sysinternals.com
usage: handle [[-a [-l]] [-u] | [-c [-y]] | [-s]] [-p |] [name] [-nobanner]
-a Dump all handle information.
-l Just show pagefile-backed section handles.
-c Closes the specified handle (interpreted as a hexadecimal number).
You must specify the process by its PID.
WARNING: Closing handles can cause application or system instability.
-y Don't prompt for close handle confirmation.
-s Print count of each type of handle open.
-u Show the owning user name when searching for handles.
-p Dump handles belonging to process (partial name accepted).
name Search for handles to objects with (fragment accepted).
-nobanner Do not display the startup banner and copyright message.
No arguments will dump all file references.
For example:
C:\Temp>handle VBoxSharedClipboard
Nthandle v4.21 - Handle viewer
Copyright (C) 1997-2018 Mark Russinovich
Sysinternals - www.sysinternals.com
VirtualBox.exe pid: 6088 type: File 50: C:\Program Files\Oracle\VirtualBox\VBoxSharedClipboard.dll
VirtualBox.exe pid: 8008 type: File 50: C:\Program Files\Oracle\VirtualBox\VBoxSharedClipboard.dll
Re: (Score:2)
It's still better than the current solution, where data might be cached in RAM to be written unto the flash driver later.
So this change is an improvement.
Re: (Score:1)
The way operating systems handle removable USB media is retarded. Data should never get corrupted when you remove a device; or if that's not possible, the OS should warn you upon disconnect, give you a chance to plug the device back in, and continue where it left off after you plug the device back in. Why can't this happen? Looking at Linux too. Why after an accidental connection/reconnection does the device not come back and continue operation as the same device? If a USB drive is accidentally disconnected
Re:Good luck with that (Score:4, Informative)
AmigaOS had this feature, if you ejected a floppy that was in use it would tell you to put it back in and wait for you to do so...
Re: (Score:2, Funny)
So did early macs. It was particularly fun if you only saw the message *after* you'd done passed the disc to a friend, who had, say, completely overwritten it.
Mac: please insert disc x.
User: but it no longer exists.
Mac (refusing to do anything else): please insert disc x.
User: I can't!
Mac (still refusing to do anything): please insert disc x.
User: Oh ffs... here's the disc, though you probably won't recognise it.
Mac (still stuck): please insert disc x.
User: Oh ffs *yanks cable*.
Re:Good luck with that (Score:5, Informative)
It's not really practical today.
AmigaOS could do that with floppies because back then the computer was 100% in charge of the drive and knew exactly what had gone through and what not.
A modern disk runs an entire OS of its own, and very possibly lies to the OS about its internal state, because lies look better on benchmarks. Just because the drive says "this has been saved", doesn't necessarily it has been.
That means the OS can't really do what you want reliably. It might work with some drives, and fail miserably with others.
If every hard disk was truthful about what's on the platter, and every SSD had the capacitors needed to finish work, this would work nicely. But we unfortunately don't have that.
Re: (Score:1)
Re: (Score:1)
They aren't likely to unplug the drive during the copying. Before this change, Windows would copy the data to RAM and then lie and say the copy was done. Now it won't, and Windows will say the copy takes longer.
Re:Good luck with that (Score:5, Insightful)
This essentially just shows that MS does not care about your data at all.
To the contrary, they are lowering performance to improve data safety.
A larger write will take time, and data will be corrupted if you just "yank it out".
Users yank it out anyway. This change will make it safer for them.
Since nobody uses thumb drives for high performance computing, this change is a sensible improvement.
Re: (Score:2)
Use any filesystem that supports transactions, and you can have both safety and performance. It's especially easy to do for whole-file writes which are the usual way of using USB sticks.
Not sure if NTFS transactions work sanely, but if they do, here's compat with any version of Windows since Vista.
Re: (Score:2)
Transactions don't help if the OS claims the write is done before the write has been committed to hardware.
This isn't a transaction problem. It isn't a file system problem at all. It's a write-cache problem. In other words, a problem in the communication between the OS and the physical hardware. In things like hard drives, write caching makes sense for performance reasons, and literally every OS does it. But when the OS treats the USB as a temporary hard drive instead of as proper removable media, and
Re: (Score:1)
It's not just the OS lying about a write being complete. The hard drive controller can lie and say the write is complete when really just queued up to be written. Same for the hard drives themselves. Most modern hard drives have an internal write cache that's enabled by default.
Normally, it doesn't cause too many problems, but for things like transactionaly consistent databases, it's a really really big deal when the H/W lies about a write being complete.
At work, I actually had to test this using a r
Re: (Score:1)
That may well be true, but Microsoft's implementation of how I can change the option leaves a lot to be desired.
You can change the policy setting for each external device, and the policy that you set remains in effect if you disconnect the device and then connect it again to the same computer port.
I have multiple ports on my machine. I may plug a drive into any of them. I want a device to be treated t
Re: (Score:2)
Because the manufacturer of the device cheaped out, and didn't give each device a unique serial number. The OS can't really tell the difference between different devices.
Re: (Score:1)
In which case they wouldn't be able to handle it in the same port either!
No, this is MS daftness.
Re: (Score:2)
But MS has decided that I have to set things for each port separately. Why?
The USB standard specifically enumerates the same device on different ports differently. This is nothing to do with Windows. Plugging any device in any port on any OS will see it as a "new" device if never seen on that port before.
Re: (Score:1)
But it is daft to treat that "new" device differently when it is clearly the same device.
Re: (Score:3)
I think the point is that writes are no longer cached, so copies and other writes will now take noticably longer, but when it's done it will actually be done.
I argue that this is how it should have been from day one, rather than the idiocy they had done up till now.
Re: (Score:2)
MS does not care about your data at all
This would rather be good news from some point of view.
As for data corruption, some changes might be made to libraries, file manager and kernel FS subsystem in order to wait for the complete data flush to the removable device.
Re: (Score:2)
Much as I hate Microsoft, I don't think you are correct. I don't think you understand the change. If you read the MS page (not the summary, or the article on betanews), this become clear.
I think that what is changing here is that the OS will attempt to write to USB drives as quickly as possible, instead of caching the data and delaying the write in a manner that would improve performance.
The net result is that, at any given moment, your data is more likely have been written to a USB drive, and hence it is m
Re: (Score:1)
Because people were pulling the damn USB sticks out anyway. They care, but they were tired of dumb people complaining 'why do I have to safely remove hardware when I've finished with it', not realising the OS hadn't flushed buffers to the device.
What they've done is disabled write-buffering by default; so the write won't report back to the software as 'done' until it's actually on disk. Thus, the 'file saving' progress bar in the software will take longer but is going to be actually flushed to disk when t
Sometimes it won't let you (Score:4, Funny)
I get this condition, especially after editing a large MS-Word file on a USB drive and exiting, that Windows never tells you it is OK to pull out the drive.
I am in a hurry, late for a meeting or to catch a ride home, and I never get the "Safe to Remove" message. So I end up having to do a Shut down on the computer to remove the drive when Windows has saved ev-er-y-thing it has cached, but wouldn't you know it, I have to wait for an Update to complete before Windows even shuts down.
This is when one wants to throw the computer out the window, but I never know if it is OK to yank the USB drive before doing this?
Re: Good luck with that (Score:2)
The point is that when the dialog indicating a copy disappears, then the copy is complete. Since Windows 95 that hasn't been the case, even on slow media like floppies, Windows would have a write cache and finish a write when the system was "less busy".
Re: (Score:2)
Indeed since Windows 95 that wasn't the case. Since Windows XP on the other hand it was. You're complaining about something that was fixed 18 years ago, which incidentally is how long this option that for some reason is incorrectly shown in the 1809 changelog has actually existed. And no they weren't fixing a regression, the default is the same on 1803.
Re: Good luck with that (Score:2)
I have done this hundreds if not thousands of times on Windows and I've yet to experience any data corruption. Do that on "user-friendly" macOS and it has a nervous breakdown.
Re: Good luck with that (Score:2)
Yeah millions of lucky people do regularly without any negative consequences. I would suggest that your students have been very unlucky instead.
Re:Good luck with that (Score:5, Insightful)
And how would the average user know? This is an unsafe default, plain ans simple. It is asking for people to get hurt. It is exceptionally bad design.
Re: (Score:2)
Maybe because there's a dialog telling the user that the copy is still going on?
The computer, and therefore the user, may not know (Score:2)
If there is a RAM cache in the drive, then the computer may not even know that the data has not yet been committed to the disk. So It can't warn the user. And this is unlikely to change.
But this change is not to allow users to remove the disk, it is to make it less likely to cause problems. It means that the computer will make sure that, as far as it is aware, the information is written to disk before telling the user that it is done - by closing the explorer copy animations, or by signaling to running prog
Re: (Score:2)
Your sarcasm detector is broken.
Re: (Score:2)
It is the current default that is unsafe. (Score:2)
The current default treats USB connected hard drives like internal drives, and assumes that they will be safely shut down before removal. This allows the computer to store data temporarily in the computers memory, allowing the programs to continue while it writes out the data in the background.
This change assumes that the drive could go away at any time, so makes sure that data is written to disk before the applications close or the animations disappear. But you can still get caught out if there is data in
Re: (Score:2)
It takes a dumbass to recognize one.
Re: Good luck with that (Score:5, Funny)
I yank mine constantly.
Don't we all. It just feels so good.
Re: (Score:2)
Re: Good luck with that (Score:2)
Re:I don't have Windows 10 (Score:5, Insightful)
Re: (Score:3)
Windows 98 killed my pappy!
Stop complaining about how windows worked 15 years ago.
Re: I don't have Windows 10 (Score:2)
No it was fixed a very long time ago
Re: (Score:1)
C’mon, stop holding back - tell us how you REALLY feel.
Re: (Score:3)
Look be fair, just like that other user, I have also felt the impact of the questionable functioning of M$ write behind caching, where it pretends to write data to any media and well, any tiny hiccup and that data gets written all over the place or not at all or anything in between. The only safe way to run M$ write behind caching, turn it off, seriously. It just did not work that well or reliably and that is very problematic.
I found that windows machines run a whole lot more reliably when 'ALL' write behi
Re: (Score:3)
well for example, EVERY cluster you write in a new file needs to mark that cluster as used, and that's a change in the free space map and the free cluster count, as well as the cluster list and directory's size indicator for the file. Obviously, updating it every time you write one more cluster would be grossly inefficient, so it's done in blocks, hopefully adjusted to the write speed of the device, so that most of these things are only updated maybe once a second. So if you yank a drive while it's saving