Slashdot Mirror
Automated PDF File Integrity Checking?
WomensHealth writes "I have about 6500 pdfs in my 'My Paperport Documents' folder that I've created over the years. As with all valuable data, I maintain off-site backups. Occasionally, when accessing a very old folder, I'll find one or two corrupted files. I would like to incorporate into my backup routine, a way of verifying the integrity of each file, so that I can immediately identify and replace with a backed-up version, any that might become corrupted. I'm not talking about verifying the integrity of the backup as a whole, instead, I want to periodically check the integrity of each individual PDF in the collection. Any way to do this in an automated fashion? I could use either an XP or OS X solution. I could even boot a Linux distro if required."
Maintaining a database of md5 checksum on the archived versions of the files and periodically check your live versions against it?
Remote backup with a notification of changed files and versions of all previous files for restoration.
wouldn't be too hard to write an inotify script that stores a backup of the file and an md5sum whenever you drop a file in. wouldn't help you recover an already corrupt document, but it would help you to stop it in the future. a tie-in to the actions menu would make it more usable, but that's a bit more effort, and such solutions probably already exist.
There are PDF libraries out there - write a wrapper that loads a file, and when it gets to the end without error emits a 0 "no error" return code, and any errors result in a non-zero code.
/dev/null and check the exit code. I'd be surprised if there were a ready-made solution for this somewhere.
Or maybe there are other cmd-line tools which issue a "failed to load" error. That's where I'd look first. Like a tool to strip content out of a PDF - script it so it outputs to
md5sum *.pdf > sums
md5sum -c sums
Not exactly automated, but I wouldn't exactly call typing 2 lines to be manual labor; and once you've got the sums you really just need the second line.
Put something like this in a shell script and you can make it automatically replace files that fail a hash check with a good backup. Use perl, python, or whatever, and you can make it work across Windows, OS X, and *nix.
When you have finished this cup of coffee your adventure will begin again.
it has built in integrity checking and stuff.
Do you even lift?
These aren't the 'roids you're looking for.
Just use the Linux md5sum utility:
Create checksums: md5sum file > file.md5
Test: md5sum -c file.md5
Or use a compressor: bzip2 file
Test: bzip2 -tv file.bz2
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Are you sure the corruption didn't happen when the PDFs were being created, as opposed to when they were being backed up (or restored)?
PDFs are not as trouble-free as many people seem to think. I would swear to this in a court of law because I used to have a job that had me handling several hundred PDFs every day that had been generated by companies from around the world, using virtually every PDF creation software package known to man. Trust me: PDFs don't always start out their lives error-free.
So finding out when and how the corruption occurred really matters here, because it will determine at what point(s) you'll need to verify the PDFs are valid.
I once found this:
http://multivalent.sourceforge.net/
The Multivalent suite of document tools includes a command-line utility that validates PDFs. It can be run across a whole directory of files too, so should do the trick.
Written in Java, so should run anywhere.
Use git.
http://git.or.cz/
Check them all into a repository, then periodically run git-fsck. Git hashes all files in a repository with SHA-1 when they're first committed, and git-fsck recalculates the hashes.
Jon
The OP is not asking about preventing future corruption; the OP wants an automated way to sift through 6500 PDFs to find corrupt (or at least, potentially corrupt) PDF files without having to open each one by hand.
MD5 generates a hash of the binary data of the PDF file. A MD5 hash will not tell you if a PDF file is corrupt; it is only useful once the integrity of the PDF has been confirmed. After the integrity is confirmed, then you can make your database of MD5 hashes, to detect future corruption.
To test that a given file is a valid PDF, you could probably use something like pdf2ps; you don't care about the PostScript output per se, but you'd be testing for an error code. If pdf2ps returns an error code, you set the file aside for manual verification. This should, if nothing else, whittle down that 6500 PDF archive into a much smaller subset that you can feasibly test manually using Adobe Acrobat. And those, if you "refry" them (print them back to the Adobe PDF printer to re-PDF it), will probably fix the PDF so it passes the pdf2ps test.
I will leave the actual writing of a script to recurse through your directories, feed each PDF file through pdf2ps, and test for error codes, as an exercise to the OP. Now that you have an idea of what to do, actually doing it should be pretty simple.
Here is a java command line tool designed to check the validity of 1000's of pdf files:
http://multivalent.sourceforge.net/Tools/pdf/Validate.html
There is also a tool for repairing some pdf errors:
http://multivalent.sourceforge.net/Tools/index.html
Never used it myself, just stumbled over it when I was searching for some pdf software.
--
Regards
Many are commenting on using checksums (MD5, SHA, ....) to validate the file hasn't changed. This is good. However, none of these can actually tell if the PDF was is good to begin with. I would suggest using Ghostscript to verify that the PDF is properly structured. Ghostscript is an opensource tool that can convert PDF and Postscript files to several other formats. If Ghostscript can interpret the PDF file without errors, then odds are the file is good too.
This is a boring sig
One of the things that strikes me about the posts thus far is that nobody has asked the first and most important question: *WHY* are the files becoming corrupted? And what is the nature of the corruption?
From a general accessibility perspective, the age of the folders shouldn't matter, nor should the age of the files contained within them: A properly operating file system will maintain the integrity of the files it tracks indefinitely, assuming the underlying media is sound and all related hardware is functioning correctly.
Certainly, for verification of critical data, checksums are a good measure so long as they are done at the time of file creation, after verification that the files are good, but in light of the reported symptoms, I'd investigate the source of the problem first, and correct it. Then I'd make provisions for checksumming, in addition to regular file system health checks, before backing up those files and their checksums.
Proceeding from a "bottom-up point of view": For Windows-based systems, regardless of the file system in use (although I'd hope you'd be using NTFS), regular file system scans via CHKDSK are a must. The same applies to the file systems of other OS': Run whatever utilities are available to verify the integrity of the file system on each hard drive regularly.
In addition, most hard drive manufacturers have utilities that you can download for free that will non-destructively scan the media for grown defects. These are typically available as ISOs: Make a CD, boot from it, and follow the instructions carefully, preferably after making a full, verified backup. Naturally, you'll have to know the manufacturer(s) of your hard drives.
Once you've identified the cause of the corruption, and corrected it, then you can (and should) make provisions for checksums.
But, there are other things that you can, and should check as well. Make sure that the AC power to your computer is sound from an electrical perspective and that the power available is sufficient for the load being placed upon it. Buy a good UPS if you don't have one already, and if you do have one, test it.
Then, test the power supply in the computer to ensure that it is providing adequate power.
Then test the memory in your computer.
Then test the hard drives, both surface level and file system level.
Hope this helps.
If you've got files on your computer that you only read, never write, and those files are getting corrupted, then it sounds like you have a problem with your filesystem, or a problem with your hardware. You need to find and fix the problem with the filesystem or hardware, not apply band-aids to PDF files if the problem has nothing to do with the PDF format per se.
Another possibility would be that you're using buggy software that is supposed to open PDF files in read-only mode, but actually corrupts them. If so, then you need to identify what the software is that's doing it, so you can remove that software from your computer.
For diagnosis, and also recovery, one thing you could try would be using the Unison file synchronizer to synchronize your files with a hard disk on another computer. If the files aren't changing, it will run extremely fast. If you notice mysterious changes to files right after a blackout or an electrical storm, then you can guess that's why. If you notice mysterious changes right after you use a particular application, ditto. Unison has a -fastcheck option on Windows, which you should read about; you'd probably want to run most of the time with it, and maybe once a week without it.
Find free books.
Works on Winders, Linux, OS X, *BSD, even Solaris. Build yourself an AT every night .BAT file that checks 'em all. It might even be able to repair the corrupted ones.
...bittorrent? It has built in file integrity checking. Simply create a torrent for the files and have the backup source seed. Then periodically check the integrity of the files (many clients can let you force a recheck of file integrity) and it will not only identify corrupt files, but automatically download replacements from the backup. If you have to add files to the backup, it does require you to make a new torrent. Still, if you set things up right it does prove to be a rather elegant solution, I've used it myself for a few things in the past.
This could be anywhere from just works to very effective, but a distributed version control system, so copied can be kept on multiple systems easily, and something that can check the integrity of files.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software seems interesting, look for distributed and atomic commits, and signed tags (though this by itself doesn't guarantee it catches file errors right away).
I use and love Git, and though Windows support is there, it is questionable I have heard.
Adding or saving changes is "git add [file]" then "git commit", checking files for any changes is "git status", checking the integrity of the stored data history is "git fsck", pushing your changes to a remote backup location is "git push" .
Mercurial and Monotone do similar things (if differently or not as well), but have better Windows support.
If there is any reason not to use a version system, it is the complexity and abundance of features that are not needed for something this simple.
Wonder what the public key field is for?
has modules for checking pdf files.
http://hul.harvard.edu/jhove/
Linux and possibly OSX should be able to make of md5sum and pdfinfo to do the following in a script:
1) upon PDF generation use pdfinfo to ensure that it is a valid PDF (i have had generation fail and no reader could open it when needed months later)
2) if Generation and validation are successful generate md5sum for file and store values gen_md5sum,cur_md5sum,filename,unix_path,valid (bool),invalid_time,valid_timestamp in mysql a (myisam table format) database.
3) Weekly cron does comparison with files in path stored and MD5 for and checks against table check if current MD5sum matches known valid MD5.
If you are not doing MD5sum generation in batch then the process should be quick, this way you can see the date of generation for the file and MD5 and also when it may have become corrupt.
-kb
XPdf comes with a 'pdfinfo' command line utility. It returns non-zero if the PDF is corrupt. Should be somewhat efficient and very easy to automate.
PAR2 does checksums of each file and checksums of sections of the contents of each file in an overlapping way. If any section of any file in the PAR2 archive is corrupted/lost, the original contents can be regenerated, given enough time and CPU power ... depending on how much of each file is missing.