$++ Mail Notification on hash failures.
Yes! checksum can mail you when it detects errors in your files;
especially handy for scheduled tasks running while you are away or
otherwise engaged.
Your mail preferences can be edited from a cute GUI available from
checksum's System Tray menu (while one-shot verify options window is
open). It can do CC, BCC, SSL, single and multiple file attachments,
mail priority, all the usual goodies. (it uses the built-in Windows CDO
mail sending functions)
I've tested it successfully with a few outgoing servers including gmx
and gmail (both using SSL on the standard port: 465) as well as my own
local Linux sendmail.
To attach files, you can either enter the full path of the file(s) into
the attachment input (separate multiple files with semi-colons ";"), or
else click the label "Attachments" to browse for files (which will be
appended to your current input), or else drag & drop files directly onto
the input (which replaces the current input).
NOTE: You can use the "@log" token (no quotes) to attach the final log
to the email - most useful! e.g..
@log;C:\some\other\file.txt;C:\and\another.png
Attaching you log file, as well as being extremely useful, has the added
bonus of (assuming you have inline attachments and HTML enabled in your
mail client) making the entire mail look cool like a checksum log!
Finally, you can also save mail settings as presets for later recall.
This makes it easy to switch between mail servers, if required.
+ The Mail-On-Fail dialog is also resizable, like the create options, for
the same (accessibility) reasons, and with corresponding checksum.ini
hacks available for permanent resizing (these are the minimum values)..
mail_options_width=265
mail_options_height=360
+ BAD files (those which appear to be .hash files, but are not - most
likely corrupted) will now be logged as well as reported. BAD files can
be sign of disk corruption.
~ Even faster startup!
~ The final total number of files processed is now also shown in the final
dialog during verify operations as well as creation tasks.
~ During search+verify operations, if checksum discovers a changed file,
it will now update the hash (if you have this behaviour enabled - by
using the "w" switch). Previously the "w" switch had no effect in this
scenario.
+ I have added an option for search+verify to the one-shot verify options.
It's kinda thrown in for now, until I can get around to re-organising
that window. But it works!
~ If you have open_log_folder ("g" switch) set during verification and
there are hash failures and the log folder is /already/ open on your
desktop /somewhere/, checksum will bring it to the front.
* Fixed a bug where a couple of the verify switches were not translating
into the checked items in the one-shot verify options.
£* Fixed the bug in the disable edit ini and custom preamble not being
available to registered users.
* Fixed a bug in the relative and fall-back logging locations. If a blank
log location is entered, the log will now appear in the top folder
checked, as expected. And if that is not possible, it will fall-back to
your desktop (and now with a file extension, as expected!). No one uses
this (because the checksum dedicated log folder is such a good idea!),
which is how it escaped my attention so long.~ Faster string search routines (now almost twice as fast). This impacts hash synchronization, checking files from the list of existing hashes. I have tested the new routines against a range of strange foreign languages and Unicode characters with 100% success. * Fixed sync issue when using absolute paths inside root hashes. This was leading to duplicate hash entries. * Fixed issue with hash comments not respecting the always_store_unc pref (they were using UNC-style paths even when this was disabled - it caused no issue, but looked incongruous). * Fixed a bug in applying unified extension to multiple legacy hash files. This almost never happens, but if you happen to have .md5/.sha1/.blake2 hash files for a file and applied a unified extension, hashes for second and subsequent algorithms were being re-calculated.
+ Added search + verify command to checksum's default installed Explorer
context commands. It's that handy! (see 1.5.6.3 changes)
If you want this NOW, either uninstall+reinstall checksum (all your
settings will remain intact) or else merge the sample registry file
found here: https://corz.org/windows/software/checksum/files/
++ Directory Exclude Masks. You can now specify one or more directories
which you would like to exclude from the hash creation process, using
standard file masks (?,*). The "x" switch, followed by a set of exclude
masks in braces, enables this functionality. Separate individual masks
with a comma.
For example, you want to create a root hash, but not hash any
directories who's names begin with "Foo", or end with "Bar", or starts
with "baz" AND ends "qux", do..
checksum.exe cr1x(foo*,*bar,baz*qux) "D:\MyDir"
* Fixed long path handling in search+verify function - Of course Explorer
is sending short paths. Doh!++ checksum will now post the path that was hashed/verified in the final
tooltip, in case you forgot what it was you were hashing, e.g..
checksum completed verifying: e:\music\jazz\ in 3.55 seconds.. [100% OK]
++ Added new method (actually, the original method!) for testing
writeability of directories. Normally we use the most accurate method,
which is to write an actual test file to the directory. However, this
will also change the "last modified" timestamp on that directory.
If you would prefer this to /not/ happen, you can do (in checksum.ini)..
relaxed_write_test=true
which will instead rely on the system's "read-only" flag for the
directory. This works in most ordinary scenarios.
++ Added Individual file verification search feature. This enables you to
verify a single file, anywhere in your system, /from/ anywhere in your
system, regardless of where its associated .hash file is in the file
tree.
This is extremely useful when you want to verify a single file but don't
have an individual .hash for it, especially when the entry is inside a
.hash file with thousands or millions of other entries, or you aren't
sure exactly which .hash file contains the entry.
Normally, for verification you feed checksum .hash (or .md5, whatever)
files and it scans them looking for matching files to hash. Using /this/
method, you feed checksum a regular file path and it scans your .hash
files looking for a matching hash entry!
checksum will search up the tree, first looking for matching individual
.hash files, and then folder hashes, all the way up to the root of the
volume until it finds one containing a hash for your file, at which
point it will verify that one hash and return the result.
The final dialog will also tell you *which* .hash file contained the
entry for your chosen file.
Thanks to Brett Lang for the original idea, which he presented to me as
a DOS batch script doing a similar thing. I have to admit, it took me a
while to get my head around the idea (it's just so back-to-front!), but
once I did, I immediately saw how useful such a feature might be.
You can enable this operation by using an "i" on the command-line, think
"individual" file verification, or perhaps "Inverted operation"! e.g..
checksum.exe vi "C:\some\path\to\file.ext"
This works best as an Explorer context command. Future versions may have
this built-in to the installer setup. For now, an example .reg file is
at https://corz.org/windows/software/checksum/files/