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. Yet it's significant enough for Windows to deny
you access to the whole file?

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?

Thanks!

yawnmoth <terra1024@yahoo.com> wrote:
Trouble is that Win is saying you have a bad
sector in that file. Thats quite a few bytes, 512

Its not denying you access, thats what the Abort Retry Fail is for.

Spinrite claims to try hard to get what is obtainable from the file.

Previously yawnmoth <terra1024@yahoo.com> wrote:
Agreed. Matches my experience.

The problem here is that the underlying OS functionality
is not prepared to deal with bad CRCs in any way. It can only
report the error.

For the defective sector itself, there is not. The disk does not
deliver it to the OS. 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
that stops to read when encountering a read error.

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. It does this on the normal file-access layer 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. Should not be too difficult
to write if you have some programming experience.

Arno

"yawnmoth" <terra1024@yahoo.com> wrote in
news:1151522531.450043.295570@i40g2000cwc.googlegr oups.com:

I've no direct experience of it, but it is claimed to do what you
need...

http://www.roadkil.net/unstopcp.html

"Product Description

Recovers files from disks with physical damage. Allows you to copy
files from disks with problems such as bad sectors, scratches or
that just give errors when reading data. The program will attempt
to recover every readable piece of a file and put the pieces
together. Using this method most types of files can be made useable
even if some parts were not recoverable in the end. "

"Arno Wagner" <me@privacy.net> wrote in message news:4gg908F1mbu56U1@individual.net
Probably not, given the solution you come up with.

Actually it will do retries and unless the interface is completely dead
next commands will just succeed.

Nonsense. CRC errors are not sector errors.

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).


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?

He wants the bad sector as well, bad and all.

But obviously with a different from 'normal' or usual access pattern.

The file isn't resqued. It will be a damaged file with missing data.

Then program it to read the bad sector as well, instead of skipping it.

Rod Speed wrote:
mean that all the bytes are corrupted, does it? I mean, wouldn't just
one of those bytes being corrupted result in a CRC mismatch?

Previously yawnmoth <terra1024@yahoo.com> wrote:

A single bit would be enough. However since HDDs do not really use
CRC but a more elaboraate ECC, you will likely get some real
corruption. If you can get the disk to give the raw data to you.

In SCSI there is a command to read the raw data. There might be one
in ATA too. Might mean that you have to do some programming
yourself. But the easiest approach is to try to do without the
defective sector.

Arno

yawnmoth <terra1024@yahoo.com> wrote
Sure, I meant that mostly when the sector isnt readable,
you basically lose all 512 bytes, not just a few bytes.

ECC, yes. But what normally happens is that you
dont get anything much of the bytes you should get.

"yawnmoth" <terra1024@yahoo.com> wrote in message news:1151547089.513910.150880@x69g2000cwx.googlegr oups.com
ECC, not CRC.

A sufficient number of them that the contents can't be repaired by the ECC.

The problem is that Windows won't give them to you, all 512 of them.

In news:1151547089.513910.150880@x69g2000cwx.googlegr oups.com yawnmoth
typed:
Hi "yawnmoth" (who what so ever named You so?)
A CRC does no longer looks like a HW fault but may also result
from a SW CRC checksum.

No, from a HW point of view every 512 bytes are checked (ECC).
From a SW point of view the comlete file is checked.
But both are regaining You from reading the data correctly.

Any of CRC or ECC error might prevent You from reading the data.
Then You would have to reconstruct that data (rewrite or rebuild).
Some extern utilities may be able to read these data.
But this matter has too much culprits to give You a single solution.
Horst

In news:4ggug8F1n36qlU1@individual.net Rod Speed typed:
Hi Rod, not only even that but a complete cluster,
which is normally 4096 bytes (by NTFS).
But ECC might recover some of the 8 sectors involved.
Horst

Horst Franke <nospam@invalid> wrote
The ECC applys at the sector level, not the cluster level.

And you wont necessarily lose an entire cluster on a single bad sector either.

In news:4grvucF1oprg5U2@individual.net Rod Speed typed:

readable then the complete cluster will be treated as not readable.
Horst

Horst Franke <nospam@invalid> wrote:
Wrong as far as the data is concerned.

www.cnwrecovery.com

The program will continue reading even with CRC errors. Blocks of
fixed data will be inserted, but you maybe able to recover your file.
The beta program is still free

Michael (CnW Recovery)

<mscotgrove@aol.com> wrote in message news:1152018902.856820.149710@75g2000cwc.googlegro ups.com
But that's the point, you don't.
You may be able to play the file from where it is by sofware that uses
the streaming command set (if the drive/driver supports it) and then
capture it from there.