Slashdot Asks: Do You Need To Properly Eject a USB Drive Before Yanking it Out? - Slashdot

Slashdot Asks: Do You Need To Properly Eject a USB Drive Before Yanking it Out? - Slashdot
Close
binspam
dupe
notthebest
offtopic
slownewsday
stale
stupid
fresh
funny
insightful
interesting
maybe
offtopic
flamebait
troll
redundant
overrated
insightful
interesting
informative
funny
underrated
descriptive
typo
dupe
error
101740704
story
In a story earlier this week,
Popular Science
magazine explored an age-old topic: Do people need to safely eject a USB stick before they pull it from their computer? The magazine's take on it -- which is,
as soon any ongoing transfer of files is complete, it is safe to yank out the flash drive
-- has unsurprisingly
stirred
debate
. Here's what the magazine wrote:
But do you really need to eject a thumb drive the right way? Probably not. Just wait for it to finish copying your data, give it a few seconds, then yank. To be on the cautious side, be more conservative with external hard drives, especially the old ones that actually spin. That's not the official procedure, nor the most conservative approach. And in a worst-case scenario, you risk corrupting a file or -- even more unlikely -- the entire storage device.
To justify its rationale, the magazine has cited a number of computer science professors. In the same story, however, a director of product marketing at SanDisk made a case for why people should probably safely eject the device. He said, "Failure to safely eject the drive may potentially damage the data due to processes happening in the system background that are unseen to the user."
John Gruber of
DaringFireball
(where we originally spotted the story),
makes a case for why users should safely eject the device before pulling it out
This is terrible advice. It's akin to saying you probably don't need to wear a seat belt because it's unlikely anything bad will happen. Imagine a few dozen people saying they drive without a seat belt every day and nothing's ever gone wrong, so it must be OK. (The breakdown in this analogy is that with seat belts, you know instantly when you need to be wearing one. With USB drives, you might not discover for months or years that you've got a corrupt file that was only partially written to disk when you yanked the drive.)
I see a bunch of "just pull out the drive and not worry about it" Mac users on Twitter celebrating this article, and I don't get it. On the Mac you have to do something on screen when you eject a drive. Either you properly eject it before unplugging the drive -- one click in the Finder sidebar -- or you need to dismiss the alert you'll get about having removed a drive that wasn't properly ejected. Why not take the course of action that guarantees data integrity?
What are your thoughts on this? Do you think the answer varies across different file systems and operating systems?
Related Links
Bot Tweeted Names And Photos Of Venmo Users Who Bought Drugs
Microsoft Drops 'Safe Removal' of USB Drives As Default In Windows 10 1809
Some Colleges Cautiously Embrace Wikipedia
This discussion has been archived.

No new comments can be posted.
Slashdot Asks: Do You Need To Properly Eject a USB Drive Before Yanking it Out?
More
Slashdot Asks: Do You Need To Properly Eject a USB Drive Before Yanking it Out?
Comments Filter:
All
Insightful
Informative
Interesting
Funny
The Fine Print:
The following comments are owned by whoever posted them. We are not responsible for them in any way.
yes,
Score:
, Funny)
by
Anonymous Coward
writes:
on Sunday July 22, 2018 @10:09AM (
#56989670
one should always eject before pulling out
Share
Re:yes,
Score:
, Funny)
by
Anonymous Coward
writes:
on Sunday July 22, 2018 @01:15PM (
#56990504
one should always eject before pulling out
Also remember to use protection against virus
Parent
Share
Re: yes,
Score:
, Insightful)
by
Anonymous Coward
writes:
And what mount options. And what filesystem. And how busy the OS is and it's settings.
There are so many exceptions its best to just say always eject first. If you don't you are needlessly putting your data at risk.
Re: yes,
Score:
, Insightful)
by
Aighearach
( 97333 )
writes:
on Sunday July 22, 2018 @07:47PM (
#56991984
Horse shit.
I don't give a rat's ass what the drive is doing when you remove it. If you want to plug it into a Pentax camera without having to reformat it first, you'll eject or unmount the drive before removal.
Lots of other devices have this same problem. The drive records if it was properly ejected or not. You have to know for sure if you want the ability to use it with any compatible device on the next insert, or if you want to have to risk needing to re-insert it, and then eject, so that your device will trust you that the drive is in a known-good state.
It is not enough to know what the drive is doing "at the time," you have to know what the drive will be doing in the future too.
Parent
Share
Re: yes,
Score:
, Informative)
by
c6gunner
( 950153 )
writes:
on Monday July 23, 2018 @01:32AM (
#56992924
Homepage
The drive records if it was properly ejected or not.
No, it doesn't. The filesystem on the drive might, though, depending on which filesystem it's formatted with.
This used to be an issue with many Linux distributions and NTFS in the past. If you tried to mount an NTFS filesystem which wasn't cleanly dismounted, it would throw an error at you and fail. For other filesystems it didn't matter.
Parent
Share
Re:
Score:
by
zifn4b
( 1040588 )
writes:
Or just turn off write caching for USB devices. In fact, it's off by default in Microsoft Windows. There are two options for USB devices, Quick Removal (default) and Better Performance (write caching).
More information
[howtogeek.com].
Depends.
Score:
, Informative)
by
msauve
( 701917 )
writes:
on Sunday July 22, 2018 @10:12AM (
#56989680
No mention of the OS or file system. Assuming Windows - there's a setting for "Quick Removal," which disables write caching and makes it so "you can disconnect the device safely", and another for "Better Performance," which doesn't and may cause grief.
Share
Re:Depends.
Score:
, Informative)
by
BenFranske
( 646563 )
writes:
on Sunday July 22, 2018 @10:37AM (
#56989796
Homepage
This is true. My recollection is also that somewhere along the line Microsoft changed the default in Windows. Traditionally in Windows all mass storage devices, think HDDs, had performance enhancing features such as caching turned on which can cause delayed writes while media like floppies had it turned off. The problem is that when USB 2 came out and USB mass storage became feasible people started unplugging USB drives as soon as the copy appeared to be finished even if the OS was really still writing to the drive in the background causing a potential for data corruption. In this era we were teaching everyone to eject USB drives before removing as that would force a clearing of the write cache before giving the OK to remove the drive.
Somewhere along the line (maybe Windows Vista?) it became apparent that the clumsy drive eject mechanism in Windows, combined with users frequently forgetting to do it, and the increasing popularity of flash drives made this a usability issue. At that point Microsoft changed how Windows handles USB attached mass storage devices and disabled or modified the performance features to flush the write cache as quickly as possible and keep copy dialogs on screen until the files were actually fully copied. At the same time a lot of flash drive manufacturers started putting access indicator LEDs on the drives so you could tell if the drive was being accessed. After this most Windows users stopped ejecting drives before removal and save for an especially odd case there seems to have been little data corruption which can be traced back to not ejecting the drive.
Parent
Share
Re:Depends.
Score:
, Informative)
by
thegarbz
( 1787294 )
writes:
on Sunday July 22, 2018 @01:02PM (
#56990422
My recollection is also that somewhere along the line Microsoft changed the default in Windows.
Yes, almost 17 years ago they changed that default. Windows hasn't enabled caching and the likes on removable drives since the release of Windows XP.
The only benefit you get of the safely remove feature is that windows won't let you remove the drive if it is actively being written to. But either way you will know instantly if you end up with a corrupted file if you don't safely remove as you'll get an error message for whatever program was writing.
Mr Gruber's scenario of hidden corruption just isn't a thing.
Parent
Share
Re:
Score:
by
Joce640k
( 829181 )
writes:
Maybe true, but...
If you just yank it, the next time you want to use it you'll have to go through "The file system on this disk may be corrupt, do you want to run CHKDSK on it" followed by several dialog boxes that need clicking.
Your idiotic "I'm going to yank it anyway" attitude just makes things worse in the long run.
Re:
Score:
by
kelemvor4
( 1980226 )
writes:
Maybe true, but...
If you just yank it, the next time you want to use it you'll have to go through "The file system on this disk may be corrupt, do you want to run CHKDSK on it" followed by several dialog boxes that need clicking.
Your idiotic "I'm going to yank it anyway" attitude just makes things worse in the long run.
Not if you're using a reasonably current version of windows. Honestly, until this idiotic thing got posted to slashdot I had forgotten about having to "eject" storage devices back in the day. Maybe it's a concern if you're using osx or some flavor of *nix. It is not a concern with windows.
Also, every usb device I own, and I have a large bag (probably 30 of various sizes) of them from tech conventions and the like... every one has an LED on it to indicate if read/write is going on. If the bright light i
Re:
Score:
by
Khyber
( 864651 )
writes:
"If you just yank it, the next time you want to use it you'll have to go through "The file system on this disk may be corrupt, do you want to run CHKDSK on it" "
Uh, no? Haven't seen that in about 15 years. I NEVER eject drives. Hell I hot-swap SATA all day. I never get asked to run a damn thing.
Re: Depends.
Score:
, Informative)
by
c6gunner
( 950153 )
writes:
on Monday July 23, 2018 @01:38AM (
#56992938
Homepage
If by "very old" you mean Windows 7, and by "odd FS choice" you mean FAT32 and NTFS, then yeah, sure.
I get that message all the time on the work computers because nobody ever bothers properly dismounting the damn flash drives.
Parent
Share
Re:
Score:
by
thegarbz
( 1787294 )
writes:
No, it tells you after the fact “you shouldn’t have done that”, which is something quite different than not letting you do it in the first place.
Err no it tells you before the fact and then doesn't proceed:
"Problems Ejecting #########. Windows is unable to stop the device ########. Don't remove this device whilit is still in use. Close any programs using this device and then remove it."
(And because it's a safe operation I just did it mid copy right now so I could post this error message here verbatim to let you know how wrong you are). Please don't speak so authoritatively on something so easily disproven.
Re:Depends.
Score:
, Interesting)
by
Joce640k
( 829181 )
writes:
on Sunday July 22, 2018 @01:45PM (
#56990628
Homepage
I remember back in the 1980s when the Commodore Amiga used to say:
"You MUST put the floppy disk back in or data loss could occur".
(or something like that)
If only modern operating systems had such technology.
Parent
Share
Re:
Score:
by
arth1
( 260657 )
writes:
When does the OS say "all done"?
Generally when the drive reports that the write has completed.
If the drive isn't truthful about that, and reports success back to the OS before the actual commit, things can (and thus will) go wrong.
Especially when combined with write amplification, where a well used solid state drive finds out it has to clear up some space and shuffle data around and re-initialize an entire sector before the actual write can be done - that can take a second or more.
I am very skeptical when I see solid state drives that
don
Re:
Score:
, Interesting)
by
Spazmania
( 174582 )
writes:
If your operating system was programmed well, the IO call writing to the USB drive would not return until all write buffers were flushed, would not permit large write buffers to a USB drive -and- nothing else would attempt to write the USB drive in the background.
Your operating system was not programmed well. Quick Removal only gets close.
Re:
Score:
by
Spazmania
( 174582 )
writes:
Do you?
The buffer is where the data sits while waiting for the receiver to finish receiving and accept it. The write() call can return immediately while the OS sends data from the buffer in the background. The write call can block until the OS finishes sending data from the buffer. Either way there's a buffer that holds the data being sent until the OS is done with it.
Re:
Score:
by
dinfinity
( 2300094 )
writes:
I can't help but think there is a a simple interaction (and possibly partly technical) solution to this:
Just indicate whether write buffers are definitely empty for a certain drive and ejection can be done safely if no other writes are started (an orange indicator next to the ejectable, for instance). It is silly that putting in a USB drive and yanking it out almost immediately is regarded as unsafe ejection or bad practice.
I understand that
theoretically
another process can initiate a write as you are yank
Re:Depends.
Score:
, Insightful)
by
willy_me
( 212994 )
writes:
on Sunday July 22, 2018 @12:31PM (
#56990308
Plenty of things could still go wrong. There is simply no guarantee that the OS will not be writing to the FAT due to some background process. Pull the drive at the wrong time and you corrupt the FAT. If one uses a journaling file system, yanking the drive becomes more feasible - but is still not a good idea.
Parent
Share
Re:
Score:
by
WatchMaster
( 613677 )
writes:
I always format usb drives as NTFS because it is more damage-resistant than FAT32. Not immune, but more resistant to several types of errors due to journaling.
That doesn't really help
Score:
, Insightful)
by
Solandri
( 704621 )
writes:
on Sunday July 22, 2018 @01:05PM (
#56990442
Because all it does is change the choice to "Do I eject the drive properly, or do I check to make sure "quick removal" is enabled and then yank the drive?" Unless you already
know
it's been set (i.e. you personally set it previously for this drive for this instance), the latter takes more time than ejecting.
The #1 cause I've seen for corruption of data/partition information on USB flash and external HDDs is yanking it out too quickly, just before the copy has finished. In theory a journaling filesystem like NTFS should be immune to damage from this. But for some reason it occasionally seems to corrupt the partition table making the entire contents of the drive inaccessible unless you're skilled enough to repair it manually (usual cause seems to be the partition type number got changed).
That's a 10 minute or so repair process if you know what you're doing. If you don't, it's probably 30-60 minutes downloading the tools and stumbling around trying to figure it out. And if you obeyed Windows when it popped up the
"You need to format this disk before you can use it" message
[sandisk.com] when you plugged the drive in again, and formatted it, now you're looking at several hours for file recovery with no guarantee you'll be able to recover everything. (They really need to add a second line to that message saying that formatting will destroy any existing data.)
All this risk and time wasted just to save a few seconds by not ejecting. So I advise people to
always
eject the drive before yanking it. The seatbelt analogy is very appropriate. It takes very little time to do, but the rare consequences if you don't do it can be devastating.
Parent
Share
You can't always eject first on Mac
Score:
, Insightful)
by
Anonymous Coward
writes:
on Sunday July 22, 2018 @10:13AM (
#56989686
I can't count the number of times I've tried to eject a USB drive, and Mac OS tells me it's "unable to eject the drive because it's in use."
Usually it's because Preview.app held onto some file descriptor for its stupid thumbnail of recent documents - not the list in the file menu, the one that pops up when you right-click on Preview in the Dock.
Apple used to promote the idea that the user is in charge. When I click "eject," the damn thing should eject!
Share
Re:
Score:
by
houstonbofh
( 602064 )
writes:
Apple used to promote the idea that the user is in charge.
Yeah, like cdroms that dont have eject buttons, and if you're old enough to remember that a floppy drive is, same crap there. I more surprised that Apple does not lock the usb-ports so you CANT unplug a thumbdrive without asking for authorisation from the mighty System7...
I remember when a PC power switch was actually a SWITCH and not a software interrupt! It had 4 big mains power wires.
This isn't a debate
Score:
, Informative)
by
Murdoch5
( 1563847 )
writes:
on Sunday July 22, 2018 @10:15AM (
#56989694
Homepage
Depending on the write method in use from the OS, you either have transferred the full contents of what you wanted, or you haven't. In the later, ejecting will finish the write cycle and in the first you're good to go. There is one other rare problem that can arise and that's file-system corruption. and you run the risk of it by just pulling your USB key out, although with any modern file-system, such as EXT4, BTRFS, ZFS, even NTFS, that chances of seeing corruption are rare.
Share
It's a question of percentages and value
Score:
by
SuperKendall
( 25149 )
writes:
any modern file-system, such as EXT4, BTRFS, ZFS, even NTFS, that chances of seeing corruption are rare.
That's all well and good until the "rare" event actually happens to some data that mattered to you.
If you place any value on your data at all, you will not want to chance even a "rare" data loss or corruption.
Save rolling to dice to power or hardware failures, not easily protected actions like removing a USB device from a computer.
Although I do have a humorous aside - I have an external USB reader that lo
Re: This isn't a debate
Score:
, Informative)
by
tepples
( 727027 )
writes:
{tepples} {at} {gmail.com}
on Sunday July 22, 2018 @10:26AM (
#56989752
Homepage
Journal
What is "âoesyncâ"? [1]
Even if you do type
sync
before ejecting, that doesn't keep some other process from opening and writing another file on the volume in the seconds between when you type
sync
and when you actually pull the plug. To prevent the possibility of corruption, you need to unmount the volume (and possibly remount it read-only) before disconnecting the drive.
[1] Rhetorical.
Parent
Share
Re: This isn't a debate
Score:
, Insightful)
by
drinkypoo
( 153816 )
writes:
drink@hyperlogos.org
on Sunday July 22, 2018 @10:52AM (
#56989860
Homepage
Journal
What is "ÃoesyncÃ"? [1]
A sign that Slashdot's text handling is pathetic.
Parent
Share
Re:
Score:
by
CaptainDork
( 3678879 )
writes:
It's a sign of operator error.
We're nerds.
Work around it.
Re: This isn't a debate
Score:
, Funny)
by
Hognoxious
( 631665 )
writes:
on Sunday July 22, 2018 @11:05AM (
#56989940
Homepage
Journal
It's either the Maori name for New Zealand or what Toilet & Douche re-branded themselves as a few years back.
Parent
Share
Re:
Score:
by
CaptainDork
( 3678879 )
writes:
Tell that to an old Windows NT server.
I plugged up an EHD for backup; ejected it; and it bitched, topping out the error log over and over again.
It thought the yanked EHD was performing poorly.
Service Technician
Score:
, Informative)
by
Anonymous Coward
writes:
on Sunday July 22, 2018 @10:18AM (
#56989714
I repair computers and macs for a living and have been doing so for more than 20 years.
Is it safe to yank a USB drive?
No, but the severity varies by OS.
On Linux or Mac? Somewhat, or at least safer than Windows, but I'd go ahead and unmount it anyway just to be safe.
On Windows? No. You can do it, but you're taking a gamble every time that doing so will break the partition tables. You might be able to fix that and get the data back off of it... or you might not.
Now, will I do it anyway, knowing the risk?
Absolutely, and especially on windows. I keep a drive just for moving diagnostic tools or software to windows computers while inside the OS and occasionally, windows decides it doesn't want to unmount it, so I'll yank it anyway. But that's with the understanding that everything on that drive can go 'poof' any time I do it and everything on it is backed up.
In short:
If you value what's on that drive, you shouldn't... but you should have more than the one copy on the drive of whatever you're moving around anyway.
If you don't have backups, it must not have been important.
Share
Re: Service Technician
Score:
by
Anonymous Coward
writes:
Microsoft does update a partition table when it sees it for the first time. It's an awesomely bad idea, but hey: Microsoft
You'd think. Theory vs practice. Undervoltage
Score:
by
raymorris
( 2726007 )
writes:
You'd think the partition table would be pretty darn safe since it's rarely updated. Yet, I've had to help people recover from lost partition tables many times. You can do forensics to discover where the partitions were, such as by looking for blovks that match the beginning of a filesystem, and for the first partition, testing the defaults.
One potential reason for this is that electronics designed to work at five volts can do literally ANYTHING when they have 2.5 volts supplied. You may notice some device
Risk
Score:
, Insightful)
by
xonen
( 774419 )
writes:
It's akin to saying you probably don't need to wear a seat belt
No, no and no.
As you may know, risk = damage x chance.
When i don't wear a seat belt and get in a crash, i might die or suffer severe injuries. That's big damage.
When i loose a file, i lost a few bits. I usually couldn't care less. It might be a photo or mp3 file. It might be a failed backup. Worst case it's a fortune worth of bitcoin. But i won't die from it.
Don't make analogies that just aren't true. Don't pretend a lost bit is the same as a broken body part. And to be on-topic - i usually just `yank` my t
Re:
Score:
by
angel'o'sphere
( 80593 )
writes:
As you may know, risk = damage x chance.
Only if the damage is monetary and you are in the insurance business. Otherwise risk and chance are two orthogonal axis.
E.g. the typical prisoner dilemma: you are sentenced to life time prison. You get offered to either stay and accept the sentence or walk through two doors: one door gives you freedom, the other door execution.
The
chance
is 50% for either freedom or death. The
risk
is death, and not an abstract number multiplied from two other numbers.
Re: Risk
Score:
by
Kjella
( 173770 )
writes:
The worst case is almost always that you die. You can die of a heart attack, a car crash, lightning strike, whatever. We have dismissed them because they are highly improbable. If it was 50-50 thereâ(TM)s a âoerealâ chance youâ(TM)ll die. It only looks like a 1D model after youâ(TM)ve evaluated the other dimension.
Catastrophic health care cost
Score:
by
tepples
( 727027 )
writes:
Worst case it's a fortune worth of bitcoin. But i won't die from it.
That depends on how your country handles health care finance.
Re:
Score:
by
houstonbofh
( 602064 )
writes:
When i loose a file, i lost a few bits. I usually couldn't care less. It might be a photo or mp3 file. It might be a failed backup. Worst case it's a fortune worth of bitcoin. But i won't die from it.
Funny you should say that. When it comes down to it, the biggest killer on this planet is a lack of money. So that loss of bitcoin could kill you if you needed food. Or if you owed the mob. Or if you needed an operation insurance would not cover. Many wars in the world about about nothing more them money.
If money really means nothing to you, you must have quite a bit of it by world standards.
Sigh.
Score:
, Insightful)
by
ledow
( 319597 )
writes:
on Sunday July 22, 2018 @10:25AM (
#56989742
Homepage
If you haven't written anything to the USB, yes, it's completely safe. Any filesystem that's writing data just because of your passive reading of the disk is a) stupid, b) should have recovery for such, c) shouldn't be writing anything important (e.g. a last access time, maybe?)
If you have written anything to the disk, and it's synced to disk (i.e. activity light is idle) then, yes, it's safe. This may be dependent on OS and whether you can see any activity light. Modern OS should mount without write-caching for external drives unless told otherwise, and any half-decent filesystem should survive a forcible unmount in such circumstances
If the USB is still busy churning after you copied files to it, and you yank it? Yes, you're gonna lose data.
That a bunch of "nerds" can't figure this out after all the years we've had USB disks etc. (I remember starting with them in 95 OSR2 / Linux 2.0 personally?) really worries me.
Same as floppies before it. Floppy only being read-from? You can yank it. Floppy was written to but has now gone idle? You can yank it. Floppy was written to and it still pulsing / flashing? Leave it alone.
Share
Re:
Score:
by
tepples
( 727027 )
writes:
If you have written anything to the disk, and it's synced to disk (i.e. activity light is idle) then, yes, it's safe.
The activity light comes back on just as your brain sends the signal to your arm to pull the plug. Still safe?
Re:
Score:
by
hcs_$reboot
( 1536101 )
writes:
+1
Re:
Score:
by
tepples
( 727027 )
writes:
Secondly, why is the computer doing things that you're not telling it to do?
People tend to forget what they
have
told the computer to do in the background, such as index text files for full-text search and index image files for thumbnail browsing.
Re:
Score:
by
houstonbofh
( 602064 )
writes:
If you haven't written anything to the USB, yes, it's completely safe. Any filesystem that's writing data just because of your passive reading of the disk is a) stupid, b) should have recovery for such, c) shouldn't be writing anything important (e.g. a last access time, maybe?)
That would be windows that by default updates the partition table when it sees a new disk. And while I agree with you, it is still the way it is...
Re:
Score:
by
DamnOregonian
( 963763 )
writes:
And if you cut out in the middle of an access-time-write, the filesystem at worst has an incorrect access time.
And herein lies our problem. Blind, proud, and dangerous ignorance.
There are a lot of layers in a file write. Even more layers when it's to a flash drive with built in wear-leveling.
You presume to know what the underlying filesystem, vfs cache, block scheduler, device driver, and the device itself are doing. In short, you are insane.
You do *not* want to pull power off that device simply because it's not receiving data to write from the PC anymore.
You are otherwise correct that atimes aren't commonly in
Depends
Score:
, Informative)
by
AlanObject
( 3603453 )
writes:
on Sunday July 22, 2018 @10:27AM (
#56989758
I used to write a lot of 8GB+ file system images to 16GB SanDisk devices using an Ubuntu 14.04 system. The caching it did was immense. The dd or the cp command finished in less than 60 seconds but when I did a umount command on the volume it would block for about 5 whole minutes or more while the cache emptied.
These particular USB drives have a blue activity LED on them so it wasn't hard to figure out what was going on.
In that use case yanking the USB would have been a big no no.
Share
Re:
Score:
, Informative)
by
Anonymous Coward
writes:
I used to write a lot of 8GB+ file system images to 16GB SanDisk devices using an Ubuntu 14.04 system. The caching it did was immense. The dd or the cp command finished in less than 60 seconds but when I did a umount command on the volume it would block for about 5 whole minutes or more while the cache emptied.
These particular USB drives have a blue activity LED on them so it wasn't hard to figure out what was going on.
In that use case yanking the USB would have been a big no no.
This is why dd has the argument "oflag=sync". I suppose you could also use "oflag=nocache", never tried it myself, but the man page suggests it has the same effect.
Likewise it's easy enough to add "&& sync" or "&& sync && umount
/your/device" to the end of a cp command. If you want to monitor it with a glance once in a while, try iotop.
I have also noticed that if I perform a copy with my GUI file manager the copy notification stays on until it's really completed. On a big copy a U
Re:
Score:
by
houstonbofh
( 602064 )
writes:
operating systems that don't (windows by default)
Which windows? That default changed with the versions...
I vacum my computers
Score:
by
CranberryKing
( 776846 )
writes:
all the time. Have carpeting too. The case is open often and a beer is balanced somewhere nearby that it probably shouldn't. Not the same as forgoing a seat belt at all.
RAM caches
Score:
, Informative)
by
dissy
( 172727 )
writes:
on Sunday July 22, 2018 @10:29AM (
#56989762
Depends how many places "confirmed" saved data can be cached in RAM.
Spinning hard drives have their own cache, which isn't written to the actual disk until either the cache is "full enough" or you instruct it to do so.
This data will be lost if you power the device down before the cache is flushed to disk, after the drive reported the data saved.
Flash sort of depends, an SSD for example tends to do the same thing, but there are different ways it can go about it.
Older SSDs can only write 4k blocks, it wasn't possible to write less data.
So to write for example 300 bytes, the controller has to pull in a 4k block to its RAM, edit those 300 bytes, and write out the entire 4k block again.
Pull power before this is done and your 300 bytes are gone.
"Removable" USB flash drives, the better ones at least, tend to not report data as saved before it really is, just to help avoid this problem. There is little hope for a non-technical person to know what their particular flash drive is doing however, and not even obvious to technical people either.
On top of that, your OS likely caches data to be written to any disk in RAM, completely independent of what the disk itself is doing.
If one is absolutely certain how all of these caches function, and can be completely assured all data is written in a method that doesn't rely on the disk claiming it is or isn't, then in that case it would be safe to power down the device.
For average and above average users, that will just not be true.
Even for experts, outside of a small set of cases like highly customized and tuned systems, it may be true the expert knows what is going on, but would tell you from that knowledge it wouldn't be safe and is a silly risk to take, with a high cost of data loss in exchange for a couple of seconds of time saved.
Hell, even I am still in the habit of issuing three 'sync' commands in a row before an unmount command, and that's despite the knowledge the unmount command will do a 'sync' call of its own!
But as this advice is for average or below people, as bad as it is, isn't the worst things commonly done.
Average or below people rarely even make backups, which has a far higher cost when (never IF) a drive fails. Corrupting a couple files on a single USB drive compared to not having any backups is like complaining your car only has 5 airbags instead of 6 while driving it off of a cliff...
Share
Re:RAM caches
Score:
, Informative)
by
dissy
( 172727 )
writes:
on Sunday July 22, 2018 @03:46PM (
#56991078
Yes, by older I mean roughly 20 years ago, some of the initial nand devices on the market.
These days a 128-256kB nand page size is typical.
I also recall Intel at least saying something about 512kB on some of their higher end offerings, but don't remember what class of devices that was about or if it's one of those "coming soon" things or not.
Fortunately even though the page size keeps going up, the flash write speeds also are going up, so it doesn't tend to take that much more total time to commit a write by the controller chip.
The window of opportunity for data loss doesn't change a lot because of that, but the amount of data that can be lost if you yank power during that window can be greater.
Parent
Share
Bad design
Score:
by
inking
( 2869053 )
writes:
on Sunday July 22, 2018 @10:30AM (
#56989766
My thoughts are that this is bad design and will hopefully be fixed in some future revision.
Share
Re:
Score:
by
evanh
( 627108 )
writes:
Yes it is bad design - called write-back caching. It's one of the dumbest of ideas for removables, sits alongside auto-run.
Removables should always immediately flush all write data, as in use write-through caching. I doubt it will ever be fixed though, it's been that way for 500 million years already.
Re:
Score:
by
houstonbofh
( 602064 )
writes:
It is. It is called "The Cloud!" It has all new bad design!
Should Have Guidelines for Program Behaviour
Score:
by
mykepredko
( 40154 )
writes:
You *should* be able to just yank out a USB drive but there's always the chance that a program has a file open and has modified it but not closed it which means, depending on the file system, the file (and maybe the drive) is corrupt until it is closed.
I would think that the idea application behaviour when it comes to files the guidelines should be:
a) Opens the file to read the contents and store in memory. Once this is done, the file is closed.
b) Searches and operations are done on the copy in memory.
c)
YES, eject first
Score:
, Informative)
by
thePsychologist
( 1062886 )
writes:
on Sunday July 22, 2018 @10:34AM (
#56989782
Journal
Ever think of testing this for yourself?
It's easy. Create a half a dozen or more files of random numbers or use existing large files. I created six files of a million random integers in Python. End result, six files of about 6.9MB each. Create an md5 checksum file when you make them.
Copy them to a USB stick, and then yank the stick right when the light stops blinking. Plug the USB stick back in. Watch and learn. Easily reproducible phenomenon are:
* Not all files even appear when the stick is plugged back in
* Some of the files might appear, but give I/O errors and won't even be complete
* A Few might pass the checksum integrity test
I'm on Linux Mint, but I have seen the results on other OSes as well. The OS caches the data to be written sometime, presumably to speed up file operations. There's a reason why eject exists.
Share
Sync and unmount.
Score:
, Informative)
by
Ungrounded Lightning
( 62228 )
writes:
on Sunday July 22, 2018 @12:36PM (
#56990324
Journal
Copy them to a USB stick, and then yank the stick right when the light stops blinking.
Two functionalities are key: Sync and unmount.
- Sync forces the filesystem to complete all in-RAM updates to blocks, write the blocks to the driver, and forces the driver to flush all pending writes to the backing store. Issuing a "sync" kicks off activity that insures the data for the current state is all on the backing store when the activity is completed. (And manually issuing two of them insures the first one is completed before the second command returns.)
- Unmount also tells the filesystem to get all files closed, go to such a state (including updating a flag saying it isn't mounted, if that is part of the filesystem) and write this all to the store.
Unixes and linux are usually configured to issue syncs periodically. So if you write new stuff to your filesystem, and your filesystem/driver combination isn't one that tries to always force the data to the store right away, you'll see the activitly light go out when there's still important stuff in a last few buffers which AREN'T written yet. (For a new file, on some filesystems, that will include the metadata about the file, which got finalized when it got closed and thus is the last thing changed.) Pull the store now and important stuff about these new files is incomplete or missing, even if they've been closed (so the last buffer of data is complete and queued to be written).
When this happens, if you wait around a short time, and the periodic sync will force it out to the store. But it might be so few blocks that you don't see the activity light blink. Pull the store after that and it will have the file data and metadata for the new, and closed, files. But the filesystem image will still be in a "mounted" state, so remounting it will require at least some filesystem scan (very short for journaling filesystems) and may generate a gripe from the OS.
Unmount (then sync;sync, though unmount seems to do that for you these days) and you guarantee that the backing store is clean and ready to go. Eject does that for you (or gripes if it can't because there are sill things in use by live apps) before it actually ejects the storage medium or tells you you can safely remove it.
Parent
Share
Just pulling it out is simply dumb
Score:
by
angel'o'sphere
( 80593 )
writes:
.ed.rotnemoo. .ta. .redienhcs.olegna.
on Sunday July 22, 2018 @10:51AM (
#56989844
Journal
First of all: an annoying dialog pops up and an annoying beep comes, you have to close the dialog, probably even with the mouse because ESC or ENTER does not work.
Secondly, you probably have forgotten that a file is open in Excel or whatever and it is half modified but not fully saved.
Why not eject it and be safe, respectively be not annoyed?
Share
Re:
Score:
by
houstonbofh
( 602064 )
writes:
Pulling it out: doesn't work for data safety, doesn't work for contraception either.
But which one is the average slashdot user going to be doing daily?
It's not only about recently written data
Score:
by
cyba
( 25058 )
writes:
More sophisticated SSDs perform static wear leveling (moving old data to different locations on the disk) in the background. To improve performance, firmware on some disks does this without ensuring atomicity of each operation. It means that in case of unexpected power loss you could end up with seriously broken filesystem. Cheap pendrives are probably not affected by this, but you should be careful when connecting e.g. external SSD via USB.
Trust the people designing an OS know a little...
Score:
by
The MAZZTer
( 911996 )
writes:
...more than you do. I say this every time someone claims to know better than the OS designer. For example, memory defragmenting applications, RAM boosters, memory cleaners... if they did good, it would be probably built into the OS already.
This is a similar case, but even easier to rationalize. The designers went out of their way to warn you and chastise you for yanking out a USB device. They spent time and effort adding these messages in. I would assume they are valid just from that alone.
Windows in parti
Re:
Score:
by
Junta
( 36770 )
writes:
Well, here it's a bit of an evolved situation, and one that evolved with the general state of storage.
Once upon a time, OSes didn't bother to cache writes, they just wrote to disk and were done. Computer could just turn off at any time (parking hard drives manually aside). Memory was too scarce.
Then memory was more plentiful and OSes became more sophisticated, disk IO then presumed caching, and shutting off your system without proper shutdown was exceedingly high risk. Removable media came into fashion w
Re:
Score:
by
houstonbofh
( 602064 )
writes:
...more than you do. I say this every time someone claims to know better than the OS designer.
As someone who has actually written software and contributed to many projects; No! Do not trust me! I still remember when a major release of my software hit slashdot, and one of the first comments was "Why can't I see any logs?" Yes, I made a stupid build error that hosed logs. I was able to push a new release the next day with that fix, but it took someone not trusting me to find it first.
Also, the Metro Interface proves that the designers are often drinking better stuff than we can afford.
My question is, why don't USB drives self-eject?
Score:
by
berchca
( 414155 )
writes:
Why don't USB drives self-eject? I mean, beyond memory size and speed, and the ability to buy one in the shape of sushi, USB drives haven't evolved since their introduction. It would seem like adding a button on the drive itself--one that calls to the system to let it eject--is waaaay overdue (considering the current, boorish way of doing it, which involves using your mouse or keyboard and way too much thought and effort).
Free idea right here. Sandisk? PNY? Hello?
Re:
Score:
by
Junta
( 36770 )
writes:
Because adding a button and indicator to show completion means cost and ruining the 'minimalist' design point they are going for. Further, they know consumers will likely ignore that anyway, and that OSes have given up write-caching for removable storage anyway.
Re:
Score:
by
loonycyborg
( 1262242 )
writes:
You mean making them work like CD-Rom drives? I guess they didn't want to make them work like that to make things simpler.
Re:
Score:
by
houstonbofh
( 602064 )
writes:
You mean making them work like CD-Rom drives?
You mean where the button ignores you and does not eject the disk. Or starts to and teases you and then closes again? Like that?
Am I on Fucking Buzzfeed?
Score:
, Insightful)
by
bill_mcgonigle
( 4333 )
writes:
on Sunday July 22, 2018 @11:05AM (
#56989938
Homepage
Journal
What are your thoughts on this? Do you think the answer varies across different file systems and operating systems?
You're kidding, right?
Share
Re:
Score:
by
hcs_$reboot
( 1536101 )
writes:
No, SuperUser and Slashdot merged.
You must unless you want to deal with lost data
Score:
, Interesting)
by
Artem S. Tashkinov
( 764309 )
writes:
on Sunday July 22, 2018 @11:06AM (
#56989950
Homepage
Safe eject/removal is the
only
way to guarantee that file buffers are flushed and metadata is in a consistent state.
If you're OK with losing files, or having chunks of your free space marked as occupied, then don't use safe eject.
Share
Re:
Score:
by
DaMattster
( 977781 )
writes:
This is true. Especially when write caching is nearly ubiquitous.
Might as well..
Score:
by
Junta
( 36770 )
writes:
on Sunday July 22, 2018 @11:06AM (
#56989952
Err on the side of caution. Etiher:
You don't need to because the system isn't caching writes, in which case the result is instant
The result is slow, which means you need to do the 'eject' procedure.
Practically speaking, modern OSes have gotten the point, a small usb attached storage device is at high risk to be yanked out, so they disable write caching by default.
Share
It used to work in XP
Score:
by
necronom426
( 755113 )
writes:
I always have write caching turned off. Windows has the Quick Removal option, so why would it be there and be called that if it wasn't there to allow you to pull it out?
I never ejected a flash drive in XP and never had a problem. In Win 7 I almost always do, as it doesn't seem to work properly, but at work we have a Win 10 laptop and 90% of the time it doesn't allow me to eject (warning message pops up), so I have to either reboot (yeah, right), or just pull it out and hope for the best.
Why don't flash dr
Would you Power Off before Shut down?
Score:
by
mykepredko
( 40154 )
writes:
Just thinking about this, it's really the same question - when you power down your PC/laptop/whatever, do you hold the power button down for five seconds to shut it down or do a "System Shutdown"?
It's really the same thing when you apply to USB thumb drives.
Re:
Score:
by
houstonbofh
( 602064 )
writes:
Just thinking about this, it's really the same question - when you power down your PC/laptop/whatever, do you hold the power button down for five seconds to shut it down or do a "System Shutdown"?
It happens every time Windows decides to update while on batteries...
:)
Eject is just below delete
Score:
by
wolfheart111
( 2496796 )
writes:
Windows is funny like that.
Eject programmers from HMI design
Score:
by
Impy the Impiuos Imp
( 442658 )
writes:
This is the result of OS programmers throwing wrappers around internal APIs instead of designing a product.
How about the OS make yankable the default state, with an indicator light on the task bar, window bars, etc. For that matter computer makers can put a tiny LED by the front panel USBs to signal this too, assuming you can even see it amidst glowing coolness everywhere.
Tbe user knows they are done copying, so can wait for the OS to signal so.
Now Apporoved by majopr educational institutions!
Score:
, Informative)
by
Hognoxious
( 631665 )
writes:
on Sunday July 22, 2018 @11:59AM (
#56990148
Homepage
Journal
I don't have a clue, but I'm sure
Wikipedia
[slashdot.org] does!
Share
What are my thoughts on this?
Score:
, Informative)
by
QuietLagoon
( 813062 )
writes:
on Sunday July 22, 2018 @12:04PM (
#56990172
Simple: wow, I am surprised how low the once great Popular Science has sunk.

Oh, you mean about the USB stuff... well...
...The magazine's take on it -- which is, as soon any ongoing transfer of files is complete, it is safe to yank out the flash drive
...
The problem is that you do not know
when
the transfer is complete. The UI's representation of it shows when the UI is done with the transfer, but that does not necessarily mean that the OS is finished with the transfer. So Popular Science is correct in that you have to wait until the transfer is complete, they are just incorrect about what tell-tale to use to determine that status.
Share
Re:What are my thoughts on this?
Score:
, Interesting)
by
TeknoHog
( 164938 )
writes:
on Sunday July 22, 2018 @12:39PM (
#56990332
Homepage
Journal
The problem is that you do not know
when
the transfer is complete.
I'm also baffled about this level of idiocy in a
/. article. I guess things that were obvious to us geeks 15-20 years ago are completely new to today's "digital natives".
That said, these things only became obvious to me when I moved to Linux back in the day. I learned about things such as mounting filesystems and a lot of other fundamental machinery that must be going on in Windows too, but it's hidden from the user. But there are these occasions when you absolutely need to unmount.
Back in the days of Windows 3.1, writing to floppies would halt everything else, and it would be clear when the transfer was complete. There was not much multitasking or write caching going on anyway, so it was OK. Today we take those for granted, but in turn it means we need to be explicit about ejecting devices.
The point about spinning hard drives is somewhat orthogonal, though. Simply unmounting the drive won't power it off. So you often need to yank the plug out while the drive is spinning. This can be hard to do safely with small drives and short cables.
Parent
Share
Re:
Score:
by
DamnOregonian
( 963763 )
writes:
No, you simply don't understand what it's reporting. And that's ok, you're a generally ignorant human.
You see, kiddo, the modern OS has many layers stacked upon each other.
Your application submits I/O to a syscall, the syscall hands it off to the VFS subsystem, which then hands it off (maybe) to the filesystem, who then hands it off to the I/O scheduler, who then hands it off to the device driver, who then hands it off to the device. Here's where it gets extra cool- your device may be ultra dumb (floppy,
I usually do
Score:
, Interesting)
by
jason777
( 557591 )
writes:
on Sunday July 22, 2018 @12:21PM (
#56990266
I always eject it, but sometimes it says its in use and won't let me. But I want to pull it out NOW, so too bad its getting yanked out.
I also use a program called Hotswap! that ejects alot better than the windows one, AND lets me do sata drives and things that normally don't show up in the windows eject.
Share
Re:
Score:
by
jbmartin6
( 1232050 )
writes:
This drives me nuts. Windows STILL has no mechanism to tell me which process is supposedly using the drive. So yes, it gets yanked. Windows claims the drive CAN'T be ejected. Go to hell Windows, I say it can.
It's there for a reason
Score:
by
quonset
( 4839537 )
writes:
Just like a parking brake on a car is there for a reason, the option to safely eject a USB drive is also there for a reason.
But don't let that stop all the experts on here and elsewhere from saying otherwise.
You need to be careful ...
Score:
by
CaptainDork
( 3678879 )
writes:
on Sunday July 22, 2018 @12:42PM (
#56990348
... so just eject the goddam thing.
Share
Software fix
Score:
, Interesting)
by
gurps_npc
( 621217 )
writes:
on Sunday July 22, 2018 @12:46PM (
#56990362
Homepage
The computer should simply have a symbol on the taskbar/similar area that says when it is safe to remove the drive or not.
Share
Re:Software fix
Score:
, Insightful)
by
RhettLivingston
( 544140 )
writes:
on Sunday July 22, 2018 @02:43PM (
#56990850
Journal
The problem is, it could change back to unsafe as you're pulling it. Computers operate at speeds way to fast for this. You'd have to do something like have a green light, yellow light, red light system where writes wait until a yellow light has been shown for a couple of seconds before they start. That would destroy performance.
Parent
Share
Re:
Score:
by
DamnOregonian
( 963763 )
writes:
Oh, I hope it does more than sync and umount, because that isn't enough to guarantee the disk is in a safe state to remove. It must also disconnect it.
The back-end storage chips on most USB sticks have rather complicated behavior to make those flash chips behave anything like a disk drive, and that behavior often requires the controller keep working in the background. Only a complete moron pulls the power from a USB stick before safely ejecting it. Sure, he may dodge the bullet most of the time, but you on
Comment removed
Score:
by
account_deleted
( 4530225 )
writes:
on Monday July 23, 2018 @02:26AM (
#56993030
Comment removed based on user account deletion
Read the rest of this comment...
Share
Luck
Score:
by
cwsumner
( 1303261 )
writes:
on Monday July 23, 2018 @12:02PM (
#56994794
You can get away with risks sometimes. But if you push your luck too often, your "luck" will get used up!
And there is no law that says it won't go bad the very first time, or the second, no matter how long the odds.
Murphy's Law rules the world... 8-}
Share
Why is this even a thing?
Score:
by
mark-t
( 151149 )
writes:
markt@nerdRABBITflat.com minus herbivore
on Monday July 23, 2018 @12:08PM (
#56994836
Journal
Yes, unmount the drive before taking it out.
If the usb driver doesn't cache writes, then unmounting the device before removal will not take any extra time, and has cost you nothing, while if it does cache writes, removing before unmounting could corrupt the data on the device.
Seriously, it takes like 2 seconds if it would have been safe to do the other way and will save you untold hours of grief later if it wasn't.
Share
Scraping the connections to delicate chips
Score:
by
raymorris
( 2726007 )
writes:
"Unlikely" might be a better word than "absurd". The physical cmos chips associated with ports are delicate. They don't like voltages that are too high, too low, or change to fast.
As you pull a connector out, the power and data pins scrape against each other, causing them to connect and disconnect a hundred times in a hundred milliseconds. Having power switching on and off randomly while the data lines are active transferring data can be bad.
It's probably not LIKELY to cause damage if you do it once, but th
Re:Ports can get damaged, somehow.
Score:
, Funny)
by
Hognoxious
( 631665 )
writes:
on Sunday July 22, 2018 @11:21AM (
#56990012
Homepage
Journal
The physical damage occurs when you go "Oh, fuck!" and try to ram it back in before the computer notices.
Parent
Share
Re:
Score:
by
Hognoxious
( 631665 )
writes:
I've had Nautilus on Linux do it sometimes.
There's an "eject anyway" button but on my version it doesn't work.
Re:
Score:
by
houstonbofh
( 602064 )
writes:
Time for the skinny elephants...
Re:
Score:
by
houstonbofh
( 602064 )
writes:
Me: *Tries to eject flash drive.*
Windows: "Cannot eject drive as files are still being used."
Me: *Closes Explorer window that was open to a folder on C and not any folder on the flash drive, and tries to eject again.*
Windows: "Drive can be safely removed."
Me: "WTF?"
Windows: "Windows is applying Updates. Do not turn off your computer."
Re:
Score:
by
houstonbofh
( 602064 )
writes:
Why is it doing background operation without notifying the user?
Because the data-mining is supposed to be a secret!
Re:My thought
Score:
, Informative)
by
Anne Thwacks
( 531696 )
writes:
on Sunday July 22, 2018 @12:09PM (
#56990212
You might be using a file system called FAT - which stands for "File Allocation Table" and is only partially connected with overweight files and the concept of bloatware.
The FAT is a table (bit map of sectors in use) which says which parts of the disk are in use, as well as where the files and their parts are stored. There are also flags saying if the file system (partition) is in use, and if it has been modified - and probably other things (I was last involved in this in about 1990).
When you eject, the system stops making the changes you requested (reads and writes), and updates these tables to a consistent state (well maybe not all that consistent, if its Windows, and completely inconsistent if DOS 4.0), and then clears the dirty (modified) and Open (in use) flags for each partition.
If the eject procedure fails to complete, and the dirty flag is set when you next try to use it, the OS will try to clean up the mess - it may succeed, or trash the data, and report success, or it may fail and tell you the system is dead.
With USB sticks, the data you see is not the real data. Because of the need to hide the bad blocks, and hideously long write time, the OS sees virtual data, and operates on virtual data. The real data is different. A single bit change (eg clear the dirty bit) could end up requiring three or four copy and write operations, operating on massive amounts of logically unrelated data, unknown to the OS. If you trash those, the OS for the CPU in the USB stick will be utterly bamboozled, and you have no interface to tell it to do a factory reset, so you USB stick is dead.
(Actually, the underlying interface to the USB stick is SCSI, and there probably is a SCSI command that would unbrick it, but you can be damned sure that the manufacturer won't tell you what it is, because if he did, you would not go out and buy another USB stick, would you?)
Parent
Share
Comment removed
Score:
, Insightful)
by
account_deleted
( 4530225 )
writes:
on Sunday July 22, 2018 @01:23PM (
#56990538
Comment removed based on user account deletion
Parent
Share
Comment removed
Score:
, Insightful)
by
account_deleted
( 4530225 )
writes:
on Sunday July 22, 2018 @01:28PM (
#56990550
Comment removed based on user account deletion
Parent
Share
Related Links
Top of the:
day
week
month
362
comments
Europe Has 'Maybe 6 Weeks of Jet Fuel Left'
329
comments
Apple MacBook Neo Beats Every Single x86 PC CPU For Single-Core Performance
279
comments
Is the Iran War Driving a Surge of Interest in Electric Cars?
278
comments
California Now Has 68% More EV Chargers Than Gas Nozzles, Continues Green Energy Push
275
comments
Much of the World's Solar Gear is Made Using Fossil Power in China
next
Some Colleges Cautiously Embrace Wikipedia
65
comments
previous
Bot Tweeted Names And Photos Of Venmo Users Who Bought Drugs
86
comments
Slashdot Top Deals
The universe seems neither benign nor hostile, merely indifferent.
-- Sagan
Close
Working...