Re: copying files with bad CRCs
- From: "Folkert Rienstra" <see_reply-to@xxxxxxxx>
- Date: Thu, 29 Jun 2006 00:56:57 +0200
"Arno Wagner" <me@xxxxxxxxxxx> wrote in message news:4gg908F1mbu56U1@xxxxxxxxxxxxxx
Previously yawnmoth <terra1024@xxxxxxxxx> wrote:
Say I wanted to copy a *.avi video file (xvid encoded; it's currently
on a hard drive)) but was told (by Windows XP) I couldn't because it
had a bad CRC. Is there a way I could sorta just copy it in spite of
the bad CRC?
The reason I ask is because xvid (and MPEG1/2/4, in general) is a
rather resiliant format. A single corrupt byte may just mean that one
frame is bad. If every 20th frame is a keyframes (ie. i-frames, or
whatever), this means that only 20 - (frame position) % 20 frames are
bad. If there are 100,000+ frames, having less then 20 bad frames is
fairly insignificant.
Agreed. Matches my experience.
Probably not, given the solution you come up with.
Yet it's significant enough for Windows to deny you access to the whole file?
The problem here is that the underlying OS functionality is not pre-
pared to deal with bad CRCs in any way. It can only report the error.
Actually it will do retries and unless the interface is completely dead
next commands will just succeed.
So, anyway, I think, in some cases, Windows' seeming refusal to let you
do anything with corrupt files is inappropriate. Is there any work-
around that I'm not aware of?
For the defective sector itself, there is not.
Nonsense. CRC errors are not sector errors.
The disk does not deliver it to the OS.
So, now assuming ECC errors, (not CRC errors):
Depends on what IDE command is issued to the drive.
Some read commands stop at the sector in error but *do* deliver the faulty
sector data in the receive buffer.
If the app reads the buffer despite of the error the (faulty) data will be
there. Not clear though whether the OS will allow that (or facilitate it).
Some data-recovery siftware may still be able to do a raw read or the like,
but I have no experience with that.
For the rest of the file, there is.
The problem really is not with Windoes, but with the application(Which in this case is 'Windoes' Explorer)
that stops to read when encountering a read error.
The problem is with the IDE command that is aborted up to the sector
in error, by the disk. The actual IDE command is issued by the OS.
If the OS doesn't allow any other options than to read a file without
error or not at all then obviously that's not the application's fault.
And why the hell would an user application want to read faulty data?
There is a tool called dd_rescue on Linux, that can serve as an example.
It will skip a 512 byte sector (or other size if set on the commandline)
if it reads bad and continue with the next sector.
He wants the bad sector as well, bad and all.
It does this on the normal file-access layer
But obviously with a different from 'normal' or usual access pattern.
and the approach should work with Windows also.
However, I think that you will either have to programm this yourself
or use Linux dd_rescue to copy the file.
The file isn't resqued. It will be a damaged file with missing data.
Should not be too difficult to write if you have some programming experience.
Then program it to read the bad sector as well, instead of skipping it.
.
Arno
- References:
- copying files with bad CRCs
- From: yawnmoth
- Re: copying files with bad CRCs
- From: Arno Wagner
- copying files with bad CRCs
- Prev by Date: Re: Western Digital Settlement Approved
- Next by Date: Re: Western Digital Settlement Approved
- Previous by thread: Re: copying files with bad CRCs
- Next by thread: Re: copying files with bad CRCs
- Index(es):
Relevant Pages
|
