JPG": didn't compare at offset 128 in stream

[lake]

Nate, I have some additional data on this issue. Recently my W2000 hard drive crashed. Thanks to Retrospect, i was able to recover all my data to a new hard drive. At the same time i upgraded my OS to WXP pro.

 

Now that retrospect is running again, i still get the "didn't compare at offset 128" error. This time i googled the entire error which is: "....JPG": didn't compare at offset 128 in stream ":Q30lsldxJoudresxAaaqpcawXc:DATA""

 

MS support http://support.microsoft.com/default.aspx?scid=kb;EN-US;q319300 discusses this as a design of W2000 server which adds a data stream to some files.

 

I tried to modify the registry key indicated, but it does not exist on the WXP machine. So i suspect that the error now is due to a remnant left by W2000 prior to my crash.

 

Any thoughts how to address this?

[dthede]

You won't like this, but perhaps this may lead to an additional source/direction to pursue, should you need it.

 

I used to get the message you cite or a very similar message from Veritas' Backup Exec 9.x. It was not restricted to jpegs, but most often occured in connection with them. In that server environment, the _really_ annoying thing was that frequently, but not always, the named files did not actually exist at the path cited in the error logs, or when they did, they opened just fine. I hope you appreciate that last sentence for what it states: files which were not visible or accessible by any means available to me, were causing errors in the backup process. These errors were encoded on or "reflected in" the backup tape such that the set (in the case of a backup which spanned tapes) became unusable. In other cases, my statement above says, the alleged offending file was openable in the normal way in the specified location, although the backup was still trashed.

 

We used McAfee antivirus and their Firewall, as well as a Sonic hardware/firmware-based firewall, and kept the software very well (not perfectly, evidently)up to date. The hardware was updated automatically remotely. The problem was never solved. The backup sets were trashed. Veritas was no help whatsoever.

 

The good news in that environment was that this type of error occurred only with some well defined and well-known directories. Eventually everything "important" was emptied from them and the directory containing the problem was excluded from backup.

 

Hope this isn't too depressing and that you find a solution.

[natew]

Hi

 

The information about these files as the OS is reporting them must be incorrect. i.e. it has to be disk corruption of some kind. If you copy a problem file to a USB key disk and then back it up from the USB key disk do you still get errors?

 

Thanks

Nate

[dhamre]

Is anyone with this problem using the Encrypting File System (EFS)? There is a known issue with Retrospect and EFS that causes comparison errors. See these threads:

Unfortunately, Bug Introduced In V7.0 Still There In V7.5

Sharing Violation and Compare Errors During Backup

 

Dantz/EMC: any word on a fix for this issue?

[XOR42]

Quote:

---

I keep getting this error for jpg files.

 

---

 

It's not you and there is no cure. It's an old bug with Retro. When I upgraded to v7.5, I thought it was fixed but, alas, it returned albeit with a bit less frequency. Every now and then, it incorrectly compares a few files. The experience of others and me suggests it occurs more often with media files like JPG's, MP3's and WMA's. Reports indicate that even if you go so far as to delete and restore the files, the error recurs. Reports also suggests it occurs with a frequency of less than 20 errors per million files. Of all the causes suggested, none have panned out. Two ongoing suspicions are that: Retro has trouble dealing with the headers of media files which almost always have EXIF or other data stored there; another is that Retro has trouble dealing with files that have alternate "permanent streams" opened to them by media player or other softwares.

 

Bottom line:

Use a manual file checker to do a binary comparision of the files, like BeyondCompare2 or any of the freebie compare utitlies. If they compare ok, then learn to ignore the false error. If it really bothers you and you have a compatible editor, you can try editing the file to alter it ever so slightly like by changing some of the info tags in an MP3 or JPG file or the EXIF data in an image file. That seemed to worked for me.

 

===========================

An unoffical reply from an interested user

[carolbshaw]

Quote:

---

Is anyone with this problem using the Encrypting File System (EFS)? There is a known issue with Retrospect and EFS that causes comparison errors. See these threads:

Unfortunately, Bug Introduced In V7.0 Still There In V7.5

Sharing Violation and Compare Errors During Backup

 

Dantz/EMC: any word on a fix for this issue?

 

---

 

I am not using EFS. The "didn't compare" problem went away for me when I upgraded from Retrospect 5.6 Desktop to 7.0 Professional with Open File Backup enabled. I did two full backups, and have been doing daily incremental backups for well over a month with 0 errors and 0 warnings.

 

I was using DES encryption for the 5.6 backups, and am now using AES-256 encryption to File Backup Sets. With 7.5 Professional, I had some crashes with MD5, and AES-256 or DES encryption enabled, so I fell back to version 7.0.

[XOR42]

Quote:

---

Is anyone with this problem using the Encrypting File System (EFS)?

 

---

 

Followup: Re bad comparescomment being long standing bug through v7.5

 

I am only using plain NTFS, my backupss are set to use a password, but NO extra option of encryption is specified. In many places, Retro refers to a backup with a just a password as encrypted but in others, refers to separately specified encryption as "encrypted".

 

So, regardless of Retro's confusion over terminlolgy, I also get the false compare errors on media files. I back up about 600,000 files. Of those, 5,000 are audio (mp3, wma, etc) files and about 250,000 (jpg, gif, etc) are images.

 

With that complement, I get 0-5 compare errors, averaging about 3. So, that equates to about 1 per 100,000 media files. Note that media files usually have extensive EXIF or other forms of header information like music info tags, camera settings, etc. Office documents like Word and Excel can also have extended info but I have yet to notice a compare error on them.