after copying files to/from the p.c and the disk-on-key, is it safe to just yank the black thing out of the USB port?
or should I click on that little icon at the bottom of the screen (next to the clock in the task bar), then click on “safely remove hardware” and wait a second before yanking it out of the port?
(okay, so I’m not the most sophisticated guy…maybe my next post will be a question about when a bull enters a china shop…)
I’ve read that unless you have an unsaved document open, chances are you can just pull it.
I don’t understand what’s so hard about doing it the way it was obviously intended to be done.
You can just yank it out and everything will be fine . . . most of the time. The problem is that sometimes everything won’t be fine and you might lose some data. It happens.
RR
In your System Tray there should be a ‘Safely Remove Hardware’ icon. Open it, select your drive and close it down / eject / disconnect it (as available).
If you’re copying from the thumb drive, yanking it shouldn’t be a problem.
If you’re copying to the thumb drive, it’s best to “safely remove” it, to give the filesystem a chance to sync.
Or, I could have read the OP. :smack:
No, you should follow procedures. Windows caches things and that way lies trouble if you don’t follow procedure.
I knew a computer guy who always just yanked it, and had no problems.
Me, I follow procedure. No point courting disaster.
I believe this is much more of a problem with Linux machines. Windows writes/closes to the USB disk much closer to modification time, whereas Linux is more apt to hold things in the cache.
But then again, I am only just learning Linux, so may be learning wrong.
There’s a setting accessible by CP->Device Manager->{device}->Properties->Policies that has the option to set a drive to “optimize for quick removal” as opposed to “optimize for performance” (which uses caching). Setting it for quick removal might be a good idea if you don’t want to worry about the correct procedure.
[ul]
[li]As long as you were reading only, go ahead and yank it.[/li][li]If any writing happened ever, close it nicely.[/li][li]Just in case anyone doesn’t know already, you don’t have to double-click the icon and sift through the baffing list of devices to close it. Single click and it will show you a polite little list of normal looking stuff (e.g. “Removable Drive on E:”).[/li][li]SD cards and their ilk are a different brew: AFAIK as long as the underlying USB device is not monkeyed with you can just yank the SD card from the slot. I asked this once here and that was the consensus.[/li][li]If the data is really important, close it nicely.[/li][/ul]
>I am only just learning Linux, so may be learning wrong.
I haven’t tried Linux, but I understand it is UNIX, and I administered BSD and SVR4 UNIX systems years ago. They have a sync command, which black rabbit mentioned above. It flushes buffers to the drives - I don’t know what else it does.
In my limited programming of Windows (a little WIN32API and a little .NET) I’ve never noticed any guarantees about when buffers will necessarily be written to a file, other than when you shut the system down, or tell it to do this by using the little icon in the system tray. So, I would expect if you had only read from the thumb drive it would be OK to just yank. Though, even then, I’m not sure Windows wouldn’t find a reason to mess with the non-file components, file allocation tables or whatever they have now.
I also don’t know how long it takes Windows to actually write things into the hive files for the Registry. Perhaps you could open something on the thumb drive to read it, and have to select what program should open that file type, and pulling the thumb drive early might mess up recording that info to the Registry (gotta say I’m not sure that is where such bindings live).
One big reason not to follow procedure is that PCs can sometimes take 20 or even 30 seconds to give you the dialog box after you click the icon. If your pants are on fire, or for any of a number of other reasons, you can’t wait - well, then it is often harmless.