Well, simple reads wouldn't cause any problems, but sure, any write in
process that gets interrupted could be a problem, especially when you
don't know WHERE the write/s is/are taking place. But that's the case
with any operating system and any disk drive so it's not specific to
windows or ext drives, etc..
It is worse in XP though, because the registry is under constant
activity, even when there are no applications running on the computer.
A LOT is going on behind the scenes that the user is seldom aware of.
As long as a machine is powered down properly though, it's not a
problem. Useing Task Manager to End a Task causes no problems since,
although it forces and end to the service/program, it does so
gracefully. Loss of ac power though gives you something better than a
50-50 chance something will corrupt. That's why chkdsk often runs
automatically after such an event; to straighten out the tables and
areas it has dominion over in order to at least let the machine boot.
Or not<g>.
TGM said:
That's really unfortunate because this particular one was powered
soley by the USB port. Criminey.
Don't quote me here: Anyone who pipes in will probably be more accurate
than I:
Proper Shut Down of the computer though would have allowed a proper shut
down of the USB device in most cases. It will also flush buffers on the
way down, IF there aren't programs holding them open, as in a file/s
save. In that case things can get out of order, and by the time it tries
to save the pending write, it's already too late. Had the program
been closed and the file properly stated, then the cache would be
flushed onto the drive and all would be fine. Apparently it gets real
iffy in this area and you may or may not have corruption as a result of
the program holding a buffer open while the registry thinks it's been
written to, close it, and then the data never gets to the drive.
What's the size of the write cache typically?????
I think there is a max size, based on installed RAM and pagefile, but
IME the buffer isn't usually maxxed out. The buffer will only have in
it what was left to write before it lost the processor's attention. And
that activity flashes back and forth a bunch of times, write a little,
go do someting higher pri, write a little more, hi pri again, and so
forth. It's when it can't get the processor's attention any more it
sits there and waits. As in, the program is open, so ... no rush to
write this stuff, it lets other tasks run instead. Closing the file
SHOULD flush the buffer but I know lots of times I actually have to
close the application before it flushes. It that's by design, which I
doubt, it's a crummy process. IMO it's a "feature" they didn't fix.
Twayne