About Integrity Checker
IntegrityChecker™ creates one hidden file per folder (“.ic”), which contains the integrity-validation information for each file in that folder.
You choose which volume(s) or folder(s) you want to validate, running IntegrityChecker on them. Later, the originals or any copies of the originals can be validated, because the .ic files “go along for the ride” when the folder(s) are copied or backed-up.
Of course, files often legitimately change, and here IntegrityChecker provides a report on which files changed and how, including flagging suspicious files that appear to be damaged. When files change, you can run IntegrityChecker on just the folders containing the changed files, to update their status appropriately. The validation detects detect flaky hardware that might sporadically generate bit errors in files, or software nasties, etc.
*The '.ic' file contains the integrity-validation information for each file in that folder, which is based on the 160-bit cryptographically strong Secure Hash Algorithm, SHA1. Which means that if a single bit changes, the odds of missing it are incredibly small — you’re far more likely to win the lottery.
Compatibility and speed
IntegrityChecker is a single-file universal binary that runs on 32-bit or 64-bit systems, Mac OS X 10.6 (Snow Leopard) or 10.5 (Leopard).
Is it safe?
- Opens your files read-only;
- Never writes to the disk except to write its own validation (“.ic”) files.
- The validation process writes no files at all— it’s strictly read-only.
Is it fast?
IntegrityChecker’s sophisticated multi-threaded design can make full use of all CPU cores, scaling to 16 CPU cores or more. It is can process data at (approximately) 2800MB/sec, if you are unusual enough to have a disk array that can run that fast.
Well before Apple’s Grand Central technology, IntegrityChecker was written efficiently using robust “pthreads” technology. Numerous small files are slower due of course, but even those are processed in a sophisticated multi-threaded way, utilizing a dedicated thread even to open and close files.
Actual processing speed is almost always dependent on how fast the drives are, not the speed of the CPU, unless you have a very fast disk and a very slow CPU.
Exampleon 8 coreCPU
Show below are five copies of IntegrityChecker™ (“ic”) running on a Mac Pro Nehalem 2.93Ghz 8-core. Four striped RAID arrays were configured to provide the 1.4 gigabytes per second disk I/O for testing. The Mac Pro CPUs are still only about 50% utilized; it could accept nearly 3GB/sec before “maxing out”.
Copyright © 2008-2010 diglloyd Inc, all rights reserved