checksum 126.96.36.199I am proud to announce that the latest, greatest version of checksum has now been released.
NOTE: to get version update notifications for beta releases, enable the beta_channel preference.
~ In addition to scanning .hash files, checksum will now also check legacy files of the current algorithm (.md5/.sha1/etc.) when performing hash search operations ("i" switch). e.g.. vi "C:\path\to\file\somewhere\file.txt" Or scanning for a SHA1 hash (when MD5 is your default algorithm).. vias "C:\path\to\file\with\sha1\somewhere\file.txt" This only happens if a match wasn't found in any relevant .hash files. If you were /not/ using the unified .hash extension, there is no change; checksum would be scanning your relevant .md5/.sha1/.b2 files, anyway. ~/* VASTLY improved speeds when synchronizing hash files. I noticed that when syncing large hash files, checksum was taking an unacceptably long time (my new 1.2 million hashes test .hash file took over 12h, sorry about that!). checksum will now synchronize HUGE .hash files in /minutes/. That same 1.2 million hashes test file now syncs in under ten minutes on my lowly Celeron, including the time taken to scan the file system and extract and parse the hash data (adding a few dozen small files - obviously adding hashes for any large files would increase that). * Fixed an issue where large *.tar.md5 files (files with checksums concatenated to the end of them, usually tarred Android ROM files, though it is a neat idea I suspect could catch on for other file types) would cause checksum to run out of internal hash storage space. checksum should now correctly reject such a file. Then I thought to myself.. Why not ADD support for these files? ++ I made it so.. Rather than reject such files, users of *.tar.md5 files can now have checksum do an integrity check of the *.tar archive using the stored MD5. There is a preference to enable treating *.tar.md5 files as "special", which is.. tar_md5_special=true With this enabled (true), checksum will interrogate the final bytes of *.tar.md5 files for a corresponding hash. Such a file has the internal format: <tar data + NUL bytes><MD5 hash> <filename> e.g.. <TAR DATA> 923c5925c1b0b8694ea35db95e951cf5 recovery.tar If the <filename> embedded within the *.tar.md5 matches the given *.tar.md5 file name, minus the ".md5" part of course, e.g. "recovery.tar.md5" >> (contains data+hash for) >> "recovery.tar" ..checksum will pluck out the stored hash to compare against a hash of the tar data part of the file. If the original tar part of the file is intact, unchanged from when it was created, you get SUCCESS! as usual, and if not, you get CHANGED. Simple. By the way, to make such a file do (in Linux/UNIX/Cygwin shell).. # tar the file.. tar -H ustar -c recovery.img > recovery.tar # concatenate the MD5 onto the end of the tar file.. md5sum -b recovery.tar >> recovery.tar # rename to show change.. mv recovery.tar recovery.tar.md5 NOTE: NEVER change the name of your *.tar.md5 files, at least if you want checksum to verify them correctly. If you do do this and need to recover the original file name, drop the file into a (CAPABLE) text or hex editor and check out the last few bites, which will be the original name. Then simply add ".md5" to the end. Then leave it alone! ;o) + Added support for embedded hashes, in *any* file using the file name format: filename.<hash-format>.ext, e.g. "RoboCop.sha1.mp4". Checksum will work out the hash type from whatever "pre-extension" you use. If you use the unified hash extension, checksum will use the default algorithm unless you specify otherwise, e.g.. v RoboCop.md5.mp4 >> Uses MD5 v RoboCop.sha1.mp4 >> Uses SHA1 v RoboCop.hash.mp4 >> Uses MD5 vas RoboCop.hash.mp4 >> Uses SHA1 Unlike *.tar.md5 files, there is no support for verifying multiple embedded hashes. You must verify them individually - the same way you make them, at least for now. They can still be hashed along with your regular files, of course. To force verification of any file, hold the Ctrl key down when selecting the checksum item from Explorer's context menu. If you want to play with this, remember that some files will NOT work correctly once you concatenate a hash onto the end of them. Media files and archives are usually fine. ~ Faster file system search routines. This will impact the file search phase of checksum's operations, especially on LARGE file systems. ~ Improved speed when performing hash /search/ operations on large hash files. For huge hash files the time difference will be dramatic. Also, checksum now uses a 1/10th of the memory for searching. ~ Improved System Tray tips and progress windoid information. ~ With some internal rewiring, I increased the previous limit of 2,396,744 hashes per .hash file. The limit is now effectively around 16,777,215 hashes per file; what it was supposed to be. I say /around/ because although unlikely, if you have a hash file with 16,777,215 hashes + info lines + heaps of manually-added comments, during verification checksum will flag the file as being too big to handle. ~ checksum will now move its one-shot option dialogs on-screen if they are set (by the user) to appear off-screen, such as when you keep them in the far corner of your desktop and then login via remote desktop on a smaller device, such as a laptop or tablet. * Fixed memory spike on initial .hash file read, specifically when checksum was counting the number of lines in the hash file. * Fixed an issue where the logging level wasn't being reset correctly during verify operations, resulting in erroneous logging of DELETED files, but only after CORRUPT or CHANGED files had been discovered. * Fixed handling of ANSI MD5 files with foreign file names in them (which I broke in the last version). These were being treated as UTF-8 and the verification would result in apparently MISSING files. checksum will once again automatically determine the file's encoding. By the way, I DO NOT recommend you use any ANSI-only utility to create MD5 sums of directories of files with foreign names. Even using extended locales, your program will simply miss files. Of my test directory of 58 foreign-named files (including but not limited to Russian, Chinese, Urdu, Greek, Icelandic, Swedish, Arabic, and more, as well as a selection of just wild UNICODE character names), other apps will fail on at least 30 of the file names. With the default UTF-8 encoding, checksum can handle everything. Simple Checksum 0.9.3.1 ~ Simple Checksum will now disable checksum's beep for the first half of a folder compare operation. If you have beeps enabled in checksum you will hear that at the end of the completed folder compare.
Full details in the itstory.
You can grab the latest checksum (and simple checksum) from the usual place.