I'm using XP. In XP's Device Manager there is an entry for Disk
Drives and when I look at the Policies tab for the flash drive, it
says:
"Optimized For Quick Removal. This setting enables
write caching on the disk and in Windows, so you can
disconnect this device without using the Safe Removal
icon."
My friends get upset if I don't use the Safe Removal process when
their USB memory is in my PC. Maybe they're repeating a mistake? Or
is there a reason which I'm missing that says I should always use
Safe Removal?
The main problem with removing USB drives without "safe removal" (or
umount on Linux) is that the OS could still have data in its write
buffers. If you remove the flash drive before the write is complete,
you will lose data, corrupting the file that is being written, and
possibly corrupting the FAT (and therefore lots more of the flash disk).
The "optimize for quick removal" makes windows save as little in the
write buffers as possible, minimising your risks, but you are still
risking data loss and file corruption. The other choice is to store
lots more in the write buffers - that makes the flash disk far faster
for writing, especially for writing lots of small files, but means
greater risk of corruption if you don't remove it safely.
So you should /always/ use safe removal, unless you haven't written
anything to the disk.
Windows doesn't always write immediately to a USB stick, but quickly caches
things and writes to the USB drive at its own speed (like a print queue) so
if you drag files across, then immediately remove the stick you might find
things missing or corrupted. If the stick has an LED, then you can tell when
its ready/finished.
That is dangerous. It may delee or interrupt writes for a short
time due to other things. The only safe opton is to use safe
removal and o wait until windows says that the stick can be removed.
That said, if you have mostlysmall writes, just janking the stick
out oftnen works, but can also result in mor or less subtle data
corruption, up to an including loss of all data on the stick.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: ar...@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> I'm using XP. In XP's Device Manager there is an entry for Disk
> Drives and when I look at the Policies tab for the flash drive, it
> says:
> "Optimized For Quick Removal. This setting enables
> write caching on the disk and in Windows, so you can
> disconnect this device without using the Safe Removal
> icon."
That is basically a lie by omission. You still need to
wait until all writes are complete. The difference is that
windows will try hard to write immediately, but a) writes
can take time and larger ones can take a lot of time
and b) some other things can still prevent windows to
write immediately. Often this works, but you may still
loose all data on the stick or get corruption if you trust
this statement.
> My friends get upset if I don't use the Safe Removal process when
> their USB memory is in my PC. Maybe they're repeating a mistake? Or
> is there a reason which I'm missing that says I should always use
> Safe Removal?
Your friends are right. There are some advanced journalling
filesystems that can reliably minimize corruption if you remove
an USB stick during a write, but Wndows is not using them
and neither FAT nor NTFS is safe to remove during a write.
Obviously a file tat is bing written during remmoval will
always have some corruption as result, there is no way around
that.
Just remove it after done. Mine burnt out when I left it in -- end
LED light always flashed whether being written to not while it was
working.
Suppose I wait a few minutes after I moved a file to the flash
drive. Will the write cache be written out to the flash drive in
that period? Working like that is preferable because XP's Safe
Removal utility can be fiddly to launch.
I mean to ask, is it simply a matter of leaving ENOUGH TIME for the
write cache to be emptied by XP?
Or does the emptying of the write cache depend on OTHER FACTORS than
elapsed time?
>Do I always need to close or stop a USB flash drive before I remove
>it?
I've been removing the drive immediately (all drives: USB, SD,
external HDD, ect) for years now and I've never had a problem. Course
I ways wait to remove it until a few moments after the lights stop
flashing. I'm sure you will hear from those who have had problems
though. It may depend on which app you are using to do the transfer.
Perhaps as in life it boils down to just how much of a hassle you are
willing put up with to be completely safe... ;)
It is, but there is no reliable way to tell how much time is enough.
> Or does the emptying of the write cache depend on OTHER FACTORS than
> elapsed time?
The time the emptying takes can depend on other usage of the
filesystem, for example. Say you have a large weite request
that has aged in the background and reached the "must flush"
timeout, than that will be written before the USB stick is.
There are other conditions that can delay writing.
The problem is that there is no way to tell from the outside
and you will get corruption if you remove in the wrong Moment.
That said, it typically (low I/O load, no large writes, no
high CPU/hogh memory load tasks) works.
All safe removal really does is wait to tell you it can be
removed if the buffer is not written out yet.
As for the optimized for quick removal setting, in use the
main difference is that this keeps the "copying..." visual
indicator window on screen until the copying is done, while
if you chose the other option the copying indicator window
will finish suggesting the copying is finished while all
that is necessarily done is all the data to be copied is now
in the windows buffer.
While writes can be delayed it is not by much, it would take
a fairly heavy use of the system to really delay by more
than the physical write speed and USB bus limitations cause.
IF your drive access LED works properly and you are familiar
with it, you can judge when writing is done by simply
observing several seconds of no activity, but certainly the
safest is to use the safely remove hardware feature.
The best thing to do is just respect your friend's wishes
and use it, regardless of whether it really matters... you
can't spend your life arguing with or educating people about
every little thing... and some of them will get offended.
Thats just plain wrong. If you have it optimized for quick removal and its
been a while since the write, its fine to unplug it without safe removal.
> Or does the emptying of the write cache depend on OTHER FACTORS than
> elapsed time?
Suppose the antivirus program is downloading a large update, that
you are not yet aware of. The writes to the flash drive may, or
may not be completed quickly. The only way to be sure, is to use
the remove safely option.
The only time it's guaranteed to be safe without that, is if you
haven't written anything to the drive. Your friend is correct
that you should always use the safely remove. Even if 99% of the
time it works ok without it, it's his drive that could effectively
be erased due to fat corruption.
Also, using the "Optimized For Quick Removal" option increases the
number of small writes to the drive, which will speed up the wearing
out of the drive. Flash drives have a limited number of writes.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
That is true, but how long is "a while"? It is highly dependent on the
size of the write(s), the type of flash disk, and the speed of the
transfer. Some flash disks have an LED or an indicator of some sort
that can help, but most don't.
Given the O/P's question, I think it's safer to recommend always using
safe removal, even if it is a little more paranoid than "use safe
removal or wait a while".
What do you mean, "fiddly to launch"? Unless you have done something
unusual to your XP setup, there's a little icon in the notification area
of the taskbar with a green arrow on it. Left click it, and choose the
usb drive you want to "safely remove". If windows keeps "helpfully"
hiding it, you can change the taskbar properties to turn off hiding of
unused icons.
> I mean to ask, is it simply a matter of leaving ENOUGH TIME for the
> write cache to be emptied by XP?
>
> Or does the emptying of the write cache depend on OTHER FACTORS than
> elapsed time?
It is basically a matter of time. The problem is that there is no
reliable way to tell how long you have to wait. Often it is only a very
short time, but it could be longer.
It is also possible that applications that have files open on the disk
will not take kindly to a sudden removal. That would only apply to
programs that are using it (and things like music players or photo
gallery applications might well try to use the flash disk without your
realising it), and I've no idea how it might affect them. But it is
safer to be "polite" and "safely remove" your disk.
Irrelevant to your stupid /always/ claim.
> It is highly dependent on the size of the write(s), the type of flash disk, and the speed of the transfer.
Not in the real world.
> Some flash disks have an LED or an indicator of some sort that can help, but most don't.
Another pig ignorant lie.
> Given the O/P's question, I think it's safer to recommend always using safe removal,
More fool you.
> even if it is a little more paranoid than "use safe removal or wait a while".
A hell of a lot more mindlessly paranoid, actually.
Not much longer.
> It is also possible that applications that have files open on the disk
> will not take kindly to a sudden removal. That would only apply to
> programs that are using it (and things like music players or photo
> gallery applications might well try to use the flash disk without your
> realising it), and I've no idea how it might affect them.
No problem at all in fact.
> But it is safer to be "polite" and "safely remove" your disk.
So you always wear a belt and braces so you dont end up exposing yourself ?
>>> So you should /always/ use safe removal, unless you haven't written
>>> anything to the disk.
>>
>> Thats just plain wrong. If you have it optimized for quick removal
>> and its been a while since the write, its fine to unplug it without
>> safe removal.
>>
>
>That is true, but how long is "a while"?
Several seconds with no I/O indicated.
>It is highly dependent on the
>size of the write(s), the type of flash disk, and the speed of the
>transfer.
None of these are a factor as you aren't timing it then
guessing when it's done. The two indictors when caching is
disabled are that the copy or move dialog window has
finished and the LED has remained indicative of no further
I/O.
> Some flash disks have an LED or an indicator of some sort
>that can help, but most don't.
Most do have an LED and the only one I'd ever buy that
didn't, only lacks one because it sacrifices everything to
be very tiny. So yes there is a complication without an
LED, but if someone wants the ability to visually see when
I/O has stopped, the LED is a desirable feature to seek at
time of product selection.
>
>Given the O/P's question, I think it's safer to recommend always using
>safe removal, even if it is a little more paranoid than "use safe
>removal or wait a while".
Safer yes, but since data with any value should never be
kept on only one storage medium, the risk isn't much to be
concerned about.
>Suppose I wait a few minutes after I moved a file to the flash
>drive. Will the write cache be written out to the flash drive in
>that period?
If you don't want to use the safely remove feature, don't
enable that cache so the copy or move dialog indicates the
state of the file transfers.
>Working like that is preferable because XP's Safe
>Removal utility can be fiddly to launch.
>
>I mean to ask, is it simply a matter of leaving ENOUGH TIME for the
>write cache to be emptied by XP?
Yes, but since we dont' all want to conduct experiments to
find out each individual system and flash drive performance
on myriad combinations of file size and total transfer size,
then calculate the expected period necessary for each set of
file transfers, it is generally preferred to look at the OS
file move or copy indicator window and the LED on the drive,
waiting for several seconds of inactivity before presuming
the transfer is complete.
>
>Or does the emptying of the write cache depend on OTHER FACTORS than
>elapsed time?
No, time versus bus rate and flash drive I/O speed. The
cache won't just sit there with a timer or anything it will
continue to read or write until finished.
> On Tue, 17 Nov 2009 10:26:38 GMT, Eddie <du...@invalid.com>
> wrote:
>
>>Do I always need to close or stop a USB flash drive before I
>>remove it?
>>
>>I'm using XP. In XP's Device Manager there is an entry for Disk
>>Drives and when I look at the Policies tab for the flash drive,
>>it says:
>>
>> "Optimized For Quick Removal. This setting enables
>> write caching on the disk and in Windows, so you can
>> disconnect this device without using the Safe Removal
>> icon."
>>
>>My friends get upset if I don't use the Safe Removal process
>>when their USB memory is in my PC. Maybe they're repeating a
>>mistake? Or is there a reason which I'm missing that says I
>>should always use Safe Removal?
>
> All safe removal really does is wait to tell you it can be
> removed if the buffer is not written out yet.
>
You say "All safe removal really does is wait to tell you it can
be removed if the buffer is not written out yet."
I thought the Safe Removal window actually *forced* the data to
be flushed out of the write cache?
Are you saying it is just a way of making the user wait until
flushing is done (but not start flushing any sooner)?
> As for the optimized for quick removal setting, in use the
> main difference is that this keeps the "copying..." visual
> indicator window on screen until the copying is done, while
> if you chose the other option the copying indicator window
> will finish suggesting the copying is finished while all
> that is necessarily done is all the data to be copied is now
> in the windows buffer.
>
> While writes can be delayed it is not by much, it would take
> a fairly heavy use of the system to really delay by more
> than the physical write speed and USB bus limitations cause.
>
> IF your drive access LED works properly and you are familiar
> with it, you can judge when writing is done by simply
> observing several seconds of no activity, but certainly the
> safest is to use the safely remove hardware feature.
>
> The best thing to do is just respect your friend's wishes
> and use it, regardless of whether it really matters... you
> can't spend your life arguing with or educating people about
> every little thing... and some of them will get offended.
>
Many times Safe Removal window says something like operatiom
failed to stop the drive or adaptor. Repeated tries don't seem to
improve this.
>On Tue, 17 Nov 2009 11:15:19 -0500, Eddie <du...@invalid.com> wrote:
>
>> Or does the emptying of the write cache depend on OTHER FACTORS than
>> elapsed time?
>
>Suppose the antivirus program is downloading a large update, that
>you are not yet aware of. The writes to the flash drive may, or
>may not be completed quickly. The only way to be sure, is to use
>the remove safely option.
BUT, are you really, REALLY sure? Or are you only placing
confidence in windows doing what it is supposed to do? It's
that a bit of the same thing as assuming the drive LED
access indicator is doing what it is supposed to do?
Some days I'd trust an LED hard wired to a chip not running
windows, more than windows itself. ;)
>The only time it's guaranteed to be safe without that, is if you
>haven't written anything to the drive. Your friend is correct
>that you should always use the safely remove. Even if 99% of the
>time it works ok without it, it's his drive that could effectively
>be erased due to fat corruption.
For the sake of argument, let's assume that 99% is a
fictional number and count the ways that a pending write
could be cached still but the user unaware of this.
1) User is unfamiliar with the specific flash drive,
doesn't know what the blinking LED means.
2) Owner didn't pick a drive that has an LED to indicate
I/O or didn't wait a few seconds to be sure there was no
activity.
3) Owner never looked at the LED to confirm it works
properly, there's always that one drive in the whole case
that might be defective.
>
>Also, using the "Optimized For Quick Removal" option increases the
>number of small writes to the drive, which will speed up the wearing
>out of the drive. Flash drives have a limited number of writes.
>
>Regards, Dave Hodgins
It's not worth considering. You won't wear out a USB flash
drive making backups or moving files around until long after
it's viable lifespan is over. Not even close.
>Also, using the "Optimized For Quick Removal" option increases the
>number of small writes to the drive, which will speed up the wearing
>out of the drive. Flash drives have a limited number of writes.
>
>Regards, Dave Hodgins
Also, optimized for quick removal doesn't necessarily
increase the number of small writes, a block written at a
time is far smaller than the always present read caching
windows does regardless of the write caching. It's not the
source of the data nor the main memory that is the
bottleneck, it's the USB bus and flash drive's own write
performance, the next write is always waiting whether you
have optimized for quick removal set or not.
What the setting really does is virtualize a completion of
the process so the system can go on to do more work with the
filesystem as if it were finished.
That's true enough. The copy/move box is a fairly good indicator, if
all the caching is disabled - the final flushing to disk should be
finished within a couple of seconds of the box closing.
I'm not suggesting it is not generally safe to remove the disk a few
seconds after you expect the copy to be finished - in the great majority
of cases, it /is/ safe. I'm simply saying that there are circumstances
that could make it unsafe. Perhaps /you/ have write caching disabled
and "optimise for quick removal", but not everyone does - it is not
uncommon to use a flash disk to files from someone else's machine.
Using "safe removal" is a good habit, works everywhere, costs nothing,
and avoids accidents on the rare occasions when there might be extra
delays. This is advice to the OP (and others) who would like a nice
general rule. Those who know what they are doing will obviously use
"safe removal" as and when they see fit.
>> Some flash disks have an LED or an indicator of some sort
>> that can help, but most don't.
>
> Most do have an LED and the only one I'd ever buy that
> didn't, only lacks one because it sacrifices everything to
> be very tiny. So yes there is a complication without an
> LED, but if someone wants the ability to visually see when
> I/O has stopped, the LED is a desirable feature to seek at
> time of product selection.
>
I agree that an LED is nice, but in practice I have seen very few flash
sticks with one. Cost is the main reason few sticks have an LED, rather
than size, but either way they are rare in my experience. You certainly
can't rely on having one on your "average" stick.
>
>> Given the O/P's question, I think it's safer to recommend always using
>> safe removal, even if it is a little more paranoid than "use safe
>> removal or wait a while".
>
> Safer yes, but since data with any value should never be
> kept on only one storage medium, the risk isn't much to be
> concerned about.
While you and I know that, there are lots of users who never seem to
understand about backups and extra copies of data. It is certainly not
uncommon for "average" users to copy files to a flash stick as their
only backup. Thus the good rule of thumb for "average" users is the
extra safe one of always using "safe removal".
>>On Tue, 17 Nov 2009 11:15:19 -0500, Eddie <du...@invalid.com> wrote:
>>
>>> Or does the emptying of the write cache depend on OTHER FACTORS than
>>> elapsed time?
>>
>>Suppose the antivirus program is downloading a large update, that
>>you are not yet aware of. The writes to the flash drive may, or
>>may not be completed quickly. The only way to be sure, is to use
>>the remove safely option.
> BUT, are you really, REALLY sure? Or are you only placing
> confidence in windows doing what it is supposed to do? It's
> that a bit of the same thing as assuming the drive LED
> access indicator is doing what it is supposed to do?
Windows will tell you that it is safe to remove the drive only
after it has a) written all buffered data and b) blocked the
device so no new writes can happen. In the absence of a programming
error, this is reliable.
> Some days I'd trust an LED hard wired to a chip not running
> windows, more than windows itself. ;)
>>The only time it's guaranteed to be safe without that, is if you
>>haven't written anything to the drive. Your friend is correct
>>that you should always use the safely remove. Even if 99% of the
>>time it works ok without it, it's his drive that could effectively
>>be erased due to fat corruption.
> For the sake of argument, let's assume that 99% is a
> fictional number and count the ways that a pending write
> could be cached still but the user unaware of this.
> 1) User is unfamiliar with the specific flash drive,
> doesn't know what the blinking LED means.
> 2) Owner didn't pick a drive that has an LED to indicate
> I/O or didn't wait a few seconds to be sure there was no
> activity.
> 3) Owner never looked at the LED to confirm it works
> properly, there's always that one drive in the whole case
> that might be defective.
Well, a defective flash drive may lead to corrutpion anywaus.
And this is a real problem: I have had two defective ones, one
in a long therm overwrite experiment and one as a recovery
boot medium and both have had silent corruption of data, i.e.
no error message at all. This measn their reliability is
significantly below that of a floppy disk.
I currently have a second drive in the torture chair and
will do a writeuo if that gets silent corruption as well.
>>
>>Also, using the "Optimized For Quick Removal" option increases the
>>number of small writes to the drive, which will speed up the wearing
>>out of the drive. Flash drives have a limited number of writes.
>>
>>Regards, Dave Hodgins
> It's not worth considering. You won't wear out a USB flash
> drive making backups or moving files around until long after
> it's viable lifespan is over. Not even close.
In ordinary use no. I have tortured one Kingston 2GB drive
to death, which took about 3400 complete overwrites or
in the order of a month of continued writing. The problem
was that it then gave wrong data but no error messages. Seems
there is no CRC in these devices or it is switched off.
Follow standard procedure. :)
--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.31.6
^ ^ 20:41:01 up 5 days 9:46 1 user load average: 1.00 1.02 1.00
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
So how long is "a while"? If you can't quantify it you're just talking crap.
>>> Do I always need to close or stop a USB flash drive before I remove it?
>
>>> I'm using XP. In XP's Device Manager there is an entry for Disk
>>> Drives and when I look at the Policies tab for the flash drive, it says:
>
>>> "Optimized For Quick Removal. This setting enables
>>> write caching on the disk and in Windows, so you can
>>> disconnect this device without using the Safe Removal
>>> icon."
>>> My friends get upset if I don't use the Safe Removal process
>>> when their USB memory is in my PC. Maybe they're repeating a
>>> mistake? Or is there a reason which I'm missing that says I
>>> should always use Safe Removal?
>> All safe removal really does is wait to tell you it
>> can be removed if the buffer is not written out yet.
> You say "All safe removal really does is wait to tell you
> it can be removed if the buffer is not written out yet."
> I thought the Safe Removal window actually *forced*
> the data to be flushed out of the write cache?
It does both.
> Are you saying it is just a way of making the user wait
> until flushing is done (but not start flushing any sooner)?
If that is what he is saying, he is wrong.
>> As for the optimized for quick removal setting, in use the
>> main difference is that this keeps the "copying..." visual
>> indicator window on screen until the copying is done, while
>> if you chose the other option the copying indicator window
>> will finish suggesting the copying is finished while all
>> that is necessarily done is all the data to be copied is now
>> in the windows buffer.
>> While writes can be delayed it is not by much, it would take
>> a fairly heavy use of the system to really delay by more
>> than the physical write speed and USB bus limitations cause.
>> IF your drive access LED works properly and you are familiar
>> with it, you can judge when writing is done by simply
>> observing several seconds of no activity, but certainly the
>> safest is to use the safely remove hardware feature.
>> The best thing to do is just respect your friend's wishes
>> and use it, regardless of whether it really matters... you
>> can't spend your life arguing with or educating people about
>> every little thing... and some of them will get offended.
> Many times Safe Removal window says something like operatiom
> failed to stop the drive or adaptor. Repeated tries don't seem to
> improve this.
On one system I do occasionally get it saying that it cant currently be removed and another go allows it to be removed.
It never keeps saying that it cant be removed.
And I use that system every couple of days.
Then you need to get out more. Most of us get the exact
opposite effect, very few flash sticks that dont have one.
> Cost is the main reason few sticks have an LED, rather than size, but either way they are rare in my experience.
Then you need to get out more. Most of us get the exact
opposite effect, very few flash sticks that dont have one.
> You certainly can't rely on having one on your "average" stick.
You dont need to 'rely' on anything, just do it differently if there is no led.
>>> Given the O/P's question, I think it's safer to recommend always
>>> using safe removal, even if it is a little more paranoid than "use
>>> safe removal or wait a while".
>>
>> Safer yes, but since data with any value should never be
>> kept on only one storage medium, the risk isn't much to be
>> concerned about.
> While you and I know that, there are lots of users who never seem to
> understand about backups and extra copies of data. It is certainly
> not uncommon for "average" users to copy files to a flash stick as
> their only backup. Thus the good rule of thumb for "average" users
> is the extra safe one of always using "safe removal".
Nothing like your original stupidity.
Few seconds of no led activity and the Win transfer window gone.
<reams of your puerile shit any 2 year old could leave for dead flushed where it belongs>
>In comp.sys.ibm.pc.hardware.storage kony <sp...@spam.com> wrote:
>> On Tue, 17 Nov 2009 13:30:10 -0500, "David W. Hodgins"
>> <dwho...@nomail.afraid.org> wrote:
>
>>>On Tue, 17 Nov 2009 11:15:19 -0500, Eddie <du...@invalid.com> wrote:
>>>
>>>> Or does the emptying of the write cache depend on OTHER FACTORS than
>>>> elapsed time?
>>>
>>>Suppose the antivirus program is downloading a large update, that
>>>you are not yet aware of. The writes to the flash drive may, or
>>>may not be completed quickly. The only way to be sure, is to use
>>>the remove safely option.
>
>> BUT, are you really, REALLY sure? Or are you only placing
>> confidence in windows doing what it is supposed to do? It's
>> that a bit of the same thing as assuming the drive LED
>> access indicator is doing what it is supposed to do?
>
>Windows will tell you that it is safe to remove the drive only
>after it has a) written all buffered data and b) blocked the
>device so no new writes can happen. In the absence of a programming
>error, this is reliable.
^ That last sentence is the key... of course windows has
never had programming errors and never will, they're design
/features/.
>In ordinary use no. I have tortured one Kingston 2GB drive
>to death, which took about 3400 complete overwrites or
>in the order of a month of continued writing. The problem
>was that it then gave wrong data but no error messages. Seems
>there is no CRC in these devices or it is switched off.
There might have been a time when one could try and make one
go bad, but today the capacities are much higher so not only
can one select a drive of far higher capacity than they fill
per a given storage requirement like 2GB, it takes a lot
longer to fill it.
That situation may change with the move to USB3 based flash
drives used for other things than backups, if someone buys
into window's readyboost or equivalent future features but I
discount this factor because main system memory has also
become so inexpensive that quite a lot more can be cached in
main memory these days.
>> All safe removal really does is wait to tell you it can be
>> removed if the buffer is not written out yet.
>>
>
>You say "All safe removal really does is wait to tell you it can
>be removed if the buffer is not written out yet."
>
>I thought the Safe Removal window actually *forced* the data to
>be flushed out of the write cache?
The write cache was still being written out continuously,
it's not like it waits to write until you or the OS tell it
to.
>Are you saying it is just a way of making the user wait until
>flushing is done (but not start flushing any sooner)?
Yes, but there are other factors like if you had a file in
use on the flash drive volume, so the safety in removing it
depends on, like most things in life, whether the user is
aware of the details.
>Many times Safe Removal window says something like operatiom
>failed to stop the drive or adaptor. Repeated tries don't seem to
>improve this.
Finding cause would have to be done on a case by case basis.
Sometimes an app won't release a lock on a file, windows
thinks it's still being used. As you noted, using Safe
Remove or not doesn't make a difference then.
>> You say "All safe removal really does is wait to tell you
>> it can be removed if the buffer is not written out yet."
>
>> I thought the Safe Removal window actually *forced*
>> the data to be flushed out of the write cache?
>
>It does both.
>
>> Are you saying it is just a way of making the user wait
>> until flushing is done (but not start flushing any sooner)?
>
>If that is what he is saying, he is wrong.
With a pending write operation, do tell us what is going to
make the OS think to itself "I'll just wait until someone
tells me to write this a 2nd time as the first was just an
idea not a command", instead of doing it at next available
opportunity just as if you use Safely Remove feature?
>> Many times Safe Removal window says something like operatiom
>> failed to stop the drive or adaptor. Repeated tries don't seem to
>> improve this.
>
>On one system I do occasionally get it saying that it cant currently be removed and another go allows it to be removed.
>
>It never keeps saying that it cant be removed.
>
>And I use that system every couple of days.
>
It can keep stating that, though I admit I haven't waited
several days to try again but minutes to hours later it can.
>>> You say "All safe removal really does is wait to tell you
>>> it can be removed if the buffer is not written out yet."
>>> I thought the Safe Removal window actually *forced*
>>> the data to be flushed out of the write cache?
>> It does both.
>>> Are you saying it is just a way of making the user wait
>>> until flushing is done (but not start flushing any sooner)?
>> If that is what he is saying, he is wrong.
> With a pending write operation, do tell us what is going to
> make the OS think to itself "I'll just wait until someone
> tells me to write this a 2nd time as the first was just an
> idea not a command", instead of doing it at next available
> opportunity just as if you use Safely Remove feature?
You never ever could bullshit your way out of a wet paper bag.
>>> Many times Safe Removal window says something like operatiom
>>> failed to stop the drive or adaptor. Repeated tries don't seem to
>>> improve this.
>> On one system I do occasionally get it saying that it cant
>> currently be removed and another go allows it to be removed.
>> It never keeps saying that it cant be removed.
>> And I use that system every couple of days.
> It can keep stating that,
I said THAT SYSTEM never does that, fuckwit.
>kony wrote
>> Rod Speed <rod.sp...@gmail.com> wrote
>
>>>> You say "All safe removal really does is wait to tell you
>>>> it can be removed if the buffer is not written out yet."
>
>>>> I thought the Safe Removal window actually *forced*
>>>> the data to be flushed out of the write cache?
>
>>> It does both.
>
>>>> Are you saying it is just a way of making the user wait
>>>> until flushing is done (but not start flushing any sooner)?
>
>>> If that is what he is saying, he is wrong.
>
>> With a pending write operation, do tell us what is going to
>> make the OS think to itself "I'll just wait until someone
>> tells me to write this a 2nd time as the first was just an
>> idea not a command", instead of doing it at next available
>> opportunity just as if you use Safely Remove feature?
>
>You never ever could bullshit your way out of a wet paper bag.
Haha, thank you for conceding I am right. For those not
acquainted with Rod Speed jargon, google groups will bring
you up to /rod/ speed.
>>> It never keeps saying that it cant be removed.
>
>>> And I use that system every couple of days.
>
>> It can keep stating that,
>
>I said THAT SYSTEM never does that, fuckwit.
Then what are you referring to? A hypothetical system that
never does? lol, if that is the case, then by definition
your hypothetical system meets that, but since it is a dream
rather than a constant, we can ignore it as something to
assume.
In an ideal world you would be right, that's how things
ought to work. In the real world, apps misbehave and
windows doesn't provide the level of checks and balances
needed... and why would it, there is no competitive reason
they would need to do so.
That's why monopolies are bad, simple things like this go
unresolved for years.
>>>>> You say "All safe removal really does is wait to tell you
>>>>> it can be removed if the buffer is not written out yet."
>>>>> I thought the Safe Removal window actually *forced*
>>>>> the data to be flushed out of the write cache?
>>>> It does both.
>>>>> Are you saying it is just a way of making the user wait
>>>>> until flushing is done (but not start flushing any sooner)?
>>>> If that is what he is saying, he is wrong.
>>> With a pending write operation, do tell us what is going to
>>> make the OS think to itself "I'll just wait until someone
>>> tells me to write this a 2nd time as the first was just an
>>> idea not a command", instead of doing it at next available
>>> opportunity just as if you use Safely Remove feature?
>> You never ever could bullshit your way out of a wet paper bag.
> Haha, thank you for conceding I am right.
You're lying, as always, when you get done like a dinner, as always.
>>>> It never keeps saying that it cant be removed.
>>>> And I use that system every couple of days.
>>> It can keep stating that,
>> I said THAT SYSTEM never does that, fuckwit.
> Then what are you referring to?
THAT SYSTEM I made that comment about, fuckwit.
> A hypothetical system that never does?
Nope.
> lol, if that is the case, then by definition your hypothetical
> system meets that, but since it is a dream rather than a
> constant, we can ignore it as something to assume.
You'll end up completely blind if you dont watch out, child.
> In an ideal world you would be right, that's how things
> ought to work. In the real world, apps misbehave and
> windows doesn't provide the level of checks and balances
> needed... and why would it, there is no competitive reason
> they would need to do so.
> That's why monopolies are bad, simple things like this go unresolved for years.
You'll end up completely blind if you dont watch out, child.
>>In comp.sys.ibm.pc.hardware.storage kony <sp...@spam.com> wrote:
>>> On Tue, 17 Nov 2009 13:30:10 -0500, "David W. Hodgins"
>>> <dwho...@nomail.afraid.org> wrote:
>>
>>>>On Tue, 17 Nov 2009 11:15:19 -0500, Eddie <du...@invalid.com> wrote:
>>>>
>>>>> Or does the emptying of the write cache depend on OTHER FACTORS than
>>>>> elapsed time?
>>>>
>>>>Suppose the antivirus program is downloading a large update, that
>>>>you are not yet aware of. The writes to the flash drive may, or
>>>>may not be completed quickly. The only way to be sure, is to use
>>>>the remove safely option.
>>
>>> BUT, are you really, REALLY sure? Or are you only placing
>>> confidence in windows doing what it is supposed to do? It's
>>> that a bit of the same thing as assuming the drive LED
>>> access indicator is doing what it is supposed to do?
>>
>>Windows will tell you that it is safe to remove the drive only
>>after it has a) written all buffered data and b) blocked the
>>device so no new writes can happen. In the absence of a programming
>>error, this is reliable.
> ^ That last sentence is the key... of course windows has
> never had programming errors and never will, they're design
> /features/.
Ok, let me re-phrase that ;-)
If MS has not (again) messed up functionality that is important
and works reliable on real OSes, then safe removal on Windoes
is indeed safe.
Short form: Don't use Windows unless you have to. It sucks.
The question we are discussing here does not even come
up with proper OSes.
>>> You say "All safe removal really does is wait to tell you
>>> it can be removed if the buffer is not written out yet."
>>
>>> I thought the Safe Removal window actually *forced*
>>> the data to be flushed out of the write cache?
>>
>>It does both.
>>
>>> Are you saying it is just a way of making the user wait
>>> until flushing is done (but not start flushing any sooner)?
>>
>>If that is what he is saying, he is wrong.
> With a pending write operation, do tell us what is going to
> make the OS think to itself "I'll just wait until someone
> tells me to write this a 2nd time as the first was just an
> idea not a command", instead of doing it at next available
> opportunity just as if you use Safely Remove feature?
Actually the way this goes ios something like this:
1) The OS waits until it reaches the soft flush timeout.
The intention is to get larger writes.
It then starts to write with relative low priority.
It may also start before if the I/O load is low.
2) Then data in the buffer reaches a certain age
(the hard flush timeout), then the data is written to
disk with high priority and very little other things get
done. Data written in this mode to a different disk can
still cause delays.
The longer delay 1) does give significant performance
improvement. Historically, it used to be as high as 5 minutes,
and is more in the 1 minute range now.
With an "optimize for fast removal", the hard flush timeout
is set to zero or a very low value (1 sec). An alternative
is a "sync" mount, were data is flushed immediately, but
that has massive negative impact on performance (e.g.
100-1000 times slower). It is the only way to ensure data
is on disk before the write system call returns to the
application. Even with a sync mount, writing can take some
time. Due to its low performance, a sync mount is possibly
less safe for the purpose at hand.
What happens on umount (safe removal, why does MS has to
invent their own language for well established things??)
is that the hard flush timeout is set to zero for the
affectyed device and the buffer is monitred until there
are no more pending writes for the device. In addition the
device is removed from visibility for the applications.
This may fail if some applications have open files. The
failure is the correct bbehaviour here, a forced close on
open files usually causes data corruption.
When done, the "you may now unplug" message is displayed.
Indeed. That is also why MS is so keen on maintaining its
monopoly. They know thay cannot compete on technological
merit. It is incredible how far they are behind in some
areas.
Really good info. Thank you. Where's it from? It explains background
to some things already posted and shows some previous info hasn't
been 100% right.
Eg. wait a few secs after LED stops.
Eg. need to close apps for Safe Removal to succeed.
Eg. ...
Well, basically from my academic OS design course (I was
listener not lecturer, not exactly my field) and from wanting
to find out way back. It is an important topic in OS design, so
a current book on the topic should have one or several
chapters on this.
One problem with Windows is that they do not follow established
ways to do this. In Unix, e.g., you always have to explicetly
tell the OS to release a storage medium and to make the potential
damage of unexpected removal small, journalling filesystems are
used.
There is no monopoly, the main alternative is quite literally free.
In the real world that the rest of us live in, it will take longer to write
more data to a USB flash drive than it would to write less information.
Unless you can guarantee that the data write has finished then for peace of
mind, you should *always* use the safe removal option. If the USB stick has
an LED and you can see that the write activity has stopped and the OS is not
busy doing something else, then you can pull it out. If the USB stick has no
LED, then you will not know for sure whether the OS has finished writing to
it or not. If you are content with crossing your fingers and hoping that 'a
while' has passed, then you can follow Rod's advice and just pull the USB
stick out.
Telling us that the length of time the OS needs to write to the USB stick is
'a while', but then telling us that the time is irrelevant is really not
helpful!
>My friends get upset if I don't use the Safe Removal process when
>their USB memory is in my PC. Maybe they're repeating a mistake? Or
>is there a reason which I'm missing that says I should always use
>Safe Removal?
I always do safe removal. Sometimes it's not obvious that some
program has an open file handle on the USB stick, and when you do the
safe removal Windows will warn you of this (tell you that you can't
remove it yet).
That was a comment on the second and third bits, not the first which was too obvious to comment on.
> Unless you can guarantee that the data write has finished then for
> peace of mind, you should *always* use the safe removal option.
Wrong when you check whats happened with the copy popup and the led on the stick.
> If the USB stick has an LED and you can see that the write activity has stopped and the OS is not busy doing something
> else, then you can pull it out.
What I said in different words.
> If the USB stick has no LED, then you will not know for
> sure whether the OS has finished writing to it or not.
Wrong. You can check the popup on that.
> If you are content with crossing your fingers and hoping that 'a while' has
> passed, then you can follow Rod's advice and just pull the USB stick out.
Or you can have enough of a clue to use the led and the popup.
> Telling us that the length of time the OS needs to write to the USB stick is 'a while', but then telling us that the
> time is irrelevant is really not helpful!
Your mindless pig ignorant shit in spades.
Same here.
Tim Mastrogiacomo
This is a toilet seat issue! There are logical reasons why you shouldn't
need to put the seat down, but if you want your honey to be nice to you, you
do it. Only an idiot would fight that fight! Use safe removal for your
friends and make crude comments as you do it to entertain yourself and ease
the "pain". But then that's another thorny office issue too, ain't it?
>Really good info. Thank you. Where's it from? It explains background
>to some things already posted and shows some previous info hasn't
>been 100% right.
>
>Eg. wait a few secs after LED stops.
>Eg. need to close apps for Safe Removal to succeed.
>Eg. ...
Except you can clearly see windows behavior yourself and
didn't read (or I didn't express well enough) that those who
want not to have to use Safely Remove will have left the
optimize for safe removal default setting as-is.
If you leave the default "optimize for quick removal" for
the flash drive, you will never have to wait even 1/4th a
minute after the LED stops, the "few seconds" isn't even
needed but to make sure you are seeing it stopped in case
you misrecall the LED activity patterns between multiple
different drives.
Those of us who routinely use flash drives without using
safely remove feature realize this. Try it yourself, on a
test if you doubt it rather than only backup up important
data.
Once a post has triggered a "rodbot" reply, you just have to ignore any
posts by Rod in that branch - you'll never get an intelligible response
from him. Pick a different branch and make the same comment or ask the
same question, and you might well get a helpful answer.
> In the real world that the rest of us live in, it will take longer to write
> more data to a USB flash drive than it would to write less information.
>
> Unless you can guarantee that the data write has finished then for peace of
> mind, you should *always* use the safe removal option. If the USB stick has
> an LED and you can see that the write activity has stopped and the OS is not
> busy doing something else, then you can pull it out. If the USB stick has no
> LED, then you will not know for sure whether the OS has finished writing to
> it or not. If you are content with crossing your fingers and hoping that 'a
> while' has passed, then you can follow Rod's advice and just pull the USB
> stick out.
>
Another thing to remember here is that while the LED going out or the
"copy box" closing will indicate the end of that particular write, you
don't necessarily know that there will be no more writes. If all you
are doing is putting the stick in, copying files, then taking it out,
then you know what's going on. But if you are using the stick directly,
and have applications opening files on the disk, then there may be other
things going on. For example, MS Word likes to make hidden temporary
files in the same directory as the original data file. It will do no
harm if these files get lost or corrupted during an unsafe removal, but
you also risk messing up the FAT or directories with corrupted writes.
Just because the LED has gone out, does not guarantee that it won't come
on again just as you are pulling it out!
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.
> Rod Speed <rod.sp...@gmail.com> wrote
> Your mindless pig ignorant shit in spades.
I think you will find it impossible to shit 'in' spades as a spade is a flat
metallic gardening implement. Perhaps you meant shit 'on' spades? Please
check your post before committing! A couple of 8 letter words though - well
done - obviously didn't learn those from your mamma!
See: http://www.venukb.com/2008/06/11/safely-remove-usb-hardware/
Never ever could bullshit and lie its way outof a wet paper bag.
>> In the real world that the rest of us live in, it will take longer to write more data to a USB flash drive than it
>> would to write less information.
>> Unless you can guarantee that the data write has finished then for
>> peace of mind, you should *always* use the safe removal option. If
>> the USB stick has an LED and you can see that the write activity has
>> stopped and the OS is not busy doing something else, then you can
>> pull it out. If the USB stick has no LED, then you will not know for
>> sure whether the OS has finished writing to it or not. If you are
>> content with crossing your fingers and hoping that 'a while' has
>> passed, then you can follow Rod's advice and just pull the USB stick out.
> Another thing to remember here is that while the LED going out or the
> "copy box" closing will indicate the end of that particular write, you
> don't necessarily know that there will be no more writes. If all you
> are doing is putting the stick in, copying files, then taking it out,
> then you know what's going on. But if you are using the stick
> directly, and have applications opening files on the disk, then there
> may be other things going on. For example, MS Word likes to make
> hidden temporary files in the same directory as the original data
> file. It will do no harm if these files get lost or corrupted during
> an unsafe removal, but you also risk messing up the FAT or
> directories with corrupted writes. Just because the LED has gone out,
> does not guarantee that it won't come on again just as you are pulling it out!
It does if you wait a few seconds after it goes out, fool.
... 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.
>>> Those of us who routinely use flash drives without using
>>> safely remove feature realize this. Try it yourself, on a
>>> test if you doubt it rather than only backup up important
>>> data.
>>
>> 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
>>
>>
>All too true. What is truly amazing is that when it is pointed out to them
>they get defensive and refuse to even listen to why it's risky
>and maybe they should consider paying attention to safe practices until they
>have their second or third disaster. Then they come back here whining about
>the unreliability of the equipment.
Aren't blanket generalizations great (even if not true much
of the time)?
Show us someone who came here and whined about a problem
removing a flash drive with the optimize for removal default
setting left at the default/enabled, who had a problem that
wasn't due to some other factor rather than not using
"safely remove".
Those of us who do it all the time know it works fine. In
some circles that would be considered proof rather than
paranoia.
There is a difference between denying a risk exists and willingness
to accept a risk. I am talking about the former, obviously.
>> ... 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.
>
>There is a difference between denying a risk exists and willingness
>to accept a risk. I am talking about the former, obviously.
>
>Arno
... only in principle not reality, if you never see any
problem...
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".
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.
... which is drifting into the realm of tin-foil hats and
myths.
I use USB flash drives constantly, it's really not a problem
and the logic isn't sound for using Safely Remove.
You:
1) Distrust Windows to work properly after MS has already
stated you won't need to use Safely Remove if the default
Optimize for Quick Removal is left as the default.
2) Suddenly trust windows again, that using Safely Remove
will matter enough to consider it safe because they use the
word "safe" in it's name?
Safely Remove Hardware does absolutely nothing if windows is
left at the defaults for the device. Period. (except waste
your time).
>Safely Remove Hardware does absolutely nothing if windows is
>left at the defaults for the device. Period. (except waste
>your time).
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.
>In comp.sys.ibm.pc.hardware.storage kony <sp...@spam.com> wrote:
>> On 21 Nov 2009 10:55:13 GMT, Arno <m...@privacy.net> wrote:
>
>
>>>> ... 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.
>>>
>>>There is a difference between denying a risk exists and willingness
>>>to accept a risk. I am talking about the former, obviously.
>>>
>>>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.
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
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.
The dismount is pretty important. Otherwise an application
could start writing between the "you may now remove..."
message and the actual removal.
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.
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
> The dismount is pretty important. Otherwise an application
> could start writing between the "you may now remove..."
> message and the actual removal.
Question: How does one unmount/dismount in Windows 98 SE since it
doesn't have those USB safety removal option in its system tray?
--
"What is it all but a trouble of ants... In the gleam of a million...
million of suns? --Alfred Lord Tennyson
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Nuke ANT from e-mail address: phi...@earthlink.netANT
( ) or ANT...@zimage.com
Ant is currently not listening to any songs on his home computer.
You missed a space.
<heavily edited for brevity>
> > Cost is the main reason few sticks have an LED, rather
> > than size, but either way they are rare in my experience.
>
> 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.
--
Cordially,
John Turco <jt...@concentric.net>
Paintings Pain and Pun <http://laughatthepain.blogspot.com>
> <heavily edited for brevity>
There you go again...
>>> Cost is the main reason few sticks have an LED, rather
>>> than size, but either way they are rare in my experience.
>> Then you need to get out more. Most of us get the exact
>> opposite effect, very few flash sticks that dont have one.
> <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.
>> The dismount is pretty important. Otherwise an application
>> could start writing between the "you may now remove..."
>> message and the actual removal.
> 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?
>
> 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?
>In comp.sys.ibm.pc.hardware.storage kony <sp...@spam.com> wrote:
>> On Sun, 22 Nov 2009 14:58:43 -0500, kony <sp...@spam.com>
>> wrote:
>
>
>>>Safely Remove Hardware does absolutely nothing if windows is
>>>left at the defaults for the device. Period. (except waste
>>>your time).
>
>
>> 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
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.
>> 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?
It's not me. It's the clients. :/
--
"Only two great groups of animals, men and ants, indulge in highly
organized mass warfare." --Charles H. Maskins
Right, idiot, so it's not a matter of "suddenly trusting Microsoft".
It's doing something *DIFFERENT*.
Doing something different. Thanks for that verbose reply.
> chrisv wrote:
>
>> kony wrote:
>>
>>> kony wrote:
>>>
>>>>Safely Remove Hardware does absolutely nothing if windows is
>>>>left at the defaults for the device. Period. (except waste
>>>>your time).
>>>
>>>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.
>>
>>Right, idiot, so it's not a matter of "suddenly trusting Microsoft".
>>It's doing something *DIFFERENT*.
>
>Doing something different. Thanks for that verbose reply.
You wrote it yourself, idiot. Starts with "dis".
But you forgot to mention you think it's important to
dismount the volume and why.
If the user knows there aren't any valuable files left open
and sees the I/O activity is done via the LED, unplugging it
without using Safely Remove will also dismount it.
I guess some people can make use of a feature and others are
too worried the sky is falling. If it doesn't work for you
I would investigate why since others are able to use their
removable USB drives fine without jumping through this hoop.
>>> 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?
> It's not me. It's the clients. :/
My condolences. Maybe there is an "umount utility" for
Win 98 that addresses the problem?
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.
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
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.
>On 11/22/2009 1:30 PM PT, Arno typed:
>
>> The dismount is pretty important. Otherwise an application
>> could start writing between the "you may now remove..."
>> message and the actual removal.
>
>Question: How does one unmount/dismount in Windows 98 SE since it
>doesn't have those USB safety removal option in its system tray?
By physically removing it from the USB port. Just as with
later windows OS left at their defaults, you don't need to
unmount the volume. If an app then claims it can't write,
plug the flash drive back in, though it is typically pretty
clear whether that situation would exist, who really wants
apps writing to their flash drive that they weren't aware
of, and who doesn't realize that when they produce something
in an app they have to save the file at the end?
Ultimately, instead of training a user to use a removal app
if there is or were one, they can simply be instructed to
carry on as they always have, saving files while the drive
is plugged in and not removing it while the access indicator
LED is showing access.
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
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
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