Persistent compare error...

[rtestardi]

I am running Retrospect 5.6 against both a Seagate USB tape drive and a Sony CD-RW.

I get persistent compare errors on exactly one file, every time I do the backup. Same

file, same offset.

 

10/29/2003 6:04:20 PM: Comparing Drive C (C:)

File "C:\Pictures\2003-08\2003_08_08\122-2238_IMG.JPG": didn't compare at offset 118 in stream ""

 

I know this file is perfectly good, and the source disk is perfectly good. Obviously this can't

be related to the destination media, since I use multiple pieces of different types of media

and get the exact same behavior.

 

It is as if either the data pattern or the pathname is causing Retrospect to simply goof...

Everything else is fine.

 

Does anyone know why Retrospect might not be able to process one particular file, at one

particular offset???

 

Please -- I understand what a compare error is... I'm asking for why Retrospect should not

be able to process one particular file... I don't have hardware problems.

 

Thanks for any help.

 

-- Rich

[natew]

Hi

 

Do you still get the error if you copy the file to another disk? How about moving it to another folder?

 

Nate

[rtestardi]

Hi Nate,

 

Great suggestion! Here's what I did:

 

1) copy the suspect file from \pictures to \temp, with the same name and contents

2) run the backup again -- the file in \temp succeeded and the one in \pictures failed

3) exchange the two files (using renames)

4) run the backup again -- the one in \pictures (which is now a new file) still fails!!!

5) run "cmp" to verify that the files in \temp and \pictures are in fact identical and readable

 

From this I conclude: Retrospect can't back up that file name in that location (possibly

with that data) -- it has nothing to do with the underlying file.

 

This is a scary bug... I've seen folks mess up their hashes and have hard to find bugs

like this that only show up when the filename is very, very unlucky.

 

I wonder if my tapes are good at all... I obviously can't ever know for sure -- even

doing a restore and testing it myself only guarantees that the files I happened to use

for my test are OK... And OK this time... (I need Dantz to be sure!!! I can't do QA!!!)

 

Bummer

 

-- Rich

 

Rich Testardi

+1-303-443-4254 (o/h) +1-303-883-6664 ©

E-mail: rich@testardi.com Web Page: http://www.testardi.com/rich

 

[natew]

Hi

 

Before we call it a bug lets try moving the file to another disk and see. These kinds of problems can often follow a file around the file system.

 

You can also do something like this:

Stuff or zip the file and delete the original. Then run scan disk on the drive and unzip the file again.

 

Either way will work but we should try both to be sure.

 

Nate