checksum 1.6.6.6

I 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.

Changes..

~   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.

for now..

;o)