Comparing files seems to change one byte randomly could it be a bad storage medium?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • mgalaty
    Visitor
    • Oct 2017
    • 5

    Comparing files seems to change one byte randomly could it be a bad storage medium?

    I am comparing some files which seem to change one byte in files. After copying a directory of pictures and/or a moving perhaps a video, I am getting a one byte difference in some of the files using the binary comparison. The picture does not seem to have changed and if it was a video it still works.

    I am trying to figure out if the problem is a bad storage medium or if some backup software is causing a byte difference. Any thoughts on what could cause this? I am planning to do more testing such as turning off the backup software. One tip would be how I can use a HEX screen in Beyond Compare to read which byte is being changed; currently I am seeing the difference in text which I can't tell what byte or offset was different.
  • Aaron
    Team Scooter
    • Oct 2007
    • 15996

    #2
    Hello,

    First, if you are in the Text Compare view looking at the text of a file, you can use the Session menu -> Compare Files Using menu -> Hex Compare to switch views. A binary scan from the Folder Compare can also reveal if the files are exact matches or if anything has changed.

    If this is copying to an FTP, you might have line ending conversion occurring. This is usually larger than just one byte, but can be disabled in the Tools menu -> Profiles dialog, select the FTP profile, and in the Transfer tab switch from AUTO to Binary for transfers, then restart BC4.

    Does this corruption happen if you copy using BC4? Using Explorer? Another application? Does it require copying or does just comparing/opening/viewing files trigger it? What kind of device (base folder syntax) is the source and what is the destination?
    Aaron P Scooter Software

    Comment

    • mgalaty
      Visitor
      • Oct 2017
      • 5

      #3
      Hi - I am copying from a Windows 10 system to a attached USB drive. I have the code 42 software backing up the USB drive. I use BC2 to compare the files and when I saw RED, I'd copy the file again. I can fix the files such that they match, but after running a binary compare on 180+gig, some time later I'll find RED files which when I compare I'll find a one character difference. What I am not sure is if the drive is failing and I actually get a file corruption or if the backup software is changing some internal byte in the file for some other reason. I am thinking of turning off the backup software to determine it, but I was hoping someone had a perspective on what I might be seeing. These are a bunch of raw pictures which are stored in directories taken from a phone camera. They may have internal file hidden attribute and I am thinking those may be updated. I also thought about putting a read only flag on the files.
      My goal is to take the files off the system and be sure I've gotten a perfect copy without errors. I thought the binary comparison by BC2 would prove I have a good copy and I'd then delete from the Windows 10 system. What I don't want to do is delete and find out I am having a corrupt drive issue and my photos and videos are not what they were. I may do an MD5 to these to figure out what is changing.
      Thoughts?
      Thanks for the tip on the HEX, I'll try that.
      Michael

      Comment

      • mgalaty
        Visitor
        • Oct 2017
        • 5

        #4
        I am running build 2.5.3 and I am not seeing the menus for the Hex dump.

        Comment

        • mgalaty
          Visitor
          • Oct 2017
          • 5

          #5
          RE: "Does this corruption happen if you copy using BC4?"===> I am using Build 2.3.5.

          Using Explorer? I initially copied with Robocopy, but then tried to make the two paths equal using BC2.3.5 so I later copied with BC all the red files.

          Another application? Robocopy 2.3.5.

          Does it require copying or does just comparing/opening/viewing files trigger it? I made a copy of a directory and all subdirectories with Robocopy, then I did a binary compare with BC2.3.5. I then showed only the different files and then used BC2.3.5 to make the files the same. I later re-ran the BC2.3.5 binary compare and some of the files went red again.

          What kind of device (base folder syntax) is the source and what is the destination? I am copying off a hard drive onto a backup USB drive. I am intending on taking the files off the drive and leaving them on the USB drive. I'd like to make sure I have an exact binary copy before I remove them from the hard drive. With the BC2.3.5 binary errors I don't know if I made a good copy or if corruptions are appearing on any of the drives. I also have a backup utility running which is backing up both directories (the original and the usb drive).

          Comment

          • Aaron
            Team Scooter
            • Oct 2007
            • 15996

            #6
            Given your description, files shouldn't be altering after a copy. If you are performing a Backup, you should always have the files in two locations; otherwise if the USB drive dies (which, it looks like one of the drives might be), then you would lose the files if that was the only location they existed.

            One feature that might help: once the file copy is finished and both files are equal binary scans, use the BC2 Tools menu -> Save Snapshot to save a snapshot of each side (two .bcss files) that include the CRC code. You can then go back later and compare the Snapshot to the Side at a later date and see if either side has had the CRC code change over time. This would help you determine which side is causing the difference to occur. That, or you can perform the MD5 test you were thinking of.
            Aaron P Scooter Software

            Comment

            • mgalaty
              Visitor
              • Oct 2017
              • 5

              #7
              It seems that I've found a few articles that confirm that copying files to an external drive could cause corruption. I found a work around which improves the performance and I am pasting the link below. I've proven with some testing that the external drive copies were the files which had the corruption (basically looking for old backup copies of the files, comparing with the main disk where I am storing the files and the other backups I had compared correctly.) I hope this observation helps someone else. Once I validate this completely, I may add an update to this post. If anyone has seen or has experience, you can also reply to this post. Thank you.

              Files getting corrupt while copying to external hard drives
              https://superuser.com/questions/8182...al-hard-drives

              Comment

              Working...