Last night I was copying files from a Windows XP laptop to a USB
external hard drive. Then when I tried to safely remove the hard
drive, I got an error saying "Generic volume cannot be stopped". I've
seen this error before and it goes away if I restart Windows, but this
time I didn't want to restart, so I just put my laptop into
hibernation, and when I brought it out of hibernation, I was able to
safely remove the drive.
Then later I copied more files to the USB drive, and when I tried to
safely remove it again, I got the "Generic volume cannot be stopped"
error again. So I put the laptop into hibernation again, but when I
brought the laptop out of hibernation, Windows displayed a dialog box
saying:
"Delayed Write Failed - Windows was unable to save all the data for
the file e:\$Mft. The data has been lost. This error may be caused
by a failure of your computer hardware or network connection. Please
try to save this file elsewhere."
My USB drive is drive E, and the $Mft apparently stands for master
file table. That error seems to say that data was definitely lost, but
when I ran a chkdsk on the drive, I got the following output:
C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
The type of the file system is NTFS.
Volume label is Elements.
CHKDSK is verifying files (stage 1 of 5)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 5)...
Index verification completed.
Cleaning up minor inconsistencies on the drive.
CHKDSK is verifying security descriptors (stage 3 of 5)...
Cleaning up 12 unused index entries from index $SII of file 9.
Cleaning up 12 unused index entries from index $SDH of file 9.
Cleaning up 12 unused security descriptors.
Fixing mirror copy of the security descriptors data stream.
Security descriptor verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
Free space verification is complete.
625131831 KB total disk space.
577839972 KB in 1884 files.
1024 KB in 437 indexes.
0 KB in bad sectors.
87383 KB in use by the system.
65536 KB occupied by the log file.
47203452 KB available on disk.
4096 bytes in each allocation unit.
156282957 total allocation units on disk.
11800863 allocation units available on disk.
That chkdsk output seems to indicate the drive only had minor
inconsistencies and problems with security descriptors. It doesn't say
anything about data errors. Is it possible that I still lost data on
the drive?
Re: Delayed Write Failed - could I have lost data?
On 10/19/2011 12:45 PM, void.no.spam.com@gmail.com wrote:
> Last night I was copying files from a Windows XP laptop to a USB
> external hard drive. Then when I tried to safely remove the hard
> drive, I got an error saying "Generic volume cannot be stopped". I've
> seen this error before and it goes away if I restart Windows, but this
> time I didn't want to restart, so I just put my laptop into
> hibernation, and when I brought it out of hibernation, I was able to
> safely remove the drive.
>
> Then later I copied more files to the USB drive, and when I tried to
> safely remove it again, I got the "Generic volume cannot be stopped"
> error again. So I put the laptop into hibernation again, but when I
> brought the laptop out of hibernation, Windows displayed a dialog box
> saying:
>
> "Delayed Write Failed - Windows was unable to save all the data for
> the file e:\$Mft. The data has been lost. This error may be caused
> by a failure of your computer hardware or network connection. Please
> try to save this file elsewhere."
>
> My USB drive is drive E, and the $Mft apparently stands for master
> file table. That error seems to say that data was definitely lost, but
> when I ran a chkdsk on the drive, I got the following output:
>
> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
> The type of the file system is NTFS.
> Volume label is Elements.
>
> CHKDSK is verifying files (stage 1 of 5)...
> File verification completed.
> CHKDSK is verifying indexes (stage 2 of 5)...
> Index verification completed.
> Cleaning up minor inconsistencies on the drive.
> CHKDSK is verifying security descriptors (stage 3 of 5)...
> Cleaning up 12 unused index entries from index $SII of file 9.
> Cleaning up 12 unused index entries from index $SDH of file 9.
> Cleaning up 12 unused security descriptors.
> Fixing mirror copy of the security descriptors data stream.
> Security descriptor verification completed.
> CHKDSK is verifying file data (stage 4 of 5)...
> File data verification completed.
> CHKDSK is verifying free space (stage 5 of 5)...
> Free space verification is complete.
>
> 625131831 KB total disk space.
> 577839972 KB in 1884 files.
> 1024 KB in 437 indexes.
> 0 KB in bad sectors.
> 87383 KB in use by the system.
> 65536 KB occupied by the log file.
> 47203452 KB available on disk.
>
> 4096 bytes in each allocation unit.
> 156282957 total allocation units on disk.
> 11800863 allocation units available on disk.
>
> That chkdsk output seems to indicate the drive only had minor
> inconsistencies and problems with security descriptors. It doesn't say
> anything about data errors. Is it possible that I still lost data on
> the drive?
Re: Delayed Write Failed - could I have lost data?
What the messages basically meant were that your laptop had been attempting
to save data to the portable drive, but that in your trying to "out smart"
the warning that the "drive could NOT be safely removed at this time" (or
similar), there was corruption of that data that was being written to the
drive - *at that time*.
This data corruption was limited to the file that was being written at the
time the PC lost power due to the end of the hibernate sequence. And also,
the MFT would have lost it's validity due to the fact it could not be
updated after the loss.
The MFT was fixed by running chkdsk, and the data was probably some
inconsequential file written by a background process that enumerates
removable media (e.g. Window's Media Player). But I think you got off
lightly, the file system could have been damaged beyond repair on the
portable drive, and all data on it lost permanently.
You should always wait until Windows says that you may safely remove a
drive - else, if Windows will allow it, configure the device for quick
removal by check-marking the appropriate box in it's Device Manager
"Properties" for that drive.
==
Cheers, Tim Meddick, Peckham, London. :-)
<void.no.spam.com@gmail.com> wrote in message
news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
> Last night I was copying files from a Windows XP laptop to a USB
> external hard drive. Then when I tried to safely remove the hard
> drive, I got an error saying "Generic volume cannot be stopped". I've
> seen this error before and it goes away if I restart Windows, but this
> time I didn't want to restart, so I just put my laptop into
> hibernation, and when I brought it out of hibernation, I was able to
> safely remove the drive.
>
> Then later I copied more files to the USB drive, and when I tried to
> safely remove it again, I got the "Generic volume cannot be stopped"
> error again. So I put the laptop into hibernation again, but when I
> brought the laptop out of hibernation, Windows displayed a dialog box
> saying:
>
> "Delayed Write Failed - Windows was unable to save all the data for
> the file e:\$Mft. The data has been lost. This error may be caused
> by a failure of your computer hardware or network connection. Please
> try to save this file elsewhere."
>
> My USB drive is drive E, and the $Mft apparently stands for master
> file table. That error seems to say that data was definitely lost, but
> when I ran a chkdsk on the drive, I got the following output:
>
> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
> The type of the file system is NTFS.
> Volume label is Elements.
>
> CHKDSK is verifying files (stage 1 of 5)...
> File verification completed.
> CHKDSK is verifying indexes (stage 2 of 5)...
> Index verification completed.
> Cleaning up minor inconsistencies on the drive.
> CHKDSK is verifying security descriptors (stage 3 of 5)...
> Cleaning up 12 unused index entries from index $SII of file 9.
> Cleaning up 12 unused index entries from index $SDH of file 9.
> Cleaning up 12 unused security descriptors.
> Fixing mirror copy of the security descriptors data stream.
> Security descriptor verification completed.
> CHKDSK is verifying file data (stage 4 of 5)...
> File data verification completed.
> CHKDSK is verifying free space (stage 5 of 5)...
> Free space verification is complete.
>
> 625131831 KB total disk space.
> 577839972 KB in 1884 files.
> 1024 KB in 437 indexes.
> 0 KB in bad sectors.
> 87383 KB in use by the system.
> 65536 KB occupied by the log file.
> 47203452 KB available on disk.
>
> 4096 bytes in each allocation unit.
> 156282957 total allocation units on disk.
> 11800863 allocation units available on disk.
>
> That chkdsk output seems to indicate the drive only had minor
> inconsistencies and problems with security descriptors. It doesn't say
> anything about data errors. Is it possible that I still lost data on
> the drive?
> Last night I was copying files from a Windows XP laptop to a USB
> external hard drive. Then when I tried to safely remove the hard
> drive, I got an error saying "Generic volume cannot be stopped".
> I've seen this error before and it goes away if I restart Windows,
I do see it occasionally with an XP laptop and I just close the window
that was used to look at the USB hard drive, and just try the safely remove
again when it very rarely does it again even with that window closed.
Very very rarely even that wont work, but thats because I dont shutdown
that laptopl have it set to hibernate automatically when I close the lid and
that can see XP eventually need a reboot after months used like that.
> but this time I didn't want to restart, so I just put my laptop
> into hibernation, and when I brought it out of hibernation,
> I was able to safely remove the drive.
You might well have found that just retrying the safely remove would have worked.
> Then later I copied more files to the USB drive, and when I tried to
> safely remove it again, I got the "Generic volume cannot be stopped"
> error again. So I put the laptop into hibernation again, but when I brought
> the laptop out of hibernation, Windows displayed a dialog box saying:
> "Delayed Write Failed - Windows was unable to save all the
> data for the file e:\$Mft. The data has been lost. This error
> may be caused by a failure of your computer hardware or
> network connection. Please try to save this file elsewhere."
> My USB drive is drive E, and the $Mft apparently stands for master
> file table. That error seems to say that data was definitely lost, but
> when I ran a chkdsk on the drive, I got the following output:
>
> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
> The type of the file system is NTFS.
> Volume label is Elements.
>
> CHKDSK is verifying files (stage 1 of 5)...
> File verification completed.
> CHKDSK is verifying indexes (stage 2 of 5)...
> Index verification completed.
> Cleaning up minor inconsistencies on the drive.
> CHKDSK is verifying security descriptors (stage 3 of 5)...
> Cleaning up 12 unused index entries from index $SII of file 9.
> Cleaning up 12 unused index entries from index $SDH of file 9.
> Cleaning up 12 unused security descriptors.
> Fixing mirror copy of the security descriptors data stream.
> Security descriptor verification completed.
> CHKDSK is verifying file data (stage 4 of 5)...
> File data verification completed.
> CHKDSK is verifying free space (stage 5 of 5)...
> Free space verification is complete.
> 625131831 KB total disk space.
> 577839972 KB in 1884 files.
> 1024 KB in 437 indexes.
> 0 KB in bad sectors.
> 87383 KB in use by the system.
> 65536 KB occupied by the log file.
> 47203452 KB available on disk.
> 4096 bytes in each allocation unit.
> 156282957 total allocation units on disk.
> 11800863 allocation units available on disk.
> That chkdsk output seems to indicate the drive only had minor
> inconsistencies and problems with security descriptors. It doesn't say
> anything about data errors. Is it possible that I still lost data on the drive?
On 10/19/2011 2:13 PM, Tim Meddick wrote:
> What the messages basically meant were that your laptop had been
> attempting to save data to the portable drive, but that in your trying
> to "out smart" the warning that the "drive could NOT be safely removed
> at this time" (or similar), there was corruption of that data that was
> being written to the drive - *at that time*.
>
> This data corruption was limited to the file that was being written at
> the time the PC lost power due to the end of the hibernate sequence. And
> also, the MFT would have lost it's validity due to the fact it could not
> be updated after the loss.
>
> The MFT was fixed by running chkdsk, and the data was probably some
> inconsequential file written by a background process that enumerates
> removable media (e.g. Window's Media Player). But I think you got off
> lightly, the file system could have been damaged beyond repair on the
> portable drive, and all data on it lost permanently.
>
> You should always wait until Windows says that you may safely remove a
> drive - else, if Windows will allow it, configure the device for quick
> removal by check-marking the appropriate box in it's Device Manager
> "Properties" for that drive.
>
> ==
>
> Cheers, Tim Meddick, Peckham, London. :-)
>
>
>
>
> <void.no.spam.com@gmail.com> wrote in message
> news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
>> Last night I was copying files from a Windows XP laptop to a USB
>> external hard drive. Then when I tried to safely remove the hard
>> drive, I got an error saying "Generic volume cannot be stopped". I've
>> seen this error before and it goes away if I restart Windows, but this
>> time I didn't want to restart, so I just put my laptop into
>> hibernation, and when I brought it out of hibernation, I was able to
>> safely remove the drive.
>>
>> Then later I copied more files to the USB drive, and when I tried to
>> safely remove it again, I got the "Generic volume cannot be stopped"
>> error again. So I put the laptop into hibernation again, but when I
>> brought the laptop out of hibernation, Windows displayed a dialog box
>> saying:
>>
>> "Delayed Write Failed - Windows was unable to save all the data for
>> the file e:\$Mft. The data has been lost. This error may be caused
>> by a failure of your computer hardware or network connection. Please
>> try to save this file elsewhere."
>>
>> My USB drive is drive E, and the $Mft apparently stands for master
>> file table. That error seems to say that data was definitely lost, but
>> when I ran a chkdsk on the drive, I got the following output:
>>
>> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>> The type of the file system is NTFS.
>> Volume label is Elements.
>>
>> CHKDSK is verifying files (stage 1 of 5)...
>> File verification completed.
>> CHKDSK is verifying indexes (stage 2 of 5)...
>> Index verification completed.
>> Cleaning up minor inconsistencies on the drive.
>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>> Cleaning up 12 unused index entries from index $SII of file 9.
>> Cleaning up 12 unused index entries from index $SDH of file 9.
>> Cleaning up 12 unused security descriptors.
>> Fixing mirror copy of the security descriptors data stream.
>> Security descriptor verification completed.
>> CHKDSK is verifying file data (stage 4 of 5)...
>> File data verification completed.
>> CHKDSK is verifying free space (stage 5 of 5)...
>> Free space verification is complete.
>>
>> 625131831 KB total disk space.
>> 577839972 KB in 1884 files.
>> 1024 KB in 437 indexes.
>> 0 KB in bad sectors.
>> 87383 KB in use by the system.
>> 65536 KB occupied by the log file.
>> 47203452 KB available on disk.
>>
>> 4096 bytes in each allocation unit.
>> 156282957 total allocation units on disk.
>> 11800863 allocation units available on disk.
>>
>> That chkdsk output seems to indicate the drive only had minor
>> inconsistencies and problems with security descriptors. It doesn't say
>> anything about data errors. Is it possible that I still lost data on
>> the drive?
>
Re: Delayed Write Failed - could I have lost data?
John John MVP wrote
> The data was in the write cache,
You dont know that the data he deliberately copied to the USB drive was in the write cache.
Its very unlikely that it still was given that he tried to safely remove the hard drive and had
the system say that it couldnt do that. That should have flushed the write cache to the drive.
Its much more likely that what got lost was what the system was attempting to write
to the USB drive at the time the system was hibernated, different data entirely.
> it wasn't flushed to the disk so it was lost when the computer was rebooted.
You dont know that that was the data that he attempted to write to the USB drive.
> On 10/19/2011 2:13 PM, Tim Meddick wrote:
>> What the messages basically meant were that your laptop had been
>> attempting to save data to the portable drive, but that in your
>> trying to "out smart" the warning that the "drive could NOT be
>> safely removed at this time" (or similar), there was corruption of
>> that data that was being written to the drive - *at that time*.
>>
>> This data corruption was limited to the file that was being written
>> at the time the PC lost power due to the end of the hibernate
>> sequence. And also, the MFT would have lost it's validity due to the
>> fact it could not be updated after the loss.
>>
>> The MFT was fixed by running chkdsk, and the data was probably some
>> inconsequential file written by a background process that enumerates
>> removable media (e.g. Window's Media Player). But I think you got off
>> lightly, the file system could have been damaged beyond repair on the
>> portable drive, and all data on it lost permanently.
>>
>> You should always wait until Windows says that you may safely remove
>> a drive - else, if Windows will allow it, configure the device for
>> quick removal by check-marking the appropriate box in it's Device
>> Manager "Properties" for that drive.
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London. :-)
>>
>>
>>
>>
>> <void.no.spam.com@gmail.com> wrote in message
>> news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
>>> Last night I was copying files from a Windows XP laptop to a USB
>>> external hard drive. Then when I tried to safely remove the hard
>>> drive, I got an error saying "Generic volume cannot be stopped".
>>> I've seen this error before and it goes away if I restart Windows,
>>> but this time I didn't want to restart, so I just put my laptop into
>>> hibernation, and when I brought it out of hibernation, I was able to
>>> safely remove the drive.
>>>
>>> Then later I copied more files to the USB drive, and when I tried to
>>> safely remove it again, I got the "Generic volume cannot be stopped"
>>> error again. So I put the laptop into hibernation again, but when I
>>> brought the laptop out of hibernation, Windows displayed a dialog
>>> box saying:
>>>
>>> "Delayed Write Failed - Windows was unable to save all the data for
>>> the file e:\$Mft. The data has been lost. This error may be caused
>>> by a failure of your computer hardware or network connection. Please
>>> try to save this file elsewhere."
>>>
>>> My USB drive is drive E, and the $Mft apparently stands for master
>>> file table. That error seems to say that data was definitely lost,
>>> but when I ran a chkdsk on the drive, I got the following output:
>>>
>>> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>>> The type of the file system is NTFS.
>>> Volume label is Elements.
>>>
>>> CHKDSK is verifying files (stage 1 of 5)...
>>> File verification completed.
>>> CHKDSK is verifying indexes (stage 2 of 5)...
>>> Index verification completed.
>>> Cleaning up minor inconsistencies on the drive.
>>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>>> Cleaning up 12 unused index entries from index $SII of file 9.
>>> Cleaning up 12 unused index entries from index $SDH of file 9.
>>> Cleaning up 12 unused security descriptors.
>>> Fixing mirror copy of the security descriptors data stream.
>>> Security descriptor verification completed.
>>> CHKDSK is verifying file data (stage 4 of 5)...
>>> File data verification completed.
>>> CHKDSK is verifying free space (stage 5 of 5)...
>>> Free space verification is complete.
>>>
>>> 625131831 KB total disk space.
>>> 577839972 KB in 1884 files.
>>> 1024 KB in 437 indexes.
>>> 0 KB in bad sectors.
>>> 87383 KB in use by the system.
>>> 65536 KB occupied by the log file.
>>> 47203452 KB available on disk.
>>>
>>> 4096 bytes in each allocation unit.
>>> 156282957 total allocation units on disk.
>>> 11800863 allocation units available on disk.
>>>
>>> That chkdsk output seems to indicate the drive only had minor
>>> inconsistencies and problems with security descriptors. It doesn't
>>> say anything about data errors. Is it possible that I still lost
>>> data on the drive?
Re: Delayed Write Failed - could I have lost data?
On 10/19/2011 3:15 PM, Rod Speed wrote:
> John John MVP wrote
>
>> The data was in the write cache,
>
> You dont know that the data he deliberately copied to the USB drive was in the write cache.
It's in the error message... "Delayed Write Failed". Delayed writing is
write-behind caching.
> Its very unlikely that it still was given that he tried to safely remove the hard drive and had
> the system say that it couldnt do that. That should have flushed the write cache to the drive.
>
> Its much more likely that what got lost was what the system was attempting to write
> to the USB drive at the time the system was hibernated, different data entirely.
>
>> it wasn't flushed to the disk so it was lost when the computer was rebooted.
>
> You dont know that that was the data that he attempted to write to the USB drive.
>
>> These may be helpful:
>
>> http://www.storagereview.com/guide/cacheWrite.html
>> http://support.microsoft.com/kb/818788
>> http://technet.microsoft.com/en-us/s...rnals/bb897438
>>
>
>> On 10/19/2011 2:13 PM, Tim Meddick wrote:
>>> What the messages basically meant were that your laptop had been
>>> attempting to save data to the portable drive, but that in your
>>> trying to "out smart" the warning that the "drive could NOT be
>>> safely removed at this time" (or similar), there was corruption of
>>> that data that was being written to the drive - *at that time*.
>>>
>>> This data corruption was limited to the file that was being written
>>> at the time the PC lost power due to the end of the hibernate
>>> sequence. And also, the MFT would have lost it's validity due to the
>>> fact it could not be updated after the loss.
>>>
>>> The MFT was fixed by running chkdsk, and the data was probably some
>>> inconsequential file written by a background process that enumerates
>>> removable media (e.g. Window's Media Player). But I think you got off
>>> lightly, the file system could have been damaged beyond repair on the
>>> portable drive, and all data on it lost permanently.
>>>
>>> You should always wait until Windows says that you may safely remove
>>> a drive - else, if Windows will allow it, configure the device for
>>> quick removal by check-marking the appropriate box in it's Device
>>> Manager "Properties" for that drive.
>>>
>>> ==
>>>
>>> Cheers, Tim Meddick, Peckham, London. :-)
>>>
>>>
>>>
>>>
>>> <void.no.spam.com@gmail.com> wrote in message
>>> news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
>>>> Last night I was copying files from a Windows XP laptop to a USB
>>>> external hard drive. Then when I tried to safely remove the hard
>>>> drive, I got an error saying "Generic volume cannot be stopped".
>>>> I've seen this error before and it goes away if I restart Windows,
>>>> but this time I didn't want to restart, so I just put my laptop into
>>>> hibernation, and when I brought it out of hibernation, I was able to
>>>> safely remove the drive.
>>>>
>>>> Then later I copied more files to the USB drive, and when I tried to
>>>> safely remove it again, I got the "Generic volume cannot be stopped"
>>>> error again. So I put the laptop into hibernation again, but when I
>>>> brought the laptop out of hibernation, Windows displayed a dialog
>>>> box saying:
>>>>
>>>> "Delayed Write Failed - Windows was unable to save all the data for
>>>> the file e:\$Mft. The data has been lost. This error may be caused
>>>> by a failure of your computer hardware or network connection. Please
>>>> try to save this file elsewhere."
>>>>
>>>> My USB drive is drive E, and the $Mft apparently stands for master
>>>> file table. That error seems to say that data was definitely lost,
>>>> but when I ran a chkdsk on the drive, I got the following output:
>>>>
>>>> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>>>> The type of the file system is NTFS.
>>>> Volume label is Elements.
>>>>
>>>> CHKDSK is verifying files (stage 1 of 5)...
>>>> File verification completed.
>>>> CHKDSK is verifying indexes (stage 2 of 5)...
>>>> Index verification completed.
>>>> Cleaning up minor inconsistencies on the drive.
>>>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>>>> Cleaning up 12 unused index entries from index $SII of file 9.
>>>> Cleaning up 12 unused index entries from index $SDH of file 9.
>>>> Cleaning up 12 unused security descriptors.
>>>> Fixing mirror copy of the security descriptors data stream.
>>>> Security descriptor verification completed.
>>>> CHKDSK is verifying file data (stage 4 of 5)...
>>>> File data verification completed.
>>>> CHKDSK is verifying free space (stage 5 of 5)...
>>>> Free space verification is complete.
>>>>
>>>> 625131831 KB total disk space.
>>>> 577839972 KB in 1884 files.
>>>> 1024 KB in 437 indexes.
>>>> 0 KB in bad sectors.
>>>> 87383 KB in use by the system.
>>>> 65536 KB occupied by the log file.
>>>> 47203452 KB available on disk.
>>>>
>>>> 4096 bytes in each allocation unit.
>>>> 156282957 total allocation units on disk.
>>>> 11800863 allocation units available on disk.
>>>>
>>>> That chkdsk output seems to indicate the drive only had minor
>>>> inconsistencies and problems with security descriptors. It doesn't
>>>> say anything about data errors. Is it possible that I still lost
>>>> data on the drive?
>
>
Re: Delayed Write Failed - could I have lost data?
Here is an example of what can happen. I use FreeCommander and may be
copying with 2 windows open. One window with the files I want to copy
and the other with USB drive open that I am copying to. After I am done
copying if I do not change the drive in USB window some other drive I
can not get the USB drive to shutdown because it is being accessed. You
did not say how you were copying but if some program is accessing the
USB drive you can not remove it because it is not stopped.
--
<Bill>
Brought to you from Anchorage, Alaska.
void.no.spam.com@gmail.com wrote:
> Last night I was copying files from a Windows XP laptop to a USB
> external hard drive. Then when I tried to safely remove the hard
> drive, I got an error saying "Generic volume cannot be stopped". I've
> seen this error before and it goes away if I restart Windows, but this
> time I didn't want to restart, so I just put my laptop into
> hibernation, and when I brought it out of hibernation, I was able to
> safely remove the drive.
Re: Delayed Write Failed - could I have lost data?
John John MVP wrote
> Rod Speed wrote
>> John John MVP wrote
>>> The data was in the write cache,
>> You dont know that the data he deliberately copied to the USB drive was in the write cache.
> It's in the error message... "Delayed Write Failed".
Nope.
> Delayed writing is write-behind caching.
Yes, but you dont know that its the data he cares about.
>> Its very unlikely that it still was given that he tried to safely
>> remove the hard drive and had the system say that it couldnt do that. That should have flushed the write cache to the
>> drive.
>> Its much more likely that what got lost was what the system was attempting to write to the USB drive at the time the
>> system was hibernated, different data entirely.
>>> it wasn't flushed to the disk so it was lost when the computer was rebooted.
>> You dont know that that was the data that he attempted to write to the USB drive.
>>> On 10/19/2011 2:13 PM, Tim Meddick wrote:
>>>> What the messages basically meant were that your laptop had been
>>>> attempting to save data to the portable drive, but that in your
>>>> trying to "out smart" the warning that the "drive could NOT be
>>>> safely removed at this time" (or similar), there was corruption of
>>>> that data that was being written to the drive - *at that time*.
>>>>
>>>> This data corruption was limited to the file that was being written
>>>> at the time the PC lost power due to the end of the hibernate
>>>> sequence. And also, the MFT would have lost it's validity due to
>>>> the fact it could not be updated after the loss.
>>>>
>>>> The MFT was fixed by running chkdsk, and the data was probably some
>>>> inconsequential file written by a background process that
>>>> enumerates removable media (e.g. Window's Media Player). But I
>>>> think you got off lightly, the file system could have been damaged
>>>> beyond repair on the portable drive, and all data on it lost
>>>> permanently. You should always wait until Windows says that you may safely
>>>> remove a drive - else, if Windows will allow it, configure the
>>>> device for quick removal by check-marking the appropriate box in
>>>> it's Device Manager "Properties" for that drive.
>>>>
>>>> ==
>>>>
>>>> Cheers, Tim Meddick, Peckham, London. :-)
>>>>
>>>>
>>>>
>>>>
>>>> <void.no.spam.com@gmail.com> wrote in message
>>>> news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
>>>>> Last night I was copying files from a Windows XP laptop to a USB
>>>>> external hard drive. Then when I tried to safely remove the hard
>>>>> drive, I got an error saying "Generic volume cannot be stopped".
>>>>> I've seen this error before and it goes away if I restart Windows,
>>>>> but this time I didn't want to restart, so I just put my laptop
>>>>> into hibernation, and when I brought it out of hibernation, I was
>>>>> able to safely remove the drive.
>>>>>
>>>>> Then later I copied more files to the USB drive, and when I tried
>>>>> to safely remove it again, I got the "Generic volume cannot be
>>>>> stopped" error again. So I put the laptop into hibernation again,
>>>>> but when I brought the laptop out of hibernation, Windows
>>>>> displayed a dialog box saying:
>>>>>
>>>>> "Delayed Write Failed - Windows was unable to save all the data
>>>>> for the file e:\$Mft. The data has been lost. This error may be
>>>>> caused by a failure of your computer hardware or network
>>>>> connection. Please try to save this file elsewhere."
>>>>>
>>>>> My USB drive is drive E, and the $Mft apparently stands for master
>>>>> file table. That error seems to say that data was definitely lost,
>>>>> but when I ran a chkdsk on the drive, I got the following output:
>>>>>
>>>>> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>>>>> The type of the file system is NTFS.
>>>>> Volume label is Elements.
>>>>>
>>>>> CHKDSK is verifying files (stage 1 of 5)...
>>>>> File verification completed.
>>>>> CHKDSK is verifying indexes (stage 2 of 5)...
>>>>> Index verification completed.
>>>>> Cleaning up minor inconsistencies on the drive.
>>>>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>>>>> Cleaning up 12 unused index entries from index $SII of file 9.
>>>>> Cleaning up 12 unused index entries from index $SDH of file 9.
>>>>> Cleaning up 12 unused security descriptors.
>>>>> Fixing mirror copy of the security descriptors data stream.
>>>>> Security descriptor verification completed.
>>>>> CHKDSK is verifying file data (stage 4 of 5)...
>>>>> File data verification completed.
>>>>> CHKDSK is verifying free space (stage 5 of 5)...
>>>>> Free space verification is complete.
>>>>>
>>>>> 625131831 KB total disk space.
>>>>> 577839972 KB in 1884 files.
>>>>> 1024 KB in 437 indexes.
>>>>> 0 KB in bad sectors.
>>>>> 87383 KB in use by the system.
>>>>> 65536 KB occupied by the log file.
>>>>> 47203452 KB available on disk.
>>>>>
>>>>> 4096 bytes in each allocation unit.
>>>>> 156282957 total allocation units on disk.
>>>>> 11800863 allocation units available on disk.
>>>>>
>>>>> That chkdsk output seems to indicate the drive only had minor
>>>>> inconsistencies and problems with security descriptors. It doesn't
>>>>> say anything about data errors. Is it possible that I still lost
>>>>> data on the drive?
Re: Delayed Write Failed - could I have lost data?
On 10/19/2011 3:55 PM, Bill Bradshaw wrote:
> Here is an example of what can happen. I use FreeCommander and may be
> copying with 2 windows open. One window with the files I want to copy
> and the other with USB drive open that I am copying to. After I am done
> copying if I do not change the drive in USB window some other drive I
> can not get the USB drive to shutdown because it is being accessed. You
> did not say how you were copying but if some program is accessing the
> USB drive you can not remove it because it is not stopped.
Another notorious one is System Restore which can put a handle that
seems to last forever on USB drives, System Restore should be disabled
on these drives, or rather I should say that System Restore should only
be enabled on the Windows volume and be disabled on all other drives.
Re: Delayed Write Failed - could I have lost data?
On 10/19/2011 4:07 PM, Rod Speed wrote:
> John John MVP wrote
>> Rod Speed wrote
>>> John John MVP wrote
>
>>>> The data was in the write cache,
>
>>> You dont know that the data he deliberately copied to the USB drive was in the write cache.
>
>> It's in the error message... "Delayed Write Failed".
>
> Nope.
>
>> Delayed writing is write-behind caching.
>
> Yes, but you dont know that its the data he cares about.
The OP is the one who knows or should know if data is missing. The
error clearly states that the error was on his USB drive (e:) But, yes,
it could be another process that was trying to write to the disk after
the user's data was successfully flushed to the disk.
>>> Its very unlikely that it still was given that he tried to safely
>>> remove the hard drive and had the system say that it couldnt do that. That should have flushed the write cache to the
>>> drive.
>
>>> Its much more likely that what got lost was what the system was attempting to write to the USB drive at the time the
>>> system was hibernated, different data entirely.
>
>>>> it wasn't flushed to the disk so it was lost when the computer was rebooted.
>
>>> You dont know that that was the data that he attempted to write to the USB drive.
>
>>>> These may be helpful:
>
>>>> http://www.storagereview.com/guide/cacheWrite.html
>>>> http://support.microsoft.com/kb/818788
>>>> http://technet.microsoft.com/en-us/s...rnals/bb897438
>
>
>>>> On 10/19/2011 2:13 PM, Tim Meddick wrote:
>>>>> What the messages basically meant were that your laptop had been
>>>>> attempting to save data to the portable drive, but that in your
>>>>> trying to "out smart" the warning that the "drive could NOT be
>>>>> safely removed at this time" (or similar), there was corruption of
>>>>> that data that was being written to the drive - *at that time*.
>>>>>
>>>>> This data corruption was limited to the file that was being written
>>>>> at the time the PC lost power due to the end of the hibernate
>>>>> sequence. And also, the MFT would have lost it's validity due to
>>>>> the fact it could not be updated after the loss.
>>>>>
>>>>> The MFT was fixed by running chkdsk, and the data was probably some
>>>>> inconsequential file written by a background process that
>>>>> enumerates removable media (e.g. Window's Media Player). But I
>>>>> think you got off lightly, the file system could have been damaged
>>>>> beyond repair on the portable drive, and all data on it lost
>>>>> permanently. You should always wait until Windows says that you may safely
>>>>> remove a drive - else, if Windows will allow it, configure the
>>>>> device for quick removal by check-marking the appropriate box in
>>>>> it's Device Manager "Properties" for that drive.
>>>>>
>>>>> ==
>>>>>
>>>>> Cheers, Tim Meddick, Peckham, London. :-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <void.no.spam.com@gmail.com> wrote in message
>>>>> news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
>>>>>> Last night I was copying files from a Windows XP laptop to a USB
>>>>>> external hard drive. Then when I tried to safely remove the hard
>>>>>> drive, I got an error saying "Generic volume cannot be stopped".
>>>>>> I've seen this error before and it goes away if I restart Windows,
>>>>>> but this time I didn't want to restart, so I just put my laptop
>>>>>> into hibernation, and when I brought it out of hibernation, I was
>>>>>> able to safely remove the drive.
>>>>>>
>>>>>> Then later I copied more files to the USB drive, and when I tried
>>>>>> to safely remove it again, I got the "Generic volume cannot be
>>>>>> stopped" error again. So I put the laptop into hibernation again,
>>>>>> but when I brought the laptop out of hibernation, Windows
>>>>>> displayed a dialog box saying:
>>>>>>
>>>>>> "Delayed Write Failed - Windows was unable to save all the data
>>>>>> for the file e:\$Mft. The data has been lost. This error may be
>>>>>> caused by a failure of your computer hardware or network
>>>>>> connection. Please try to save this file elsewhere."
>>>>>>
>>>>>> My USB drive is drive E, and the $Mft apparently stands for master
>>>>>> file table. That error seems to say that data was definitely lost,
>>>>>> but when I ran a chkdsk on the drive, I got the following output:
>>>>>>
>>>>>> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>>>>>> The type of the file system is NTFS.
>>>>>> Volume label is Elements.
>>>>>>
>>>>>> CHKDSK is verifying files (stage 1 of 5)...
>>>>>> File verification completed.
>>>>>> CHKDSK is verifying indexes (stage 2 of 5)...
>>>>>> Index verification completed.
>>>>>> Cleaning up minor inconsistencies on the drive.
>>>>>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>>>>>> Cleaning up 12 unused index entries from index $SII of file 9.
>>>>>> Cleaning up 12 unused index entries from index $SDH of file 9.
>>>>>> Cleaning up 12 unused security descriptors.
>>>>>> Fixing mirror copy of the security descriptors data stream.
>>>>>> Security descriptor verification completed.
>>>>>> CHKDSK is verifying file data (stage 4 of 5)...
>>>>>> File data verification completed.
>>>>>> CHKDSK is verifying free space (stage 5 of 5)...
>>>>>> Free space verification is complete.
>>>>>>
>>>>>> 625131831 KB total disk space.
>>>>>> 577839972 KB in 1884 files.
>>>>>> 1024 KB in 437 indexes.
>>>>>> 0 KB in bad sectors.
>>>>>> 87383 KB in use by the system.
>>>>>> 65536 KB occupied by the log file.
>>>>>> 47203452 KB available on disk.
>>>>>>
>>>>>> 4096 bytes in each allocation unit.
>>>>>> 156282957 total allocation units on disk.
>>>>>> 11800863 allocation units available on disk.
>>>>>>
>>>>>> That chkdsk output seems to indicate the drive only had minor
>>>>>> inconsistencies and problems with security descriptors. It doesn't
>>>>>> say anything about data errors. Is it possible that I still lost
>>>>>> data on the drive?
>
>
Re: Delayed Write Failed - could I have lost data?
John John MVP wrote
> Rod Speed wrote
>> John John MVP wrote
>>> Rod Speed wrote
>>>> John John MVP wrote
>>>>> The data was in the write cache,
>>>> You dont know that the data he deliberately copied to the USB drive was in the write cache.
>>> It's in the error message... "Delayed Write Failed".
>> Nope.
>>> Delayed writing is write-behind caching.
>> Yes, but you dont know that its the data he cares about.
> The OP is the one who knows or should know if data is missing.
Yes, and its unlikely to have any missing given the detail he spelt out.
> The error clearly states that the error was on his USB drive (e:) But, yes, it could be another process that was
> trying to write to the disk after the user's data was successfully flushed to the disk.
And thats much more likely given the detail he spelt out.
The first attempt to safely remove the drive should
have seen the write cache flushed to the drive.
>>>> Its very unlikely that it still was given that he tried to safely
>>>> remove the hard drive and had the system say that it couldnt do that. That should have flushed the write cache to
>>>> the drive.
>>>> Its much more likely that what got lost was what the system was
>>>> attempting to write to the USB drive at the time the system was
>>>> hibernated, different data entirely.
>>>>> it wasn't flushed to the disk so it was lost when the computer was rebooted.
>>>> You dont know that that was the data that he attempted to write to the USB drive.
>>>>> On 10/19/2011 2:13 PM, Tim Meddick wrote:
>>>>>> What the messages basically meant were that your laptop had been
>>>>>> attempting to save data to the portable drive, but that in your
>>>>>> trying to "out smart" the warning that the "drive could NOT be
>>>>>> safely removed at this time" (or similar), there was corruption
>>>>>> of that data that was being written to the drive - *at that time*.
>>>>>>
>>>>>> This data corruption was limited to the file that was being
>>>>>> written at the time the PC lost power due to the end of the hibernate
>>>>>> sequence. And also, the MFT would have lost it's validity due to
>>>>>> the fact it could not be updated after the loss.
>>>>>>
>>>>>> The MFT was fixed by running chkdsk, and the data was probably
>>>>>> some inconsequential file written by a background process that
>>>>>> enumerates removable media (e.g. Window's Media Player). But I
>>>>>> think you got off lightly, the file system could have been
>>>>>> damaged beyond repair on the portable drive, and all data on it lost
>>>>>> permanently. You should always wait until Windows says that you
>>>>>> may safely remove a drive - else, if Windows will allow it,
>>>>>> configure the device for quick removal by check-marking the appropriate box in
>>>>>> it's Device Manager "Properties" for that drive.
>>>>>>
>>>>>> ==
>>>>>>
>>>>>> Cheers, Tim Meddick, Peckham, London. :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> <void.no.spam.com@gmail.com> wrote in message
>>>>>> news:2f9ce058-7bf9-45ce-b7dd-5dad1b98e98d@g25g2000yqh.googlegroups.com...
>>>>>>> Last night I was copying files from a Windows XP laptop to a USB
>>>>>>> external hard drive. Then when I tried to safely remove the hard
>>>>>>> drive, I got an error saying "Generic volume cannot be stopped".
>>>>>>> I've seen this error before and it goes away if I restart
>>>>>>> Windows, but this time I didn't want to restart, so I just put
>>>>>>> my laptop into hibernation, and when I brought it out of
>>>>>>> hibernation, I was able to safely remove the drive.
>>>>>>>
>>>>>>> Then later I copied more files to the USB drive, and when I
>>>>>>> tried to safely remove it again, I got the "Generic volume
>>>>>>> cannot be stopped" error again. So I put the laptop into
>>>>>>> hibernation again, but when I brought the laptop out of
>>>>>>> hibernation, Windows displayed a dialog box saying:
>>>>>>>
>>>>>>> "Delayed Write Failed - Windows was unable to save all the data
>>>>>>> for the file e:\$Mft. The data has been lost. This error may be
>>>>>>> caused by a failure of your computer hardware or network
>>>>>>> connection. Please try to save this file elsewhere."
>>>>>>>
>>>>>>> My USB drive is drive E, and the $Mft apparently stands for
>>>>>>> master file table. That error seems to say that data was
>>>>>>> definitely lost, but when I ran a chkdsk on the drive, I got
>>>>>>> the following output: C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>>>>>>> The type of the file system is NTFS.
>>>>>>> Volume label is Elements.
>>>>>>>
>>>>>>> CHKDSK is verifying files (stage 1 of 5)...
>>>>>>> File verification completed.
>>>>>>> CHKDSK is verifying indexes (stage 2 of 5)...
>>>>>>> Index verification completed.
>>>>>>> Cleaning up minor inconsistencies on the drive.
>>>>>>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>>>>>>> Cleaning up 12 unused index entries from index $SII of file 9.
>>>>>>> Cleaning up 12 unused index entries from index $SDH of file 9.
>>>>>>> Cleaning up 12 unused security descriptors.
>>>>>>> Fixing mirror copy of the security descriptors data stream.
>>>>>>> Security descriptor verification completed.
>>>>>>> CHKDSK is verifying file data (stage 4 of 5)...
>>>>>>> File data verification completed.
>>>>>>> CHKDSK is verifying free space (stage 5 of 5)...
>>>>>>> Free space verification is complete.
>>>>>>>
>>>>>>> 625131831 KB total disk space.
>>>>>>> 577839972 KB in 1884 files.
>>>>>>> 1024 KB in 437 indexes.
>>>>>>> 0 KB in bad sectors.
>>>>>>> 87383 KB in use by the system.
>>>>>>> 65536 KB occupied by the log file.
>>>>>>> 47203452 KB available on disk.
>>>>>>>
>>>>>>> 4096 bytes in each allocation unit.
>>>>>>> 156282957 total allocation units on disk.
>>>>>>> 11800863 allocation units available on disk.
>>>>>>>
>>>>>>> That chkdsk output seems to indicate the drive only had minor
>>>>>>> inconsistencies and problems with security descriptors. It
>>>>>>> doesn't say anything about data errors. Is it possible that I
>>>>>>> still lost data on the drive?
Re: Delayed Write Failed - could I have lost data?
On 10/19/2011 10:45 AM, void.no.spam.com@gmail.com wrote:
> Last night I was copying files from a Windows XP laptop to a USB
> external hard drive. Then when I tried to safely remove the hard
> drive, I got an error saying "Generic volume cannot be stopped". I've
> seen this error before and it goes away if I restart Windows, but this
> time I didn't want to restart, so I just put my laptop into
> hibernation, and when I brought it out of hibernation, I was able to
> safely remove the drive.
>
> Then later I copied more files to the USB drive, and when I tried to
> safely remove it again, I got the "Generic volume cannot be stopped"
> error again. So I put the laptop into hibernation again, but when I
> brought the laptop out of hibernation, Windows displayed a dialog box
> saying:
>
> "Delayed Write Failed - Windows was unable to save all the data for
> the fi
<snip>
erification completeavailable on disk.
>
> That chkdsk output seems to indicate the drive only had minor
> inconsistencies and problems with security descriptors. It doesn't say
> anything about data errors. Is it possible that I still lost data on
> the drive?
Why ask here
look on the drive and see if all of your data are there
Re: Delayed Write Failed - could I have lost data?
Short answer: You lost data and you will lose more
data until you find out what is wrong and correct that
problem.
Arno
In comp.sys.ibm.pc.hardware.storage void.no.spam.com@gmail.com <void.no.spam.com@gmail.com> wrote:
> Last night I was copying files from a Windows XP laptop to a USB
> external hard drive. Then when I tried to safely remove the hard
> drive, I got an error saying "Generic volume cannot be stopped". I've
> seen this error before and it goes away if I restart Windows, but this
> time I didn't want to restart, so I just put my laptop into
> hibernation, and when I brought it out of hibernation, I was able to
> safely remove the drive.
> Then later I copied more files to the USB drive, and when I tried to
> safely remove it again, I got the "Generic volume cannot be stopped"
> error again. So I put the laptop into hibernation again, but when I
> brought the laptop out of hibernation, Windows displayed a dialog box
> saying:
> "Delayed Write Failed - Windows was unable to save all the data for
> the file e:\$Mft. The data has been lost. This error may be caused
> by a failure of your computer hardware or network connection. Please
> try to save this file elsewhere."
> My USB drive is drive E, and the $Mft apparently stands for master
> file table. That error seems to say that data was definitely lost, but
> when I ran a chkdsk on the drive, I got the following output:
> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
> The type of the file system is NTFS.
> Volume label is Elements.
> CHKDSK is verifying files (stage 1 of 5)...
> File verification completed.
> CHKDSK is verifying indexes (stage 2 of 5)...
> Index verification completed.
> Cleaning up minor inconsistencies on the drive.
> CHKDSK is verifying security descriptors (stage 3 of 5)...
> Cleaning up 12 unused index entries from index $SII of file 9.
> Cleaning up 12 unused index entries from index $SDH of file 9.
> Cleaning up 12 unused security descriptors.
> Fixing mirror copy of the security descriptors data stream.
> Security descriptor verification completed.
> CHKDSK is verifying file data (stage 4 of 5)...
> File data verification completed.
> CHKDSK is verifying free space (stage 5 of 5)...
> Free space verification is complete.
> 625131831 KB total disk space.
> 577839972 KB in 1884 files.
> 1024 KB in 437 indexes.
> 0 KB in bad sectors.
> 87383 KB in use by the system.
> 65536 KB occupied by the log file.
> 47203452 KB available on disk.
> 4096 bytes in each allocation unit.
> 156282957 total allocation units on disk.
> 11800863 allocation units available on disk.
> That chkdsk output seems to indicate the drive only had minor
> inconsistencies and problems with security descriptors. It doesn't say
> anything about data errors. Is it possible that I still lost data on
> the drive?
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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
Re: Delayed Write Failed - could I have lost data?
On Oct 19, 10:13*am, "Tim Meddick" <timmedd...@o2.co.uk> wrote:
> What the messages basically meant were that your laptop had been attempting
> to save data to the portable drive, but that in your trying to "out smart"
> the warning that the "drive could NOT be safely *removed at this time" (or
> similar), there was corruption of that data that was being written to the
> drive - *at that time*.
I thought that hibernation would force anything in the write buffer to
get written to the drive. Seems like it should - isn't hibernation
pretty much like the power off state, so all buffers should get
flushed just before entering hibernation. Also, what if I wasn't
trying to "out smart" the warning? I frequently close the lid on my
laptop just before going to bed (and my laptop is configured to
hibernate Windows if the lid is closed). So what if I had moved some
files to the USB drive late at night and then closed the lid? I might
see the "delayed write error" when I bring it out of hibernation the
next day - that should not happen.
> This data corruption was limited to the file that was being written at the
> time the PC lost power due to the end of the hibernate sequence. *And also,
> the MFT would have lost it's validity due to the fact it could not be
> updated after the loss.
I'm curious how large the Windows write buffer is - just wondering if
any possible corruption could be limited to a partial file, or
multiple files if the buffer is large enough. Fortunately I know the
last several files I moved over to the drive - most of them are files
I downloaded off the internet, so I can redownload those just in
case. But the last file I moved over was a text file I had been
editing, and it appears to be OK... unless the corruption has
manifested itself in truncating the end of the file - I don't quite
remember what was at the end of the file.
Re: Delayed Write Failed - could I have lost data?
Just ignore this fool. He doesnt have a ****ing clue about Win.
Arno wrote:
> Short answer: You lost data and you will lose more
> data until you find out what is wrong and correct that
> problem.
>
> Arno
>
>
> In comp.sys.ibm.pc.hardware.storage void.no.spam.com@gmail.com
> <void.no.spam.com@gmail.com> wrote:
>> Last night I was copying files from a Windows XP laptop to a USB
>> external hard drive. Then when I tried to safely remove the hard
>> drive, I got an error saying "Generic volume cannot be stopped". I've
>> seen this error before and it goes away if I restart Windows, but
>> this time I didn't want to restart, so I just put my laptop into
>> hibernation, and when I brought it out of hibernation, I was able to
>> safely remove the drive.
>
>> Then later I copied more files to the USB drive, and when I tried to
>> safely remove it again, I got the "Generic volume cannot be stopped"
>> error again. So I put the laptop into hibernation again, but when I
>> brought the laptop out of hibernation, Windows displayed a dialog box
>> saying:
>
>> "Delayed Write Failed - Windows was unable to save all the data for
>> the file e:\$Mft. The data has been lost. This error may be caused
>> by a failure of your computer hardware or network connection. Please
>> try to save this file elsewhere."
>
>> My USB drive is drive E, and the $Mft apparently stands for master
>> file table. That error seems to say that data was definitely lost,
>> but when I ran a chkdsk on the drive, I got the following output:
>
>> C:\Documents and Settings\Administrator>chkdsk e: /f /v /r
>> The type of the file system is NTFS.
>> Volume label is Elements.
>
>> CHKDSK is verifying files (stage 1 of 5)...
>> File verification completed.
>> CHKDSK is verifying indexes (stage 2 of 5)...
>> Index verification completed.
>> Cleaning up minor inconsistencies on the drive.
>> CHKDSK is verifying security descriptors (stage 3 of 5)...
>> Cleaning up 12 unused index entries from index $SII of file 9.
>> Cleaning up 12 unused index entries from index $SDH of file 9.
>> Cleaning up 12 unused security descriptors.
>> Fixing mirror copy of the security descriptors data stream.
>> Security descriptor verification completed.
>> CHKDSK is verifying file data (stage 4 of 5)...
>> File data verification completed.
>> CHKDSK is verifying free space (stage 5 of 5)...
>> Free space verification is complete.
>
>> 625131831 KB total disk space.
>> 577839972 KB in 1884 files.
>> 1024 KB in 437 indexes.
>> 0 KB in bad sectors.
>> 87383 KB in use by the system.
>> 65536 KB occupied by the log file.
>> 47203452 KB available on disk.
>
>> 4096 bytes in each allocation unit.
>> 156282957 total allocation units on disk.
>> 11800863 allocation units available on disk.
>
>> That chkdsk output seems to indicate the drive only had minor
>> inconsistencies and problems with security descriptors. It doesn't
>> say anything about data errors. Is it possible that I still lost
>> data on the drive?
Re: Delayed Write Failed - could I have lost data?
On Oct 19, 10:46*am, "Rod Speed" <rod.speed....@gmail.com> wrote:
> > That chkdsk output seems to indicate the drive only had minor
> > inconsistencies and problems with security descriptors. It doesn't say
> > anything about data errors. Is it possible that I still lost data on the drive?
>
> Not if the files you copied are visible.
You mean it isn't possible for a file to still exist and have a few
corrupted or missing bits - it's either there and completely intact,
or it's corrupted and totally gone?
Re: Delayed Write Failed - could I have lost data?
On Oct 19, 10:46*am, "Rod Speed" <rod.speed....@gmail.com> wrote:
> > That chkdsk output seems to indicate the drive only had minor
> > inconsistencies and problems with security descriptors. It doesn't say
> > anything about data errors. Is it possible that I still lost data on the drive?
>
> Not if the files you copied are visible.
You mean it's not possible for a file to still be there and have a few
corrupted/missing bits - it's either there and completely intact, or
corrupted and totally gone?
>>> That chkdsk output seems to indicate the drive only had minor inconsistencies
>>> and problems with security descriptors. It doesn't say anything about data
>>> errors. Is it possible that I still lost data on the drive?
>> Not if the files you copied are visible.
> You mean it isn't possible for a file to still exist and have a few corrupted or missing bits
Not if chkdsk doesnt whine about that file.
> - it's either there and completely intact, or it's corrupted and totally gone?
You can see the file in a state that chkdsk complains about and normally
attempts to fix if your system is configured to fix problems auto.
>> What the messages basically meant were that your laptop had
>> been attempting to save data to the portable drive, but that in
>> your trying to "out smart" the warning that the "drive could NOT
>> be safely removed at this time" (or similar), there was corruption
>> of that data that was being written to the drive - *at that time*.
> I thought that hibernation would force anything in the write buffer to
> get written to the drive.
Yes, it should do.
> Seems like it should - isn't hibernation pretty much like the power off state,
Yes.
> so all buffers should get flushed just before entering hibernation.
Yes.
> Also, what if I wasn't trying to "out smart" the warning? I frequently
> close the lid on my laptop just before going to bed (and my laptop is
> configured to hibernate Windows if the lid is closed).
Yeah, me too. Tho I dont use mine fulltime, I use a desktop full time
and close the lid on the laptop when I wont be using it for a while.
> So what if I had moved some files to the USB
> drive late at night and then closed the lid?
It should be fine.
> I might see the "delayed write error" when I bring it out
> of hibernation the next day - that should not happen.
Yes, but one of the downsides with using Win like that, setting it to
hibernate when you shut the lid, is that eventually the system will
\need a full reboot when its got its tiny little brain rather scrambled.
Thats likely what happened with your delayed write error message
and maybe with the inability to safely remove the USB drive too.
>> This data corruption was limited to the file that was being
>> written at the time the PC lost power due to the end of the
>> hibernate sequence. And also, the MFT would have lost it's
>> validity due to the fact it could not be updated after the loss.
> I'm curious how large the Windows write buffer is
Thats configurable.
> - just wondering if any possible corruption could be limited
> to a partial file, or multiple files if the buffer is large enough.
Yes it can and it doesnt need to be that large, it isnt that
uncommon to have more than one file being written at the
same time and you can get a delayed write failure in that
situation, usually on a mains failure with a desktop etc.
Thats one area where laptops handle that situation much better auto.
> Fortunately I know the last several files I moved over to the drive
> - most of them are files I downloaded off the internet, so I can
> redownload those just in case. But the last file I moved over
> was a text file I had been editing, and it appears to be OK...
Yeah, all the evidence you reported supports the idea that the
copy to the USB drive worked fine and that the only problem
was some glitch with the hibernate that saw the system shut
down before the last of what was written to the drive had got
out to the drive. That was in fact a bug in XP initially, it could
do that at times, not wait long enough after the last of the
updating of stuff to the drives on the file system status had
been written to the drives before actually shutting down, so
you could see a delayed write failure at times. Just status info
like whether the drive was 'dirty' or not and stuff like that, not
stuff that the user was actually deliberately writing to the drive.
The dirty status is what sees the drive do an automatic chkdsk
on startup when the system hasnt been shut down properly,
usually due to a mains flick on a desktop system etc or someone
just turning it off at the wall instead of shutting down properly.
> unless the corruption has manifested itself in truncating the end
> of the file - I don't quite remember what was at the end of the file.
Its very likely fine and all you saw was a hibernate glitch.
Re: Delayed Write Failed - could I have lost data?
In comp.sys.ibm.pc.hardware.storage void.no.spam.com@gmail.com <void.no.spam.com@gmail.com> wrote:
> On Oct 19, 10:13?am, "Tim Meddick" <timmedd...@o2.co.uk> wrote:
>> What the messages basically meant were that your laptop had been attempting
>> to save data to the portable drive, but that in your trying to "out smart"
>> the warning that the "drive could NOT be safely ?removed at this time" (or
>> similar), there was corruption of that data that was being written to the
>> drive - *at that time*.
> I thought that hibernation would force anything in the write buffer to
> get written to the drive.
You cannot force data on a drive that gives you an error.
One way around that is to also store the buffer-state and contents
in the hibernation device. But that would make things slow, so
I guess MS decided against it. This may also be a valid
reson not to use hibernation at all.
> Seems like it should - isn't hibernation
> pretty much like the power off state, so all buffers should get
> flushed just before entering hibernation. Also, what if I wasn't
> trying to "out smart" the warning? I frequently close the lid on my
> laptop just before going to bed (and my laptop is configured to
> hibernate Windows if the lid is closed). So what if I had moved some
> files to the USB drive late at night and then closed the lid? I might
> see the "delayed write error" when I bring it out of hibernation the
> next day - that should not happen.
Indeed. But if there is a storage problem it _will_ happen.
One of the reasons why hibernation is actually not that
good a thing, at least with this treatment of the filesystem
buffer.
>> This data corruption was limited to the file that was being written at the
>> time the PC lost power due to the end of the hibernate sequence. ?And also,
>> the MFT would have lost it's validity due to the fact it could not be
>> updated after the loss.
> I'm curious how large the Windows write buffer is - just wondering if
> any possible corruption could be limited to a partial file, or
> multiple files if the buffer is large enough.
Basically all available memory as a worst-case.
> Fortunately I know the
> last several files I moved over to the drive - most of them are files
> I downloaded off the internet, so I can redownload those just in
> case. But the last file I moved over was a text file I had been
> editing, and it appears to be OK... unless the corruption has
> manifested itself in truncating the end of the file - I don't quite
> remember what was at the end of the file.
Well, one way around this is to do a clean shutdown instead of
that half-baked "hibernation". Another is to do a safe remove
of the USB storage.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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
Re: Delayed Write Failed - could I have lost data?
In comp.sys.ibm.pc.hardware.storage void.no.spam.com@gmail.com <void.no.spam.com@gmail.com> wrote:
> On Oct 19, 10:46?am, "Rod Speed" <rod.speed....@gmail.com> wrote:
>> > That chkdsk output seems to indicate the drive only had minor
>> > inconsistencies and problems with security descriptors. It doesn't say
>> > anything about data errors. Is it possible that I still lost data on the drive?
>>
>> Not if the files you copied are visible.
> You mean it isn't possible for a file to still exist and have a few
> corrupted or missing bits - it's either there and completely intact,
> or it's corrupted and totally gone?
Usually you can get
1) missing file
2) present file partial data (anuthing between 0 Bytes there and the last
byte missing)
3) full data.
What you typically cannot get is corrypted data. It either is
there and correct or (partially) missing. Of course, if you edited a
file, the edits can be partially missing either in cronological order
or in sequence from the start of the file, depending on the editors
update strategy.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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
Re: Delayed Write Failed - could I have lost data?
In comp.sys.ibm.pc.hardware.storage Tom Del Rosso <td_03@verizon.net.invalid> wrote:
> John John MVP wrote:
>> The data was in the write cache, it wasn't flushed to the disk so it
>> was lost when the computer was rebooted.
> Why the hell doesn't Windows flush the write cache when it goes into
> hibernation?
While I think the Windows is (still) at best a toy, in all fairness
if the disk refuses to take data, flushing the write-buffer (no, it
is not a cache) is impossible.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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
Re: Delayed Write Failed - could I have lost data?
Tom Del Rosso wrote
> John John MVP wrote
>> The data was in the write cache, it wasn't flushed to the disk so it was lost when the computer was rebooted.
> Why the hell doesn't Windows flush the write cache when it goes into hibernation?
It does. It can also write some status stuff to the drive before hibernating
and can shut down too quickly before it gets written to the drive, particularly
if there is some delay writing that status stuff to the druve.
Re: Delayed Write Failed - could I have lost data?
Arno wrote:
> In comp.sys.ibm.pc.hardware.storage Tom Del Rosso
> <td_03@verizon.net.invalid> wrote:
>
> > John John MVP wrote:
> > > The data was in the write cache, it wasn't flushed to the disk so
> > > it was lost when the computer was rebooted.
>
> > Why the hell doesn't Windows flush the write cache when it goes into
> > hibernation?
>
> While I think the Windows is (still) at best a toy, in all fairness
> if the disk refuses to take data, flushing the write-buffer (no, it
> is not a cache) is impossible.
Does the disk refuse because it has to spin up first? Windows should be
able to delay the shutdown in that case.
--
Reply in group, but if emailing add one more
zero, and remove the last word.
Re: Delayed Write Failed - could I have lost data?
On 10/25/2011 11:39 PM PT, Tom Del Rosso typed:
>> The data was in the write cache, it wasn't flushed to the disk so it
>> was lost when the computer was rebooted.
>
> Why the hell doesn't Windows flush the write cache when it goes into
> hibernation?
Why the frak do we have write cache? Is it for speed?
--
"Ants can lift up to 50 times their own weight. And your monitor is
missing. Time to bring out the bugspray." --BBspot's Geek Horoscopes
(2/28/2003)
/\___/\ Ant @ http://antfarm.ma.cx (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / If crediting, then use Ant nickname and AQFL URL/link.
( ) If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.
Re: Delayed Write Failed - could I have lost data?
Rod, looks like you're right about the data being fine and it was just
a weird hibernation glitch. Since I had gotten a "delayed write
failed" error, I just assumed that the drive's policy was set to
"Optimize for performance". Then right after I started this thread, I
went out of town for over a week with my work laptop, so I couldn't
check my personal laptop. Now I'm finally home and was able to check
on what the policy was set to - it is set to "Optimize for quick
removal", which means the data must have been written correctly.
> Rod, looks like you're right about the data being fine and it was
> just a weird hibernation glitch. Since I had gotten a "delayed
> write failed" error, I just assumed that the drive's policy was set to
> "Optimize for performance". Then right after I started this thread, I
> went out of town for over a week with my work laptop, so I couldn't
> check my personal laptop. Now I'm finally home and was able to
> check on what the policy was set to - it is set to "Optimize for quick
> removal", which means the data must have been written correctly.
Delayed Write Failed - could I have lost data? 
Linear Mode
