Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Each time I compress a file via the command line 7zip is nice enough to return "Everything is okay". I know that I can test the integrity of an archive if I run the command 7z t but is it necessary if the former is being displayed? What added advantage is there?

share|improve this question
up vote 2 down vote accepted

"Necessary" is a somewhat relative term. When 7-Zip says that everything is okay, this just means that it didn't detect any errors during its compression process, and that it thinks it wrote out the compressed file successfully.

It's conceivable that 7-Zip could have a bug that would cause it to fail to detect an error in compression. This is probably fairly unlikely, since 7-Zip is widely used and therefore pretty well-tested in practice. A more likely scenario is a hardware problem that causes 7-Zip not to produce or write out a correct output. This could be due to a problem with your hard disk, your RAM, overheating of hardware, or any number of other things. 7-Zip is not likely to detect such an error. So doing a test of the archive afterwards is a decent way to detect such problems, but not totally guaranteed either. (I'd say it's not at all unlikely that you might run into bad hardware at some point in your lifetime.)

So, the bottom line is, I'd say that if the data's important to you, then go ahead and test the archive afterwards.

share|improve this answer
I'd go further: if the data in the archive is really important, verifying the archive integrity isn't enough. Unzip it (on a different machine if possible) and then compare the unzipped contents to the originals (using, e.g., windiff). – Harry Johnston Aug 26 '12 at 22:43
@HarryJohnston -- Quite correct. And of course, you also need to have some strategy (such as actually running the archived app/whatever on the other system) to assure that you didn't miss any files. Many a system backup has been found unusable because of omitted files. – Daniel R Hicks Aug 26 '12 at 22:45
@Harry Johnston - How would you automate the process of comparing files? – PeanutsMonkey Aug 27 '12 at 1:55
@PeanutsMonkey: by "compare" I mean "check that the contents are identical" so the files don't need to be ASCII and Nifle's suggestion is sound. Personally I'd use SHA512 rather than MD5, but that's more a matter of taste than an objective preference. If you can network between the two machines (or if you do it on a single machine) another option is to directly compare the binary content using any suitable tool. I usually use windiff (from the Windows resource kit) but it's not a great option as it sometimes has trouble with large directories. – Harry Johnston Aug 27 '12 at 3:27
If you really want to do a direct comparison, I'd install Cygwin and use diff -r, though there's a learning curve involved if you're not familiar with Unix-like systems. The checksum approach is really best overall. MD5 will do nicely here; the benefit you get from SHA-512 is totally negligible for this particular use case, and it will take substantially longer for large files. – jjlin Aug 27 '12 at 6:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.