ALWAYS close USB flash drive before removing?

[Arno]

The effort people will use to justify their risky
behaviour is astonishing. It does not make the behaviour
any less risky or the justification true.

Arno

... and by the same vein someone could argue it isn't safe
to use a push lawnmower if they aren't wearing steel toed
shoes, but last time I checked I still have both feet.[/QUOTE]

There is a difference between denying a risk exists and willingness
to accept a risk. I am talking about the former, obviously.

Arno

 

[Jerry Peters]

... only in principle not reality, if you never see any
problem...

Until you *do*, of course.

Jerry

 

[Arno]

... only in principle not reality, if you never see any
problem...

For the way people (foolishly) deal with risk, you are
certainly right. For more professional risk management
you also take into account one-time risks that you
cannot have experience with (e.g. death) and risks that
are rarely to be realized but then have large damage.

However I certaibnly do not mind your way to manege the
"USB unplyg risk", I will keep doing umounts and safe
removals. There may also be the additional aspect that
I am an IT professional and getting caugt doing something
potentially foolish may be detrimal to my reputation.

Arno

 

[Arno]

I should clarify, that I meant no writing of data that
wasn't already happening expediently without doing that, it
does also dismount the volume.

The dismount is pretty important. Otherwise an application
could start writing between the "you may now remove..."
message and the actual removal.

Arno

 

[Arno]

For the way people (foolishly) deal with risk, you are
certainly right.
For more professional risk management
you also take into account one-time risks that you
cannot have experience with (e.g. death) and risks that
are rarely to be realized but then have large damage.

Unplugging a USB flash drive without using Safely Remove has
nothing to do with "professional risk management". If you
are vaguely implying professional risk management as
requiring retention of data, it becomes a matter of
redundant storage of that data, not whether you swing a
chicken around your head, dance around a sombrero, and face
Mecca when removing your USB flash drive.

However I certaibnly do not mind your way to manege the
"USB unplyg risk", I will keep doing umounts and safe
removals. There may also be the additional aspect that
I am an IT professional and getting caugt doing something
potentially foolish may be detrimal to my reputation.

Arno

[/QUOTE]

What is dangerous to your professional image is repeating
myths that aren't based on fact and making vague false
implications about supersticions.

The fact is, even the developer of the OS plainly states
you don't need it. If you are using a system under someone
else's control such that you don't know the defaults are
left alone, that Optimize for Safe Removal is not left as
the default, then I would agree Safely Remove feature should
be used... then the setting should immediately be checked
because no USB flash drive which is to ever be removed and
contains important data should be used without optimize for
quick removal set.

Further, no USB Flash drive should be used until it is
tested and qualified as working properly. Further, no
system should be trusted with data integrity and use of a
USB flash drive until that too is tested and proven to work
properly. These things are required for any reasonable
level of "risk management" but Safely Remove simply isn't
once these factors are established.

Well, since you will very likely never hire me, I can safely
state that you still do not understand the issue. As everything
relevant has alredy been discussed, there is nothing more
I can say.

Arno

 

[Jerry Peters]

Which is like saying "I'll wear my tin-foil cap just in case
aliens come".

I do feel sympathy for those who live in such mindless
conditions... they:

A) Trust MS with their data in the first place.

B) Don't trust that when MS claims you can leave it set for
Optimize for quick removal, that they didn't really mean itj
even though they clearly state you don't need Safely Remove
using the defaults.

C) Then trust MS again when it comes to using "Safely
Remove", as if their prior statement wasn't enough, ONLY NOW
will you begin to believe.

HELLO? HAVE YOU ALL GONE MAD?

Please, please, just stop pretending you know something
until you use a thing called science. Do the trails, if
you find a fault, trace it. Assign proper blame and accept
when there is none and the same is duplicated across all
controlled environments, it is considered "fact".

1) I don't trust windows *at all*. I use Linux almost entirely. With
Linux, one performs a umount before removing a block device.

2) When I do use Windows, I don't trust it to do anything properly.
So far I've rarely been disappointed.

3) Making unwarnted assumptions often *seems* safe, until reality
bites you in the ass, usually *hard*.

4) Taking a little extra time to safely eject a USB stick isn't going
to kill me.

5) It's called being careful; I've found it usually pays.

6) Windows causes me enough grief, I have no need to *ask* for more.

Jerry

 

[GT]

Never ever could bullshit and lie its way outof a wet paper bag.

You missed a space.

 

[John Turco]

David Brown wrote:


Then you need to get out more. Most of us get the exact
opposite effect, very few flash sticks that dont have one.

<edited>

Some months ago, I bought a handful of clearance-priced USB
"key drives," locally: Two 2-packs of PNY 2GB "mini Attaché"
cuties ($5 USD apiece), and the following week, I obtained
an 8GB mini Attaché ($9.99).

Later, upon using one of the 2GB specimens, I was pretty
disappointed to discover that none of these PNY products
contain LED's. (That's probably why they're quite a bit
smaller than my older SanDisk 256MB "Cruzer Mini" models,
I assume.)

On the plus side, though, the PNY devices all feature
hinged caps -- which prevent those latter items from
becoming either lost or misplaced.

 

[Rod Speed]

John Turco wrote

Rod Speed wrote

<heavily edited for brevity>

There you go again...

<edited>

And again.

Some months ago, I bought a handful of clearance-priced USB
"key drives," locally: Two 2-packs of PNY 2GB "mini Attaché"
cuties ($5 USD apiece), and the following week, I obtained
an 8GB mini Attaché ($9.99).

Later, upon using one of the 2GB specimens, I was pretty disappointed
to discover that none of these PNY products contain LED's.

The technical term for that is 'pathetically inadequate sample'

(That's probably why they're quite a bit smaller than my
older SanDisk 256MB "Cruzer Mini" models, I assume.)

LEDs can be microscopic.

 

[Arno]

On 11/22/2009 1:30 PM PT, Arno typed:

Question: How does one unmount/dismount in Windows 98 SE since it
doesn't have those USB safety removal option in its system tray?

I am not sure you can. Maybe disable the drive in the device
manager?

 

[david]

Question: How does one unmount/dismount in Windows 98 SE since it
doesn't have those USB safety removal option in its system tray?

Upgrade to something that isn't 12 years old, maybe?

 

[Arno]

On 11/23/2009 5:50 PM PT, david typed:

It's not me. It's the clients. :/

My condolences. Maybe there is an "umount utility" for
Win 98 that addresses the problem?

Arno

 

[Arno]

The dismount is pretty important. Otherwise an application
could start writing between the "you may now remove..."
message and the actual removal.

Arno

[/QUOTE]

I agree that if you don't know if any app has the file open
and could potentially write it could be a problem, but in
that case my advice is to be sure you have closed the app if
it is a question, and if the app is buggy enough it doesn't
unlock a file after closing it, app should be patched or
replaced.

Since any important file should not exist only on a flash
drive, there should be no moment when something important to
be written to a drive is data held only in application
memory space. Therefore, if you remove the drive when a
file is open it is nothing lost, when it comes time to write
you see the volume is not there and simply plug it back in.
If it is a matter of not knowing something was going to be
written, so long as it is not writing at the time the drive
is unplugged (referring back to looking at the access
indicator LED), you can do without that write. Apps should
not write to a volume you have not explicitly told it to and
such apps should be abandoned.

Well, in a perfect world apps would also make sure that everything
they write to disk is consistent immediately after the write and
then close the file and reopen it for further writes. They
should also open files only for reading, unless they really need
to wrote. Unfortunately the worls is not perfect and some
people cannot abandon misbehaving apps.

The advice to always securely remove is in respect of that
reality. Yanking out can be made very safe, indicentially,
from a filesystem PoV by using journalling as for example
Linux ext3 does. This still leaves the app problem. In
addition, under Windows, even the filesystem level safety
is not present.

Arno

 

[Jerry Peters]

Well, in a perfect world apps would also make sure that everything
they write to disk is consistent immediately after the write and
then close the file and reopen it for further writes. They
should also open files only for reading, unless they really need
to wrote. Unfortunately the worls is not perfect and some
people cannot abandon misbehaving apps.

The advice to always securely remove is in respect of that
reality. Yanking out can be made very safe, indicentially,
from a filesystem PoV by using journalling as for example
Linux ext3 does. This still leaves the app problem. In
addition, under Windows, even the filesystem level safety
is not present.

Arno

I'd worry about what happens with a poorly coded FTL in the drive if
power happens to be removed while a write is in progress. Could lead
to corrution or even complete failure of the drive.

There was a very extensive series of emails about this on the Linux
kernel mailing list a few weeks ago, prompted by tests performed by
one of the developers. The summary was that even a jfs won't save you
if the FTL gets damaged.

Jerry

 

[Arno]

I'd worry about what happens with a poorly coded FTL in the drive if
power happens to be removed while a write is in progress. Could lead
to corrution or even complete failure of the drive.

Hmm. Good point. _Hardware_ that has issues with being
removed while writing is done is an entirely more serious
problem.

There was a very extensive series of emails about this on the Linux
kernel mailing list a few weeks ago, prompted by tests performed by
one of the developers. The summary was that even a jfs won't save you
if the FTL gets damaged.

Can you give me a link to the initial posting? I did not
find it on a quick search.

Arno

 

[Jerry Peters]

Hmm. Good point. _Hardware_ that has issues with being
removed while writing is done is an entirely more serious
problem.


Can you give me a link to the initial posting? I did not
find it on a quick search.

Arno

The original poster was Pavel Machek with a title like "ext3 unsafe on
flash device". IIRC LWN also had an article on the thread.

Pavel claims to have destroyed several devices by removing them with
writes in progress, in addition to corrupting filesystems.

The FS problem is that the underlying blocksize of the flash medium is
larger than the FS block size so that additional data can become corrupted
which the FS does not anticipate.

Jerry

 

[Arno]

The original poster was Pavel Machek with a title like "ext3 unsafe on
flash device". IIRC LWN also had an article on the thread.

Found it, thanks. The first relevant message of the thread
seems to be this one here:

http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/01044.html

Pavel claims to have destroyed several devices by removing them with
writes in progress, in addition to corrupting filesystems.

I did not find the part about broken hardware as a result of
removal, but the serious corruption scenario were you get corruption
in data that was not even written (due to large sector saize up to a
MB on some Flash) is entirely plausible.

The FS problem is that the underlying blocksize of the flash medium
is larger than the FS block size so that additional data can become
corrupted which the FS does not anticipate.

Indeed. And this scenario makes the safe removal even
more important for Flash.

Seems my suspicions of Flash being unreliable in general
are more true than I thought.

Arnp

 

[Jerry Peters]

Found it, thanks. The first relevant message of the thread
seems to be this one here:

http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/01044.html


I did not find the part about broken hardware as a result of
removal, but the serious corruption scenario were you get corruption
in data that was not even written (due to large sector saize up to a
MB on some Flash) is entirely plausible.


Indeed. And this scenario makes the safe removal even
more important for Flash.

Seems my suspicions of Flash being unreliable in general
are more true than I thought.

Arnp

Might have been another poster that mentioned destroying a flash
drive.
I think Ted Tso gave a short exposition on the FTL and problems if
the ordering of operations is not correct.

The whole thread made interesting reading. My recomendation is to
always use the OS provided mechanism to safely remove flash drives.
It's sort of like wearing seatbelts while driving, 99.99% of the time
they're superfulous, it's the other .01% that gets you.

Jerry