checksum
a no-nonsense hashing utility for windows..
http://corz.org/windows/software/checksum/
(c) corz.org
itstory.. aka 'version history'.. aka 'changes'..
[known bugs at the bottom]
Key..
* Fixes
~ Changes
+ New stuff
++ Requested New stuff
Last updated: Saturday Apr 13, 2013
1.3.5 [current development beta]
You thought the old version of checksum was the fastest hashing
application in the world? Try this! ...
++ 64 and 32 bit versions now available.
+ Significant increases in the hashing speeds in both 32-bit and 64-bit
editions, thanks to the improved compilers (and compiler options)
available today, as well as some code tweaks implemented during the
64-bit DLL update. I have also switched out the SHA1 routines for
something faster, for example..
My DVD-sized
"BIG.iso" test file used to MD5 hash (on my current system)
in 24.3 seconds. Pretty fast. That time is now under 16 seconds both the
32 bit and 64 bit editions. A SHA1 hash of the same file used to take
41.8s. It now takes less than 24s. As they say, YMMV, but I am looking
at speed increases of between 60% for MD5 and 79% for SHA1 <insert
exlamation point>.
Of course, the rate at which your system can get the data off your drive
will always be the limiting factor. And though the latest checksum is
tuned to deliver maximum disk data throughput, with 300MB/s hashing
speeds, no current hard drive could keep up. SSD users, enjoy!
+ International file name handling on >= Windows 7; Russian, Japanese,
whatever. This change is upstream, so I am keen to hear reports on it
working or otherwise on YOUR system.
++ checksum can now optionally store a file's modification date and time
along with the checksums, like so..
fba7b0f424d3c217d312bcd84728ac8f *Björk - Hunter.flac
00073fa1652f74961c1a9696afa7a992 *Desirée.flac
5deee1f6ac75961d2f5b3cfc01bdb39c *info.nfo
Thanks to the extra information, during verification checksum will
report files with mismatched hashes as either
"CHANGED" (they have been
modified by some user/process) or
"CORRUPT", where the modification
timestamp is unchanged.
These will show as a different color in your HTML logs (assuming you
are using an updated master CSS file).
You can also now choose whether or not to report (and log) missing,
changed, or corrupted files. For example, if you only want to know about
CORRUPT files, but don't care about changed or missing files, you would
set..
report_missing=false
report_changed=false
report_corrupt=true
As one commenter on the checksum page pointed out, with this sort of
functionality, checksum would become
"the only tool against silent data
corruption". I belive this goal has now been achieved.
The chosen algorithm is also stored along with this information, for
possible future use (aye, more algorithms!).
++ checksum can now post its completion times in a more readable format,
rather than using only seconds..
readable_times=true
This affects not only the message and ToolTip windoid displayed at the
end of checksum operations, but the times shown in the logs (if you have
that enabled).
+ checksum will now check online for newer versions of itself. This is
configurable in checksum.ini - you can set how many days to wait between
checks.
++ Customizable preamble string (the comment at the top of the .hash file)
+ New software licensing model. From your side of things, the biggest
change is that everyone now gets their own specific key. Also it's a lot
easier to enter!
There will be a facility for existing registered users to upgrade their
license key in time for the beta release.
++ Rudimentary queueing system. Rather than warn you about running multiple
copies on the same disk, checksum now has the option to queue jobs. If
checksum is already running and you launch a second copy (maybe by
selecting multiple items in explorer and doing a checksum context
command on them), it will add the job to a simple queu file which
checksum checks on exit. If there are jobs there, it launches itself
with the job, deletes it, and so on. It's nothing fancy, but it works.
Note: if you do this sort of thing a lot, you will probably want to
increase the long_operation time in your preferences.
~ If you have the ToolTip disabled, left-clicking checksum's tray icon
will show the Progress ToolTip, so you can see what's happening.
Previously, left-clicking the tray icon peformed no action.
* Fixed an issue where if you had the ToolTip disabled on launch and then
quickly enabled it while checkum was in the middle of a long operation
(for example, gathering the hashes for a large folder) you would get a
blank ToolTip (until the next ToolTip message was posted).
* Fixed a minor issue where the one-shot verify options audio alerts
setting would initially display the setting for the progress tip!
* Fixed an issue where checksum would unhide previously hidden checksum
files if checksum hiding was off in the prefs. Now it will leave them
alone.
simple checksum 0.8.4 [current development beta]
+ simple checksum will now do automatic clipboard compare from initial
launch. This is in addition to during all drag and drop operations.
Basically, if there's a hash in the clipboard when you hash a file, via
any route, simple checksum will attempt to compare the hashes.
Alt-C gets you the actual hash, if required.
+ A new option has been added to the menu:
"Clear the Clipboard".
simple checksum 0.8.3
~ simple checksum will now strip any white space from hashes in the
clipboard when comparing against dropped files. This is useful when
the user has copied the hash from a web page with an extra space or
linebreak at the end (sometimes unwittingly). It is also useful when
comparing against hashes which have been presented
"split", like so:
1852 fd05 0afa 3693 2a00 2c4d 08b9 b37b
Note: simple checksum will not alter the clipboard data in any way, it
will simply remove all whitespace before comparing against the hash of
the dropped file.
1.2 [current release]
++ You can now specify an output directory for your hashes, either in
checksum.ini..
out_dir=C:\hashes
Or with a command-line switch (
"d") This uses the same form as file type
groups (i.e. in braces), like so..
crid(C:\hashfiles)
"D:\some documents" In this example, checksum would hash the files in
"D:\some documents" and put the .hash files in
"C:\hashfiles".
Please be careful with this, mindful of the ramifications, especially
if you also have a static custom hash file name!
++ You now have the option to cancel a hashing operation in mid-stream.
Simply hit the <Pause/Break> key. This change is inside hash.dll.
This is especially handy on slower machines, when hashing very large
files and you need access to all your CPU cycles for a moment,
effectively using the
"Abort Hashing?" dialog as a <pause> control.
+ checksum will now check the version of its hashing library and
automatically update the dll file to the newest version, if required.
This is handy if didn't run the main installer.
+ Improved static memory usage.
~
"Individual",
"extensionless" checksum files of files beginning with a
dot will now be given the name,
"nameless", for example, an extensionless
individual checksum file of a file called
".foobar" would be named,
"nameless.hash", rather than create a .dot file (
".hash"), which can
become automaticaly invisible under certain configurations.
Most of these sorts of files would likely be better entered into your
ignore prefs, in checksum.ini.
++~ checksum now correctly verifies only hashes of the algorithm specified.
With the advent of unified hashing, this process needed to work on a
per-hash basis, as well as a per-file; both SHA-1 and MD5 could be
contained within the same file (i.e.
"foobar.hash"), as well as within
filename-specific files like
"foo.md5" or
"bar.sha1".
checksum now verifies only the hashes you specify, ignoring the other
algorithm altogether. checksum will also not load old-school hash files
from other algorithms, i.e. when asked to check only SHA-1 hashes,
checksum will ignore a file named,
"foobar.md5".
Only if you specify an alogorithm either on command-line (
"am" for MD5,
"as" for SHA-1), or in the one-shot options dialog (hold <SHIFT> on
launch) will checksum use this behaviour, otherwise the default
behaviour is still to verify ALL hashes in ALL hash files encountered in
the path.
++ There is a new @parent token which you can use in your
"hashfile_name" preference; it will be replaced with the name of the parent directory of
the file being hashed.
You can also specify how far
"up" to go when determining the name to
use, like so:
"@parent+1",
"@parent+2" and so on, as high as you like;
checksum will transform the @parent token into the currently selected
parent directory (+2. etc.), all the way up to the drive letter itself.
Thereafter, checksum will return an empty string.
NOTE:
"parent" refers to the parent of the FILE(S) being hashed, so when
performing a folder hash on
"C:\foo\bar\foobar",
"foobar" is still the
parent (of the files being hashed). If you need
"bar" in your custom
name, use @parent+1. To get
"foo", use @parent+2, and so on. In this
example, @parent+3 would return
"C", the drive letter, @parent+4, +5,
etc., would return an empty string.
* Fixed a bug where folders set in
"ignore_folders" would only work
inside the folder itself, but not folders inside that, and hashes were
being created in its subdirectories. checksum will now correctly skip
all folders specified in your
"ignore_folders" preference, and all
folders inside, and so on.
* Fixed a bug where checksum could crash if you had an instance open
at the one-shot options, and opened a second instance of checksum.
* Fixed a bug where an extra line-feed character could be added to the
end of files during synchronization, if those files contained hashes
with file names using special characters.
* Fixed a bug where synchronizing UTF8 files with special characters
which had been saved (manually by the user) without their BOM (Byte
Order Marker), resulted in the hash file being re-saved as ASCII,
duplicating the file hash, and potentially mangling the results.
checksum now correctly opens UTF8 files as UTF8 when specified to do so,
rather than converting them to ASCII if you deleted the BOM somehow.
* Fixed the SHA-1 bug in files greater than 4GB (Thanks to qriist for
spotting this error and to Michael D. Leonhard for the C++ help in
fixing it, and the original SHA-1 code, of course).
Previously checksum produced erroneous (though quite consistent) results
with the SHA-1 algorithm on files greater than exactly 4GB. This was
caused by an internal overflow within checksum's hashing library.
checksum's SHA-1 handling is now fast AND accurate, at any file size.
+ Added an input dialog for the shirtware registration code.
Five bucks, people!
* Fixed a bug where running checksum with an empty checksum.ini file would
throw up a fatal error.
++ You can now set the default file mask in your preferences.
default_mask=*.*
Normally this defaults to
"*.*" (checksum ALL files), but you can use
whatever you need. Most people will not need this - the one-shot options
dialog is usually a better way to set these things, on a per-job basis.
* Fixed a bug where exiting from a long verify operation with no errors (so
far) could throw up an empty dialog box (the tooltip shows the full status)
+ added a preference (convert_names) which will convert any truly foreign
file names that do not map correctly (i.e. Russian), into old-school 8.3
file names, which should enable you to hash *anything*.
convert_names=true
Hopefully this is a stop-gap measure until I can justify a re-write of
the hashing library to use
"boost" or similar to handle file names in
*any* language. This will produce a very slight overhead, which is why
it is optional, only for those who really need it.
NOTE: most languages are handled correctly by checksum already, without
using this preference, for example these files..
Björk - Hunter.flac
Desirée.flac
The First Noël.mp3
would be hashed and verified just fine, without any additional settings.
+ checksum now posts which algorithm it is currently checking in its
ToolTip
+ checksum now logs which algorithm has changed (when logging is enabled).
* Fixed a potential bug where checksum could fail to write hashes if the
file's name was very short and its path was *almost* at the system's
maximum file length. checksum now tests a variety of random names of the
exact same length as the .hash file name, before deciding if a location
can or cannot be written to.
Although this checking is very fast, it should be noted that checksum
tests the writeablility of every .hash/.md5/.sha1 file which is to be
written, and then has to write that file, so
"root" hashing a large
filesystem will always be faster than using individual .hash files.
+ I added a spacial
"portable" command-line switch. In line with my more
recent apps, checksum will setup itself for total portable operation,
without you having to fish out an ini file or set your logging location
preference. To activate this one-time operation simply run..
C:\Path\to\checksum.exe portable
~ The (much loved!)
"command-line error" window (which you get if you
launch checksum with no drag-and-drop or command-line switches) has been
renamed and made smaller (to fit into netbook windows). You can also
move it around by clicking and dragging anywhere within the main window
(in the text - for those poor souls not running KDE-Mover-Sizer).
It still does the same things, but now has more logical buttons, as well
as one that takes you to the checksum tricks and tips page which
explains the whole switches topic in greater detail, as well as lots of
other useful tricks for using and getting the most from checksum.
+ I dropped my
"Checksum For Linux" distribution into the extras folder.
Have fun with that!
~ I noticed in my (long) 2do list that I meant to mention that checksum
now sets the working directory (to its own directory) when running in
portable mode.
simple checksum 0.7
+ Added new
"Auto" sub-menu to the application menu, with two options..
Auto Copy to Clipboard
Auto Save to File.
Use these options with caution; the Auto Copy will replace whatever
was in your Windows clipboard with the current hash, be it file or
string hash, and the Auto Save will write a hash file next to the
dropped file, overwriting any file previously in that location. A
warning dialog displays the first time you enable the setting.
+ If Auto Save is enabled, and you re-hash a dropped file with the
other algorithm, simple checksum will re-write the saved hash file
with both algorithms stored inside - it won't attempt another hash
write until you drag and drop a new file, even if that is the same
file.
* Fixed a bug where if you switched case after calculating both MD5
and SHA hashes, and then switched the case back, only the current
algorithm and future algorithms would comply, but the stored
alternative algorithm would still be in the old case.
simple checksum 0.8 [currently available beta]
++ simple checksum now accepts two files for comparison, either on the
command-line, or via drag & drop into its input. I'm glad to get
this off the 2do list, if only to stop folk asking for it!
I've had to rewrite the way file paths are read from the user input,
hooking directly into the drag and drop process, so any bug-reports
will be gratefully appreciated.
By the way, you can retrieve the actual hash by hitting Alt-C. If
the two hashes were different (NO MATCH) you can get the second hash
by clicking ALT-C a second time. ALT-C will then toggle you between
the two file hashes.
If you have AutoCopy enabled, a small report, with file names,
hashes, and comparison result will be deposited in your clipboard.
simple checksum 0.8.2.3 [current release]
+ If you drop a file onto simple checksum's input and there is already
a hash in your clipboard, simple checksum will compare the hash of
the dropped file with that in the clipboard and report whether or
not they match (rather than report the hash string - if you need
that, IT'S IN YOUR CLIPBOARD!)
This makes it a no-brainer to compare the hashes of download files
with the hashes published on web sites, simply copy the hash from
the page (Select it, Ctrl-C) and then drop the downloaded file into
simple checksum. TADA!
NOTE: simple checksum will automatically switch between MD5 and SHA1
depending on the type of hash in your system clipboard.
NOTE: If you have Auto-copy-to-clipboard enabled, it will not
activate when comaring hashes with the clipboard, your original hash
will still be there after the operation.
+ Reduced memory usage (unused pages are now freed when hiding with
the tray icon, as well as the usual minimize button).
+ Improved ToolTips, reflecting new functionality.
+ Added startup message about the application menu (so folk know it's
there). You get this only once.
1.1.4
+ Added a preference for individual_hashes, which can now be set
permanently, if you wish. This is the same as passing
"i" in your
switches.
* Fixed a bug (bugs) where certain checksum options set in checksum.ini
were fixing that behaviour, even though the user had re-enabled the
default behaviour temporarily in the one-shot options dialog.
+ checksum now uses a more flexible and logical switch transformation
routine internally, so any switch that also has a preference in
checksum.ini, can now be switched *off* from the command-line, which,
depending on the preference, may be to enable or disable the setting,
for example..
Normally, root hashing is disabled. You can enable it by adding a
"1" to your command-line switches. You can also enable it *permanently* in
checksum.ini. IF root hashing is enabled permantly, you can *disable*
it, temporarily, by adding
"-1" to your switches.
In other words,
"-" disables a switch.
This behaviour is now true of all switches that also have a
checksum.ini preference, which is most of them.
Later preferences override earlier preferences, if applicable - the order
of preferences inside checksum.ini has changed to accomodate this logic.
Command-line switches override everything.
+ Command-line switches are now displayed dynamically in the one-shot
create options (thanks to seVen, and hashDROP for reminding me about
this feature!). You can add/remove switches there, too, and the many
checkboxes will update to match (after you move out of the switches
input). There's no real need for this in the verify one-shot options.
+ Added the absolute_paths setting to the one-shot options dialog.
+ Added a one-shot options checkbox for beeps (aka.
"audio alerts").
You can now get to all the create switches via the one-shot options
dialog. No more Windows Run dialogs!
+ Added a new
"help_tips" setting, for folk who know what they are doing
and don't need or want the helpful pop-up tooltips in the one-shot
options dialogs (applies to both create and verify one-shot options).
+ There is now a switch for the
"Open log folder on errors" preference, so
you can enable/disable that on a per-job basis, if required. The switch
is
"g", think
"Go To Errors".
Just like the other switches, if open_log_folder_on_errors is enabled in
your checksum.ini, you can pass
"-g" to disable it for a particular job.
~ The
"open_log_folder_on_errors" preference is now more correctly named
simply
"open_log_folder", as it also works if there were *no* errors,
but you have enabled
"log_everything".
Basically, if a log was created,
"open_log_folder" will activate at
the end of verification, or not, depending on your setting. checksum
will automatically upgrade your checksum.ini file and import your old
"open_log_folder_on_errors" setting.
~ The
"open_log_folder" setting will now also activate in quiet mode. If
you don't want this, pass
"-g" in your switches, or disable it in your
checksum.ini.
* Fixed a bug where checksum would beep on completion when creating
hashes, regardless of your beep settings.
* Fixed a bug where checksum would unexpectedly delete a root hash file
where it was asked to synchronise to regular folder hashes. This
behavior isn't so bad, it was simply unexpected. checksum will no
longer delete such files, so you can keep both, if required.
* Fixed a bug where synchronizing a root hash file could get you
duplicate hashes.
+ checksum will now check for all possible path variants before
synchronising a (root or folder) hash file, not just the currently
used variant.
Possible variants are; 1) full, absolute paths, 2) regular relative
paths, and 3) UNIX ./ root paths, and any combination of these. Also,
it's possible that root hash files could also be folder hash files.
checksum will check for all possibilities before adding a new hash.
Although I have improved the speed at which checksum interrogates
hash files for possible matching entries; it will always be quicker to
simply create a fresh hash file (perhaps after verifying the existing
one).
Actually, I've now re-written this to be *much* faster, so it should
now be quicker than doing the (verify + create fresh) task manually.
~ checksum.ini now uses
";", rather than
" as its comment character. ~ You can now leave the unix_hashfiles pref setting blank, if preferred.
* checksum will now correctly pop-up the completion dialog when a job
took under 0.01 seconds to comlete, and long_operation is set to 0.
+ Added a preference for
"always_sync", which is just like adding the
"y" switch to your command-line. Now you can set this permanently, if
you wish. Like the other switches, you can disable this temporarily
with
"-y", which would bring back the
"File Exists!" dialog.
~ checksum will now notify you if it switched your hash file extensions
from extensioned to extensionless, and vice-versa. For example, you
stopped using extensions, and during a re-hash, a file was renamed
from
"file.ext.hash" to
"file.hash".
* Fixed a bug where creating individual checksums of files on read-only
media would fail to create a hash file in the fall-back location.
~ Under fallback conditions, checksum will now recreate the *entire*
directory structure inside the fallback location, the root folder
being named after the letter of the drive, e.g..
C:\path\to\fallback\D\work\audio\june\june.hash
This removes any potential confusion about which checksums are which,
where multiple hash files and/or locations could have similar names.
This also means you can't accidentally create duplicate hashes by
simply starting creation from a different root location inside the
read-only volume.
+ checksum will now check your currently open explorer windows before
asking you if you would like to open the fall-back folder after
creating fall-back (read-only) hashes. If you already have the
fall-back folder (or a sub-folder) open on your desktop, checksum
won't ask you if you want to open it (again). You need to have the
Explorer Folder Option >> View >>
"Display the full path in title bar" enabled for this to work.
+ Added a new preference for
"compress_logs", so you can disable this if
you don't want checksum to compress any logs it creates.
* Fixed a bug where checksum would report files as missing if they had
a checksum in their actual filename, e.g..
MyImage-47cb705498c9480cfb0cd4980c216d82.jpg
+ I've added a preference for
"ignore_folders" which works exactly like
"ignore_files", when creating hashes. Useful for RECYCLER, System
Volume Information, etc.
simple checksum 0.6..
~ Removed the preferences dialog from simple checksum - with the
creation of a more comprehensive application menu, and more HotKeys,
it had become redundant - all changes are immediately saved, anyway.
I got to remove a big chunk of code, too, which is always nice.
~ Changed Algorithm HotKeys from Ctrl+M/Ctrl+S to Alt+M/Alt+S, which
seems more logical for algorithm settings, are easier to get to, and
leave the path free for me to add a
"Save checksum file" option.
I'll use Alt for hashing and algorithm settings, and Ctrl for
application stuff.
+ Added a HotKey for
"Always on Top", it is Ctrl+T.
+ Added a HotKey for UPPERCASE hashes, it is Alt+U.
~ simple checksum's title bar now displays the application's 'short' name.
This is neater. Also, if you use a gradient title bar, this will
probably make the algorithm part of the title easier to read, which can
be handy.
+ When switching algorithms, simple checksum will now store the previous
hash, so if you switch back to the original algorithm, rather than
re-hash the file (which could be a large file, and therefore, slow),
the stored value is re-inserted, instead.
If you manually hash something, a string, etc., or perform a drag and
drop, even of the same file, you always get fresh hashes (the file may
have changed).
+ You can now feed files to simple checksum via a regular file open
dialog. The HotKey is Ctrl+O.
+ simple checksum can now save hashes to a file. This is fairly
rudimentary compared to checksum's hash file capabilities, but I
figure if you have taken the time and CPU cycles to calculate a hash,
you might want to save it. The HotKey is Ctrl+S.
simple checksum will interrogate checksum.ini to discover your current
line-feed and carriage return settings before saving the hash file.
If you have created both MD5 and SHA1 hashes of a file, both hashes
will be stored in the (.hash) file.
+ The
"hash it" button now has a context (right-click) menu for the Open
File and Save Hash items.
+ Added System Tray menu items for Open and Save.
* Fixed a bug where the on_top preference was being saved to the ini in its
raw form (1/4 instead of 1/0) (note: simple checksum now uses true/false)
1.0 [first full public release]
+ Added an
"Edit Prefs (checksum.ini)" item to the tray menu, so you can
get this option easily, even with the Progress ToolTip disabled. Now
the tray menu and Progress ToolTip menu are identical.
0.9.24 [rc5]
* checksum can now use WAV files for notification, instead of PC speaker
beeps. You can specify a wav for success, and another for failure.
NOTE: if the specified wavs are invalid, checksum will revert to using
your peecee speaker.
I've dropped a few suitable wav files into the checksum extra files
area..
http://corz.org/windows/software/checksum/files/
I had this penciled in for v2, but got an early request!
~ Removed the dividers from the Explorer context menu in the default
install; if folk want those, they can uncomment the lines in setup.ini.
Apparently these cause issues (weird entries) on non-english language
systems.
NOTE: if you want to *remove* these dividers, simply uninstall checksum
before running the rc5 installer. i.e. do not
"upgrade". Your settings
in checksum.ini will not be lost.
* Fixed an issue where checksum's automatic ini upgrade could leave
unexpected comment lines tagged on to the end of the new updated ini.
0.9.23 [rc4 - 1st public beta]
* Fixed a bug where under certain (unusual) conditions, checksum could
fail to find your system's default browser, and crash. Now, even if
you don't *have* a system browser, checksum won't crash about it.
* Fixed a bug in simple checksum where OnTop status was being saved to
the ini file even when it hadn't changed. This could potentially cause
system warning dialogs when running simple checksum in portable mode
from read-only media.
* Fixed a bug in simple checksum where the current hash case setting
wasn't reflected in the prefs dialogs (everything should happen LIVE).
* Fixed a bug in simple checksum where the options dialog position was
only being read at launch time. If you moved your prefs, closed them,
and them opened them again, they would be at the old position.
* Fixed an inconsistency in simple checksum's preferences dialog, where
OnTop status was being immediately saved to checksum.ini, but
algorithm and case settings were only saved if you clicked
"okay". Now
all settings are saved immediately. This was always true of setting
preferences from the application menu.
In fact, all the preferences are now in the application menu (and
more), so the preferences
"dialog", per se, is redundant. However,
some folk may prefer this way of doing things, so there's no harm in
leaving it in simple checksum, for now.
Note: Ctrl+P also closes the preferences dialog, works as a toggle.
* Fixed a bug in simple checksum where the options window wasn't
dynamically updating its transparency setting when you altered the
main windows's transparency (if you had preference transparency
enabled in your ini).
* Fixed a bug in simple checksum where the hashing dll was being removed
on close in portable mode, even when you had specified in your
(checksum) prefs that it should stay put.
~ simple checksum now checks for out-of-range transparency, wonky
algorithm, and out-of-desktop window settings in the user's ini file,
and automatically corrects them.
+ In preparation for a release proper, checksum and simple checksum got
funky new icons, including a larger 48x48 size icon. I also did new
document icons, which now read,
"hash"..
+ Added unified hash extension.
Rather than create .md5 files for MD5 hashes, and .sha1 files for SHA1
hashes checksum can use a unified
".hash" extension for both type of
hash. This is the way forward for hash files, methinks..
checksum, uniquely (syat) interrogates potential hash files on a
line-by-line basis, and so will verify both kinds of hashes, even
mixed up in the same file; the file extension is irrelevant in
determining the format of the hashes contained within. Also, in the
future, there will likely be many more hash formats in general use so
it makes sense to stop the senseless creation of extraneous file
extensions in its tracks!
NOTE: if the unified extension is enabled, checksum will merge
(
"upgrade") existing hash files to match, so you don't end up with
both types, but only files of the algorithm you are currently using,
so if you are using the MD5 algorithm, checksum will merge only .md5
files in the path, not .sha1 files.
In the unlikely event of both .md5 AND .sha1 hashes existing in a
folder, running a second checksum create over the folder with the
second algorithm, and choosing
"Synchronize" from the
"File Exists!" dialog will merge the second file into the .hash file, one hash at a
time. Any new hashes will be added after that. Both MD5 and SHA1
hashes will then be inside the .hash file.
checksum still works with .md5 and .sha1 files exactly as it did
before, and the unified extension is completely optional. And once
enabled, you will still, of course, be able to verify all the old
types. This is
"extra" functionality.
NOTE: The unified hash extension is ENABLED by default. If you *need*
to use legacy .md5 and .sha1 files, simply disable this in your
checksum.ini
Hopefully other software writers, at least writers of software that
utilize hash files, will adopt this unified approach, but for now,
only checksum will create and recognize files with a .hash extension.
BETA TESTERS NOTE. The
"hash" extension will be automatically added
to your
"ignore_types" preference; you don't have to add it manually.
+ Improved checksum's cross-platform Line Feed handling, and introduced
a new master
"line_feed" preference.
checksum has always been able to open checksum files from any
platform (even mixed up in the same file), now it can intentionally
create them, too. At any rate, you can set a master line feed
character, which will be used in *all* file writing, that is;
checksum's hash files, text/html log files and music playlists.
You can choose between
"CRLF" (the Windows - and checksum - default
Line Break character),
"LF" for UNIX Line Feeds, and
"CR" for Mac
Carriage Returns. You only need this if you need to create hash files
to be used on a specific non-windows platform.
Most *nix tools can handle checksum files with Windows CRLF line
breaks, as well as all Windows tools, of course, so that's the
smartest default, but you may have other needs.
+ Made a slight alteration to the olive.css - errors are now more
clearly colored in olive logs.
+ Introducing... multi-hashing
With the unified hash extension working beautifully, there was nothing
to stop me; save the fear of throwing a spanner into checksum's
finely-tuned inner cogs, and some fun coding; giving checksum the
capability of *creating* files with more than one hash algorithm in
them. Welcome to multi-hashing.
SHA1 AND MD5 hashes in a single file. Yes, a clever inner wrapper
enables checksum to do its usual synchronization, and line-by-line
checksum interrogation, except rather than skip creating a checksum
because one already exists, it will examine the existing hash format,
and if the current algorithm isn't there, add the new hash.
So now we have the capability to
"multi-hash" (TM) our files, and
all inside a single unified .hash file. e.g..
28b7bef31e5fbda6cfb4a4990622c754 *golden boy ep1.avi
f0d474af22b9e29843c6aeeb554b88ecac3d04ca *golden boy ep1.avi
Multi-Hashing (patend pending) most likely has super-dooper security
benefits, too.
That's pretty much everything I wanted for a public release.
* Release delayed while I chase a few silly bugs I've recently
introduced.
~ Rather than simply append any legacy .md5 or .sha1 files onto .hash
files, checksum will now interrogate the file and add the old hashes
individually. This prevents all sorts of potential unwanted situations
and should make switching to unified hashing fairly painless, no
matter what kind of hash you've been using previously, even if you
used both - checksum will now synchronize everything inside a single
unified .hash file, and add all new hashes into that file, regardless
of their algorithm.
I've still not decided whether or not to make unified hashing the
default - I have a feeling that although it may alienate some people
(those who wouldn't realize/find out that this could easily be set
back to legacy .md5 files, if required), it's the way forward, and so
helping folk get there is good. Hmm.
~ During checksum's initial interrogation of potential hash files,
checksum will grab only 1MB of data from the file, which prevents
someone from running into memory problems by doing something crazy
like forcing checksum to treat an DVD ISO image as a hash file.
NOTE: checksum will still check the *entire* file for hashes, which
has no impact on memory usage, regardless of the size of the file.
* Fixed a bug where checksum could be forced to create a hash for a
non-existant file (which would be empty). checksum will now halt with
a warning if you send it any invalid path.
~ nix_paths paths (for one-file root checksums) is now disabled by
default
+ checksum's ini upgrade process will now retain ALL sections of the ini
file, even ones it doesn't know about. This enables writers of custom
GUI/wrappers to store their preferences inside checksum.ini, and have
them remain after a checksum upgrade.
NOTE: checksum produces quite a few different exit/error codes which
you can utilize in your applications. They aren't very clever, for
now, but if there's enough interest, I could work up a more precise
system. Let me know.
This is a good place to let you know about hashDROP, a rather cool wee
batch-processor GUI for checksum, which I got in my mail yesterday.
Thanks seVen! Good work!
For hashDROP, see here: http://hashdrop.50webs.com/
* Fixed a bug where your shirtware registration code could be
obliterated during an install, and if then inserted, would crash
checksum - I haven't paid enough attention to the registration aspect!
~ The Explorer context menu item for regular files has been changed to
simply
"checksum", which, as well as being neat and verb-like, should
prove less confusing if people are using the Ctrl modifier to switch
to verify mode;
"Create checksum" would be plain wrong.
+ checksum will now notify you if it applied any unified extensions to
legacy hash files.
0.9.22 [rc3]
+ I've brought back the status information to the final verification
dialog, in other words, it will now read..
CHANGED » foo.jpg
MISSING » bar.png
CHANGED » foobar.png
etc.
..as opposed to merely listing the erring files. This functionality
slipped away back in 0.9.17 when I created the fancy XHTML logging,
but some folk (myself included) missed it, and so it has returned.
+ checksum can now create music playlists (m3u or pls) with your
"root" hash files, as well as with regular folder hashes. This enables you to
create One Big Playlist for an entire music archive, or perhaps just
your trance albums, or whatever you like.
Note: the
"nix_paths" setting for root hashes also affects playlist
creation; both the direction of the path slashes, and whether or not
there's a
"./" at the start (true). The music players I've tested
don't mind which way round the slashes go, or whether or not you put
".\" at the start of the path, so it's probably cosmetic, though I
suspect some players might balk on back-to-front paths on one platform
or another. All this is only really worth noting if you share your
playlists with others, or other computing platforms around your
network. And even then, like I say, most media players don't care.
~ It may not be noted elsewhere - I'll pop it in the prefs, too - but
regardless of your checksum file encoding options, music playlists are
*always* utf-8 encoded. If you know of a media player that can't
handle utf-8, let me know. Same for the logs.
* Fixed a bug where under certain rare conditions (creating hashes for
files on read-only media, where no valid hashable files exist; for
example, they were all
"ignored" types) checksum would create an empty
checksum file along with the usual info file in the checksums folder
on your desktop. These items are now created only when real checksums
have been calculated for locked or read-only media.
~ checksum will now only attempt to set the compression bit on your main
log folder; that is, the one set in your main preferences. It will
still attempt to compress all individual log files, no matter where
they are created.
+ Added a setting for
"warn_color", which is the color the progress tip
will change to if there are errors. Previously, this was fixed at red.
~ Improved the content of generated info files (e.g.
"checksum.nfo")
which gets dropped when you create checksums for files on read-only
media. I also did a wee ascii
"checksum" logo. ;o)
* Fixed a bug where exiting checksum during the initial
"building list
of files" stage of checksum creation caused checksum to crash.
~ checksum will now always present a dialog at the end if you manually
exit the creation task mid-way. The dialog will also reflect this state,
as opposed to simply reporting
"All Done!".
* Fixed a bug where creating hashes on writable media with read-only
areas within would create many annoying dialogs, as well as fail to
leave the hashes on your desktop; the writeability test only being
performed on the root, to avoid noisy alerts as the system tries to
write to read-only media.
However, so long as the root location is writeable, checksum will now
perform a second test, locally, which could only fail through
permissions errors, and won't risk a second alert, but *will* tell
checksum if it's possible to create a checksum file in that folder. If
not, checksum will revert to leaving them in your fallback location on
a file-by-file basis.
* re-wrote some of the sync and logging code to streamline the internal
logic, and do error-checking to catch any
"unusual" conditions the
user might set up, for example, where you had already created a
checksum of some read-only files and then tried to sync it, or when
syncing a partial checksum file in a read-only folder, that sort of
thing. checksum will now intelligently handle all these sorts of
situations, and more.
* Similarly, added some error-checking to the DeTokenizer, so, for
example, if a special path @token is used for a
"name" preference, or
two path @tokens are used in the same path preference, or some other
crazy thing, checksum will handle it gracefully.
By the way, if multiple path @tokens are inserted into a single path
preference, only the first will be used; in this order: @desktop,
@userdir, @checksumdir; the others discarded.
+ I added a setting for
"fallback_folder", so if you'd prefer any fall-
back hashes to *not* be stored on your desktop, you can set some other
location here.
Note: you can use @tokens for the fallback_folder setting. Including
a new
"@desktop" token.
+ In the event of a read-only fallback within a writeable area, checksum
will now re-create the read-only directory structures in the fall-back
location.
Note: in situations like this, you could always use the
"1" switch to
generate a root hash that can be used to verfiy the read-only folders
in-situ. Just a thought.
+ Introduced
"fallback_level" setting.
This has existed as an ini hack for some time, but I decided to make
it a proper setting, and expand its capabilities some (as well as
change its name - ini hackers take note)
When checksum is asked to hash files on read-only media, it obviously
can't write the checksums in the local folders, so reverts to
"fallback mode", and leaves them on your desktop, instead (or
designated fallback folder). There are different levels of fallback.
Which level you choose depends on what you plan to eventually do with
your checksums.
Level 0 simply carries on with whatever switches you are using, except
inside the fallback location. e.g. if you are creating folder hashes,
you will find the read-only structures recreated inside the fallback
location, with individual checksum files in each folder, containing
regular relative hashes. If/when these read-only folders become
writeable, you can simply copy the folder over in one drag-and-drop,
to merge everything into the correct folders.
However, the default is..
fallback_level=1
Level 1 forces the creation of a single-file
"root" type checksum
file, with relative hashes for the entire volume (or whatever you are
checking). This is fairly portable, and will enable you to use the
checksums in a variety of ways, later; perhaps by dropping the file
into a copy of the original volume, or if it becomes writeable,
dropping it directly into the volume itself.
Level 2 forces the creation of a
"root" checksum with absolute paths.
If you are hashing a DVD, or similar, and you are CERTAIN that the
contents will always be at D:\ (or whatever drive letter you use),
then you can enable Level 2, and the entire path, including the drive
letter, will be inside the hash file, very much like using the
"absolute_paths" switch, except this will only kick-in in the event of
a fallback situation.
With level 2, just like absolute_paths, you can store this checksum
file anywhere, and it will always point to that same drive location.
If you think of other levels/strategies you'd like to see, let me know.
NOTE: the fallback_level setting only applies to fallback invoked by
read-only conditions in the ROOT of whatever folder structure to are
creating hashes for. If checksum discovers a read-only area within a
normally writeable volume, it will re-create the inner directory
structure inside the fallback folder, using whatever method you
specified on the command-line (basically, fallback_level=0).
In situations like these, you may prefer to create a root hash anyway,
then the inner (read-only) files could be checked in-situ, without the
need for fallback.
I realize that most folk will rarely, if ever need all this fallback
functionality, but nevertheless, I wanted it working.
~ checksum no longer uses the system registry to store the shirtware
reminder time. checksum.ini is now used for *all* settings.
It's worth noting that the
"portable" aspect of checksum - where if an
ini (preference) file exists next to checksum, it will use it - is no
more than a simple override which can be utilized in other ways..
In other words, administrators could distribute licensed versions
among their users with pre-registered preference (ini) files installed
in the user's home folder; which they are free to setup how they like;
or else completely override all settings with one central preference
file in checksum's program directory, with different permissions.
While I'm here..
++ CORPORATE USERS NOTE: When your organisation purchases a corporate
license, that license is transferable to ALL your employee's home
computers, and on up to nine computers around their home. You can put
checksum in their benefits package! Tell your boss!
* I chased a weird bug around for a while, where extensionless files
with numeric names were being occasionally missed. It turned out to be
a bug in one of my essential libraries. Along the way I made some of
the hash interrogation routines more robust and flexible, too; able to
handle more potential user slip-ups and possibilities, as well as
support new hash formats, for example, piped sha1 output from the *nix
openssl command (sha1sum output is also currently supported, though
undocumented).
* Fixed a potential bug where passing linefeeds on the command-line
would cause checksum to ignore the hash file completely. Of course,
getting linefeeds into the command-line is pretty difficult in the
first place but I managed it, so someone else will, too.
Actually, the real reason I
"fixed" this is so that I can use my text
editor's line-select (click in left margin) to send test command-lines
to checksum. Makes life easier, and also, fixes a potential bug!
+ checksum's final dialog will now better describe the state of things,
for example, when nothing was done, or the user quit mid-operation.
I've also added other error messages, for example, when a file doesn't
exist.
* Fixed a bug I recently introduced where one-shot options dialog
positions weren't being stored.
* Added a couple of missing switches to the main info dialog, and made
some of the other dialogs a bit smarter, for example, not reporting a
single error as
"errors", plural.
* Fixed a bug where checksum would tag a spuriuous
"ERROR >> somefile" onto the end of error dialogs if the user quit manually,
"somefile" being the file most recently checked when they quit. By the way, the
only time you should see the rather generic
"ERROR >>" message is when
files become unavailable for checking, for example, when you
disconnect a removable drive in the middle of verification, though
checksum will also let you know about this at the time.
+ If, for some bizarre reason, checksum files could not be written to
the original location OR the fall-back location, as well as warn you
of this problem, checksum will now list the checksum files which it
*didn't* write, as well as where it didn't write them to!
~ Simple checksum will, like checksum, now only store its window
positions if they have actually changed. This prevents system warning
messages when operating from a read-only drive, DVD, etc.
+ Added an option to enable multiple instances of checksum..
allow_multiple=true
Previously, this was always set to false, to prevent user's from
shooting themselves in the foot, trying to run multiple checksum
operations on the same physical drive, resulting in intense
disk-thrashing, and slow operation. However, if you know exactly what
you are doing, and remember to never run two copies of checksum at the
same time°, on the same physical drive°°, then you can now enable
multiple checksum instances; as many as you like.
° Or any two hashing processes. For example, if your torrent client
is hashing a big file, and you simultaneously do some hashing of
your own (with *any* application) on the same drive, your experience
will be very similar; noisy and slow. You could probably get off
with a quick checksum task, but be warned.
°° Remember, if a drive is split into two or more partitions (volumes),
ALL of those volumes are still the same physical drive, regardless
of the fact that they have different drive letters, and it would be
wise to run hashing applications on only one of them at a time.
+ Added a preference for
"file_extensions", for adding file extensions
to per-file individual checksums, e.g. the checksum file for
"foo.avi" would be named either
"foo.avi.md5" or the neater default,
"foo.md5".
This is assuming you are creating MD5 checksums, of course.
This has always existed as a preference, but I realized that there was
no actual ini setting to set it. You can, of course, use
"e" on the
command-line, and also enable it in the one-shot options, and though
it is ugly, you can now you can set it permanently in your ini, if you
wish.
Note: setting this in your prefs only takes affect when creating
individual hashes, but if you add
"e" to the command-line, you
automatically force the creation of individual hash files, which is
why, even if you set this to true in your prefs, it won't be checked
if you bring up the one-shot options. Good to know.
+ Added a preference for
"hide_checksums", which is just like doing
"attrib +h" on a file - checksum will hide all the hash files it
creates. This is just like adding
"h" on the command-line, except you
can set now it permanently (again, this was previously possible, but
had no official ini setting).
Note, if you have this set to true in your preferences, you can now
also add
"-h" to the command-line to disable it for a particular job,
if required.
* Fixed the unchecked boxes in the one-shot options for root hashing,
and hidden checksums (when these were set in the prefs).
+ Added another launch hotkey - Ctrl - which forces checksum into verify
mode, regardless of what was dropped on it.
NOTE: If you are using this HotKey from an explorer context menu, you
must wait until after you have activated the checksum menu item, in
other words, hit the Ctrl key right after you click the menu item.
+ If a particular task resulted in nothing being done; for example, when
you synchronized a folder, but there were no new hashes to add;
checksum will now tell you this was the case.
0.9.21 [rc2]
* Fixed a potential bug where checksum would crash if you attempted to
verify an extensionless hash file containing sha1 hashes. In the real
world, such a file should not exist, but, you ken fit like. checksum
will now correctly verify its hashes.
+ checksum can now dynamically switch between md5 and sha1 algorithms on
a line-by-line basis..
In fixing the previous potential bug, I devised a better way of
working with the hashes inside a file, and as a result, checksum can
now automatically work with md5 or sha1 hashes regardless of the file
extension (.md5 or .sha1), even in the complete absence of a file
extension (when called with the
"v" switch, checksum will treat any
file as a checksum file).
The upshot of all this is that checksum will happily verify hash files
with a mix of md5 hashes, even multiple legacy and regular md5 hashes,
as well as sha1 hashes, all jumbled up in the same file.
This clears the way for a unifying hash file extension, perhaps
".sum",
"sums", or even
".check". A user preference could be created
forcing checksum to give all hash files this extension, regardless of
the algorithm used. Feedback on this topic is welcome.
t z suggests
".hash". I like that, and according to filext.com, no
one else is using it. I feel a preference coming on!
* Fixed a silly bug where the writeablility test would fail if the
directory contained a file or folder called
"test". Oops! The test
file now has a slightly less generic name.
* Fixed a bug where checksum would attempt to place its hashing dll in
portable mode, even if it was already there. This could lead to system
warnings if checksum was operating from read-only or locked media.
* Similarly, checksum will now only write to the ini file if there were
actual changes. Previously, settings like ToolTip position, one-shot
dialog position, etc., were always recorded regardless of whether they
had changed or not.
* Fixed a bug where choosing synchronisation and root hashes together
would crash checksum.
* Fixed a couple of minor typos in the ToolTips.
* Fixed a bug in synchronising the one-file
"root" hashes, where
duplicate hashes were being created, checksum wasn't taking the
nix_paths setting into account, and the
"./" at the start of the paths
was confusing it.
* checksum will now correctly uncheck the one-file 'root' checkbox if
you disable recursion in the one-shot options. Also it will check the
recursion box if you choose one-file 'root' checksums. If you don't
require recursion, there's no point in using a 'root' hash file.
* Fixed a bug where checksum would open the log folder at the end of a
verify operation when no log was made (if this was set in the prefs,
and the user specified logging to a file on the command line/one-shot
options) For example, when logging only errors, and there were none.
+ checksum now supports Windows file names beginning with a space in
regular hashing as well as *nix
"root" hashing (which always supported
file names beginning with a space, if you used *nix root paths)
~ checksum will now force its one-shot options dialog to the front of
your windows. I suspect the SHIFT key has a special undocumented
capability in Windows, and places the launched application to the rear
of current windows. If you know this for certain, let me know.
~ By default, open_log_folder_on_errors is now set to true. This only
affects new installations, where there are no user set prefs.
~ By default, newly-installed checksum dialogs won't time-out (so you
won't ever miss them). If you want them to time-out, it's easy enough
to set this in your prefs.
0.9.20 [rc1]
* This release of checksum will mark it as the world's first
"Shirtware" application, which is like shareware, only better. You can basically
use it for free, (even the SHA-1 hashing) so long as you at least take
a look at the corz.org shirts (more details in my devblog). It's a
philosophy as much as a license, you see.
* The Shirtware part of the new version has been sticking me (read my
blog for more details), and after coming up with this new, more
fitting form of software license (fitting! gettid? hahah!), I knew I
needed something ultra-juicy; not only uber-cute and concise prose,
but a viable system or set of dialogs to present the text; this
version will be the first that has NO TIME LIMIT, and is therefore
free to roam the earth unchecked, for ever.
(it's often when I'm releasing code and writing notes that I reveal my
workings - these things matter to me, and the odd beta tester bugging
me about the latest release, is a small price that I am happy to pay
for the time to get it right.)
This is now done, and as soon as I can get the shirtware shop up to
the org, I'll release this version, probably nicknamed
"rc1", with a
view to calling it v1.0, letting it loose on the world.
* Fixed a bug in the installer, where it would place checksum.ini.new
files during an upgrade. This is no longer required; when new versions
are installed, checksum will automatically upgrade its preferences
file. You may now instead see
"checksum.ini.old" !
* Fixed a bug where verifying a one-file
"root" hash could cause errors
if there were other hashes in deeper folders. If you want these checked
in addition to the root hash, use regular recursive verification.
* Fixed a bug where
"Yes to All" and
"No to All" buttons appeared in the
"checksum found" dialog when creating one-file
"root" checksums.
* Fixed a bug where duplicate hash entries could be created when syncing
a root checksum file.
* Note: if you choose to create
"root" hash files, checksum will assume
you want to recurse. Otherwise, what's the point?
* You can now choose whether or not to use UNIX-style paths when
creating root hashes; that is, beginning with
"./", which checksum and
most UNIX tools understand, but other Windows utilities might not. It
goes without saying that checksum can verify both varieties.
* Fixed the auto ini upgrading, it will now upgrade your ini file even
if it finds no version number there (this only really applies to beta
testers with ini files from before there was a version setting in
there)
* Fixed a bug where *nix hash files with extensions like
".txt" weren't
being recognised as hash files during recursive checking.
* If there were errors during verification, and they were logged,
checksum can now (optionally) automatically open your log folder for
you.
* Fixed some internal spelling errors inside checksum-produces files and
dialogs.
* Fixed a bug where under certain conditions, the tip window could open
off-screen.
* checksum will now allow you to verify md5 checksum files with any name,
should you wish to. Use
"v" on the command-line, or input in one-shot
verify options dialog. This is in addition to checksum's ability to
automatically handle configurable *nix checksum file names.
* Fixed a bug where altering the verify path in the options from a file
to a folder wouldn't work. Now user changes are respected.
* Fixed a bug where checksum would fail to find hash files if you
switched the path in the verify options dialog from a folder to a
file. checksum will now respect whatever path is entered there, and
verify it, even if it is a single file with a non-checksum file name.
* checksum will now warn you about non-existing paths in the verify
options, and will not proceed if they are invalid.
* Fixed a bug where bringing up the creation options for a single file,
would enter the file's path into the folder input box, rather than the
parent folder.
* checksum will now accept drag-and-drop of files and folders in the
one-shot options dialog for both create and verify operations. Verify
accepts either files or folders. Create accepts folders; dropping
files onto the folder input of the create options will input the
folder part of the path, and add the file's name to the file masks
list, should you actually wish to hash the single file.
checksum will also add a single file name to the file masks drop-down,
if the one-shot options are activated via single file hash creation.
note: if you do select this single file mask, checksum will
automatically name the hash file with the file's name, rather than the
parent folder, exactly as if you had actioned it directly from the
explorer context menu.
* I notice that older ini files contain notes that are worded in such a
way that they may be re-imported into later ini files by checksum.
This in no way affects anything, other than you might see a couple of
unusual lines at the end of your [checksum] preference section,
specifically the UNIX checksum name(s)section. Feel free to delete
those. This will only affect beta testers.
* Fixed a bug where checksum would upgrade the ini, even if the ini was
brand new. This caused no errors, as such, but meant you had a
"checksum.ini.old", as well as a
"checksum.ini", where previously
there was nothing; slightly confusing.
The only time you should ever see this now is if a) you genuinely had
an old ini file, or b) I forget to upgrade the version number in the
built-in version.
* Fixed the broken shoutcast playlists. Very mysterious. :/
* My installer now has the capability to issue a license agreement dialog
during the install, checksum uses this facility. You only see it
during install, not during upgrade or re-install.
* Fixed a bug in simple checksum where the options dialog would always
open with the uppercase box unchecked, even when uppercase hashing was
currently enabled. I think I was subconsciously trying to discourage
UPPERCASE hashes.
* simple checksum will now switch the case of the input box, live,
whenever you switch between upper and lowercase hashes. Also, if you
do this from checksum's built-in application menu, it will also select
the entire hash string for you afterwards.
* If you switch algoriths, simple checksum will immediately re-hash the
file/string with the new algorithm.
0.9.19 [private test build]
* checksum will now compress the log folders using Windows built-in
folder compression (if they aren't already; and assuming your system
can do this, and compact.exe is somewhere in your path - very likely).
This can reduce the space your logs use by as much as 75%.
NOTE: if your log folder also happens to be your checksum program
folder; the logs inside it will be compacted, but that folder will
*not* be be set to auto-compact. It's better to keep logs elsewhere.
* checksum will now automatically update your ini file when you upgrade.
Thanks to seVen for reminding me about this forgotten to-be-feature!
As well as any new settings, it also means you will get my updated
notes, which continuously improve as I go along.
* I put the checksum icon into the about box. The regular one is nice,
but this makes more sense.
* The context menu
"edit checksum.ini" option is now named
"Edit
Preferences". It still does exactly the same thing.
* Made some MAJOR speed improvements to the checksum file building
routines. En-Joy!
For coders and md5 geeks, a story..
Because checksum uniquely checks every single line of each file for
its checksum format, and supports mix-and-match formats in a single
file (yup!), the initial
"building/extracting" stage has always
taken some time; roughly two seconds per 1000 checksums, which
though not a lot, can mount up.
I decided I wanted to cut this time, and set about to make this
mix-and-match support optional; split out the routines - checksum
looks at the first line only, and establishes a format type, and
from there on, assumes that all following hashes are of the same
format. Having got this working, and feeling rather chuffed with
myself, I started to test these staggering speed differences I was
expecting to see, after all, with this mix-and-match checking
omitted, a lot of code would now be bypassed on each and every
line, surely saving oodles of time over many files..
The differences were almost non-existent.
Somewhat puzzled (though secretly happy that my mix-and match code
must be pretty darned efficient) I started to investigate..
The way checksum verification operates is to scan for hash files
(
"Building file list for so-and-so..."), read all the lines in them,
decide what format each line is, Solaris, whatever, and pluck out the
file name/hash pair for that line, store it in an array (basically a
list) (the
"Extracting hashes from so-and-so.md5" bit). Once the
complete array is built, checksum runs through it, comparing the
hashes from this list with actual hashes of the files themselves.
With me, so far?
The array begins empty, and then is increased in size, by one element,
each time a new hash is added to it. To do this, I use Redim(), to
resize the array. From working on my recursive file search functions
last year (used in everything, including checksum, and available from
corz.org/engine , so you can use them too - there is no faster nor
more accurate AutoIt recurse routine, syat!) I remembered that Redim()
was comparatively slow, and I'd instead opted to create a BIG *empty*
array, and then fill as much of it as needed as I went along. I don't
remember exactly *how* much faster this approach was, but I do
remember it was faster; so I decided to use a similar approach in
checksum itself.
So checksum now creates an initial empty array with enough
capacity for the whole checksum file (by first calculating the
number of lines in the file); small array for single checksum
files, potentially HUGE array for HUGE checksum files. Then I
tested again..
O M F G !
My current test folder (a 7000+ file python install) used to take
14 seconds to build and assimilate all the hash information before
beginning the actual hashing. With the new system, that time is
now 0.34s. Yes, ZERO POINT THREE FOUR SECONDS! lol
So, erm, if you code with AutoIt, avoid Redim() at all costs!
While I'm here, I have to thank Tom Marriott for all the help with the
timing tests, I just don't have the patience to work with all those
brain-dead md5 utilities! AARRRGHHH!!! A couple of them are pretty
quick, though! *wink*
So, back to the original headline - MASSIVE speed improvements
have been made; and verifying hashes, even mix-and-match legacy
copy+pasted messed-up hashes, will be as fast as creating them in
checksum always was.
By the way, the actual internal limit on the size of a checksum
file is 8,388,606 lines, which would be equivalent to a checksum
file around 700MB in size! If you ever manage to create a checksum
file this big, checksum will then use almost 70MB of memory for
the initial empty array. Of course, in the real world, checksum
files are nowhere near that big, but if you fancied hashing the
entire internet or something, now you know. ;o)
* Fixed a bug where binary files matching the UNIX MD5 filenames (with
wildcards, e.g. md5sum.zip matches md5sum*) would crash checksum, which
should no longer happen.
checksum will now also attempt to interrogate the files, and NOT pull
hashes from them. This still isn't foolproof, though checksum does
perform a couple of rigorous checks. I've also made the default UNIX
types in the ini file more sensible, so this situation is less likely
to occur in the first place -
"md5sum*" is a bit loose :/
If bad files occur in the middle of a multi-file operations, checksum
will carry on, inform you about the bad files at the end of the
operation.
* Added the total operation time to the title bar of the final verify
dialog. This will be longer than the time (if any) in your logs, which
is the raw hashing time, only, generally much smaller.
I should note, that certain other MD5 utilities tally this raw hashing
time, and present THAT as the total time taken (which, in reality
includes lots of other operations; file-handling, logging, and so on).
If checksum started doing this, we would have an instant 1000% speed
increase! Perhaps a
"Weekly World News" version could have this. ;o)
* Checksum will now post a dialog at the end of a hash creation
operations, as well as verification. Reason being, if you are a
speed-freak, and have ToolTips disabled, there is no way to know the
final time, which you NEED to know, right? Now you can.
This also applies to any final error dialog you might get.
Standard
"long operation" rules apply, so it will only show after
however long you have set as a long operation.
I should add; I always meant to have a dialog at the end of checksum
creation, but hadn't gotten around to it. Running with ToolTip disabled
for the recent speed tests reminded me.
* I went back into the dll for the first time in months, to fix a couple
of issues with the C++. checksum will no longer crash when attempting to
md5 hash in-use locked files (such as Perflib_Perfdata_***.dat - if you
were hashing your Windows folder, for example).
In fact, I switched its file-handling routines to match my SHA1 code,
and now, as well as being uncrashable (heh, we'll see) it's also
*slightly* faster, though you would need to be performing some fairly
accurately-timed tests to notice any real change. Also, just like the
SHA1 hashing side of things, even with locked and in-use files, you
will always get your hash.
* checksum will, by default, create/verify hashes for up to only a
million folders, and up to a million hashes per folder - which
preserves ram. If by some slim chance you have more than a million
folders to check at one time, or folders with more than a million
files in them, you can override this by hacking..
max=3000000
or whatever you like, in your ini, up to a maximum of 8388606.
Probably no one will ever need this; I just like to add this sort of
hackability for those special, one-off cases. Note: this will use more
RAM, at least 10MB per extra million you add above the default (of one
million). If you have gobs of RAM you could conceivably set it to the
max and forget about it.
* During pre-release tests I realize that the installer still places a
"checksum.ini.new" file on upgrading, darn! - checksum no longer needs
this capability; I'll need to make that disableable (is that a word?)
in the installer, before it goes out to the beta testers. I guess this
will be a private build, then.
0.9.18.1
* checksum now posts what it is doing when pulling hashes from a file,
this fixes the bug where you would see a blank ToolTip while pulling
hashes from a root checksum (which can sometimes take a few moments,
if it's a large file - for regular checksum files it passed too
quickly to see)
* checksum will now allow you to exit while pulling hashes from a file.
Previously it would ignore the request.
* Apparently, most other Windows hashing utilities can't handle utf-8 :/
Seems weird, when Windows has been UTF-savvy since the Nineties. So,
in case you need to share hashes with users of ANSI-bound (probably
American) MD5 utilities; I have made utf-8 optional, in the prefs..
utf8_hashes=true
* checksum now handles ejected and missing drives in a more graceful
fashion.. If it encounters a missing file, it checks the status of the
drive, and if it isn't available for some reason, will post a dialog
warning the user of the problem, and asking if they wish to continue
(after re-inserting the disk, perhaps), or quit.
This also works if you are verifying a checksum file on a fixed drive,
with absolute paths to an ejectable drive that is, or becomes
unavailable.
It should work for any drives that become unavailable, including
network volumes, though I haven't tested this myself, yet.
Two new style classes now exist to facilitate this error condition
(indeed, any error condition that may yet be coded into checksum).
They follow the same format as the other status styles, and are..
"ERROR", and
"checksum-ERROR", the latter being for the message
itself, which will appear where the file path normally would.
* Fixed an issue where a double-path was being logged when verifying
checksum files with absolute paths in them.
* Fixed a bug where toggling the Progress ToolTip from the tray while
the options were open, would bring up an error. Those options won't
appear now until they are supposed to.
* checksum now uses my Standard About Box, and shows the version
information in the dialog (at last!).
* checksum now posts certain dialogs as modal, to prevent them dropping
behind other windows, which can be annoying.
0.9.18
* Fixed the errors in the tray; you will no longer see HTML there if
you are creating HTML logs. The list should now be much neater, too.
* checksum will now write hash files, playlists and logs as utf-8. I'd
assumed (always a mistake) that this was automatic on XP, but it's
not. This will be most noticeable in the logs, where the names of your
Eastern European folk albums will once again look authentic!
* Increased the timer display granulation in the html logs from two
decimal places, to three - checksum was finishing so fast, that the
finish time being less that 0.01 seconds, would become 0.00 seconds,
which = false. The timers are now also more accurate.
checksum will now always print the time, up to three decimal places.
NOTE: you will still occasionally see
"[checked in 0s]", for instance
when all the files in a checksum are missing - that's simply because
the hashing was completed in under 0.001 seconds. No way I'm
displaying four decimal places to catch these! Be content in the
knowledge that the operation was
"very very fast indeed".
* The log timers have been fixed. In truth, I'd tagged this on at the
end of the day, remembering that a couple of beta testers had
mentioned they'd like to see times in the log - and hadn't really
thought it through. After a big spliff on Sunday night, I could
immediately see the flaws in my previous logic, and set about on a
whole new scheme of internal logging. In short; the log timers have
been fixed.
* Fixed the div-escapees. Under certain conditions, hashes in the log
would escape their divs, and be box-less. Fact is, I ripped out the
HTML creation code and re-coded it. It is now far more robust. It
should be noted that even when some hashes escaped their divs, the
output was still 100% XHTML Strict!
These internal changes will also make it easier to collect and add
other data to the logs. What would you like?
* Log append in text mode now works as expected (the setting had gotten
reversed!)
* The plain text logging also uses the same system (the only difference
being the final parsing; either to plain text or html). Thanks to
this, the plain text logs will now display the checksum file checked,
and the hashing times, just like the HTML logs; and future data types
can also be inserted into the text logs just as easily as with the
html logging. So, what would you like?
* checksum will now once again present you with a dialog for errors,
even when log-to-file is enabled. I'd broken this earlier. If you
want no dialogs, simply pass the
"q" switch. I also improved the
logic and file list in the final error dialog, which now thoughtfully
also tells you where the log *is*, just in case. I may make it instead
present a.. [yes/no] would you like to open the log?
NOTE: The final dialog can be taken quite literally..
"A log WILL be created here.." In that, it hasn't happened yet. Only when you click okay, will the log
itself be created. This is by design. For instance; if you have set
log append to true, but realize you prefer this in a new log, you can
rename/delete/move the old log *before* you okay the dialog, and and
you will get a fresh log.
* In the plain text logs, passed files are logged.
"Passed:: C:\blah..." The
"::" being what I use as a comment in batch files and logs, and so
displays in faded text in my editor, just like the passes in HTML logs.
This also keeps CHANGED, MISSING, and Passed entries nicely lined-up.
If you want this plain text highlighting, but
"::" isn't a comment
initializer for .log files in your text editor, it's probably easy
enough to add. Check your prefs for syntax highlighting for the .log
file type.
* Thanks to the new internal logging structure, we can now go
"back in
time", and do things like give the title of the checksum a different
color IF there were errors inside. So I did that. It's a new CSS class
"has_fails", so you can either have them show as red (or whatever) or
the same color as the other checksum titles. By
"titles", I mean the
clickable header <h4> text that is the name of the checksum file itself.
Similarly, a new css class
"day_fails" can be accessed to give the
main <h3> header/title (date/time verification began) a different
color, if you so desire.
If you log everything, you can now see at-a-glance which days, and
which checksum files within those days, have errors inside. Handy, if
you use it.
* The
"f" switch will now correctly set the
"log to file" checkbox in
the verify options dialog.
* Shortened the length of the error beep to 20 milliseconds.
* You can now have full paths to the checksum files in the titles of the log;
handy if you use a generic name for your checksum files. In your ini..
hashfile_paths=true
It's quite possible that with hashfile_paths set to true, the title
could get *very* large, so checksum will thoughtfully truncate it to
however long you specify..
truncate_at=72
note: the truncation occurs in the middle, so you can always see the
name of the actual checksum file.
* Styles can now be embedded within the log files themselves, if you so
wish. You master checksum.css will be used as the template for the
embedded styles, so you can edit that, and all your logs will contain
your new styles
embed_styles = true
* The master_styles setting now accepts true/false, as well as the
location of an overriding master style sheet. The blank setting
is deprecated, though will still work (at least for a while)
It is more logical now; the style settings all accept the same
parameters; either true/false, or the location of a style sheet.
e.g. if you wanted ONLY embedded styles, you simply set fallback
and master styles to false.
NOTE: if you set embed_styles = true, you don't get the built-in
.status { float: right; } style (which is the only style the logs
include) so you need to ensure you have that covered in your css -
it's in the default sheet, anyway.
* Added Enable/Disable Audio Alerts menu item to the tray, and ToolTip
context menus. Handy if you have a lot of errors, or want peace. This
setting is permanent; or at least, until you change it.
* Added a separate setting for beep frequency. The old method of setting
the frequency was funky, but this is clearer, and makes it easy to
implement user-toggling, which I did.
* Re-ordered the ini file - putting all the new settings into related
groups. It wasn't too bad, but should now hopefully be more logical.
I also added lots of notes and default settings records, to make it
easy to revert anything you tweaked.
* Fixed the options dialog position issue (it was sucking prefs from the
ToolTip, and often opening at the very edge of the desktop).
* Expanded the log location input box on the verification options dialog
it probably looks messy now (because it escapes its group) on anything
but flatish schemes (like mine is) and I'll likely end up redesigning
the dialog, to take into account all the new verification options. In
the meantime, at least you won't have to suffer the input's
infuriating smallness.
* If you quit verification in the middle of a checksum file, checksum will
now correctly report the time taken, up to that point.
* Display of times in the log is now optional, a new setting;
"display_times" enables you to switch it on and off. It's off by default.
* A new setting,
"total_times" enables you to have the total verification
time tagged onto the end of the checksum headers (<h3> date/time). It's
a bit ugly, so is disabled by default. But if you want this, there it is.
This is not the total time taken for the entire operation, but an exact
running tally of the time taken to process each individual hash.
NOTE: If
"display_times" is disabled,
"total_times" is also disabled.
ALSO NOTE: If you disable these logging timer prefs, checksum won't
bother to time individual hashes, and so there may ironically be a
performance improvement. So you have to ask yourself, are you more
interested in *seeing* the hash times, or the *actual* hash times! ;o)
The difference will be negligible, but still, food for thought.
Neither of these two new setting has any effect on the overall timer
which displays in the final ToolTip; a single, simple, overall timer.
NOTE: these changes also apply to plain text logging.
* At some point recently, a local path change in my own system meant the
.md5/.sha1 document icons weren't stored inside checksum.exe, as they
should be. They are back now. Running the installer (upgrade) will sort
everything out, and refresh your desktop icons, too.
* seVen sent me a nice olive theme for the logs, so I messed with it,
and made an olive version of the background image to accompany it, and
dropped it in the extras folder. You can set it as your fallback
style, or master style, if you like, or use it as a template for
embedded styles. It will also always be available here..
http://corz.org/windows/software/checksum/files/olive.css
You can see demos of the log output here..
http://corz.org/windows/software/checksum/files/checksum-example-log-output.html
http://corz.org/windows/software/checksum/files/checksum-example-log-output-olive.html
* I changed the location of the background image into the same folder
as the css files (sorry testers! any logs you made with the old version
will point to the wrong place - but I'll leave the image there for a
while, yet. If you really need a background image in those old logs, a
find & replace will fix them!)
I figured it made sense to keep all these resources together - as well
as the example logs, and css, there's also alternative css and reg
hacks in there. So I've made the folder accessible from the web, and
it becomes as kinda drop-box for
"extras". Help yourselves! ..
http://corz.org/windows/software/checksum/files/
* checksum can now prepend the (base)name of the path checked to the main
titles, so you get..
[2006] Rodrigo y Gabriela @ 2007-11-21 14:14:00
instead of just the date & time. If you log all your checksums for a
particular path in the same file, you probably don't want this behaviour,
but if you do, do..
path_in_titles=true
* By default, checksum logs will now open with all the sections closed.
Reason: if your logs start to get *large*, all those sections open can
slow down your browser's page rendering. You can, of course, click the
main title to open all the sections in one go.
If you prefer them open, use your own template.html (details below)
* Times in the log now have their own style class;
"log_times", rather
than simply being <small>text</small>, so you can have them really
tiny, or whatever you like.
* seVen (again - busy lad!) sent me updated versions of the portable
mode command processors; those handy drag-and-drop thingies that make
life powerful and easy on pen-drives, floppies (whatever they are),
DVD-R, and those kinds of places. Among other improvements, the
commands are now able to suck prefs from your checksum.ini, and even
understand some checksum @tokens, too. Impressive. Available in your
extras/ folder in the distro.
0.9.17
* You can now access the tray menu while the options dialogs are open,
as well as when checksum is actually doing something, as ever.
* You can now use the token @userdir in your log_folder setting, which
is transformed into your application data folder (where checksum.ini
lives by default). So, to use a folder in there called
"logs", do..
log_folder=@userdir\logs
Which is now the default setting.
* Made further improvements to the log path functionality, and logging
relative to the checked dir should now work as expected.
* (x)html logging. ;o)
Well, here it is! And I have to say, so far, it's working beautifully
and looking exactly as I imagined it would - including pesky Javascript!
All styles, color and position is controlled by CSS, and a default
style sheet is provided along with the new release (it is placed
automatically for you, but once done, you can edit/alter that to
suit your needs). More information about this inside your ini file.
A couple of new options are now available..
* log_format - chose from
"text" or
"html". The text logging is
unchanged. the html logging, of course, is all-new.
* append_log - rather than create fresh logs each time, append out-
put to an existing log. If you set this to true, and use your log
file name @tokens creatively, you can get automatic log rotation
on a daily/monthly/etc basic you could even have logs for each
particular checked folder, automatically rotating every month!
@tokens + append = free energy! Like I said, get creative!
There is still functionality to add to the XHTML logs, but the basic
page generation works superbly. I'll be adding more as time goes on.
NOTE: I did a fair bit of internal re-wiring for the html logging,
improved other internal structures, so this release is definitely
going to be classed as
"UNSTABLE" for now, though everything seems
to be working great on my own system.
About the css (style sheet)..
Even without any styles, your logs will still be formatted, and
have all the groovy expand/collapse action; they'll just look like
sh*t, that's all! To keep everything as funky as checksum is,
requires css..
A default style sheet should have been placed next to
checksum.exe. Originally I intended to drop the master style sheet
in your user folder, but as this location needs to be hard coded
into the logs, it's actually more future-proof to use checksum's
location (if you upgrade to Vista, you will no longer have
C:\Documents and Settings, for a start). This also helps in
portable mode, where checksum will intentionally forget what a
user folder even is!.
So, the master style sheet is next to checksum.exe, along with the
other auxiliary files. You can edit styles there if you want.
Better yet, leave it as-is, and make a copy into your logs folder..
The log files will import *three* style sheets, in order; starting
with a live sheet from corz.org (fall-back styles - should always
be available), followed by your default sheet (next to
checksum.exe), and finally, your local style sheet (next to the
logs themselves), if you have one. The first
"C" in CSS, stands
for
"Cascading", C! This behaviour is configurable. (see below)
You can easily override any and all styles in your *local* style
sheet. Or you can edit your master checksum.css as you like, and
also use extra overriding styles in local areas. Or whatever you
like! Don't like the log's cool background image? Edit your CSS!
If you don't want to use the corz.org fallback styles, in your
checksum.ini, do..
fallback_styles=false
If you want to specify your own master style sheet, you can do
that with..
master_styles=file:///C:/Design/styles/checksum.css
.. or a regular http://address, or whatever you need.
* One final note about the log files (for now): checksum drops its
header template into your temporary folder while it is working,
BUT, if you happen to have a file called
"template.html" next to
checksum, it will use that instead. You might want to make better
JavaScript, or something. To get started, simply copy the output
from a log file, down to..
<!-- end header template - checksum will take over from here -->
..and edit to your heart's content. Have fun!
* Fixed up logging switches for verify dialog.
* The time taken to process each checksum file is now recorded in the logs
0.9.16.1
* Fixed a typo (which caused a fatal error) in the quit mode routines.
* Fixed a bug in the relative logging - apparently, when the folder
containing the running application is a drive root, the system/autoit
adds a
"\" backslash when returning its path. How thoughtful! *sigh*
I also improved other error-checking in the log_path routines, so it
should now work under all conditions.
0.9.16
* Fixed a bug where if you created folder checksums on a write-protected
floppy disk, you would get a blank file called
"A" on your desktop!
* Fixed a fiendish bug I'd introduced in the one-file hashing. It will
now function as expected, regardless of whether it was invoked with
the
"1" switch; or automatically, as a fall-back for read-only media.
* seVen couldn't wait for me to get around to the XHTML logs, and
created a rather nifty utility to convert checksum's plain old text
logs into lovely html, with errors in red! Good work, Sir!
You can find log2html in the latest release/extras/logging/
To use, simply drop the application into the folder where your logs
are, and run it. Drop the resultant .html files into your web browser.
* Jon (the Wolfman) has been bringing some interesting bugs to my
attention over the course of the last couple of weeks. the most recent;
something that only appears when you use explorer to attempt to create
checksums on read-only media..
When checksum attempts to write to the volume, the system throws up an
error along the lines of
"can't write bla bla ... cancel, try again, or
continue", a bit like the old DOS errors. while the initial dialog is
unavoidable, checksum had started to throw up two dialogs, and if you
had existing checksums on the volume, THREE!
At most, you will now get one dialog. There's nothing I can do about
this one dialog, as far as I know; checksum needs to attempt to write
to the disk at least one time, to know whether or not it is writable -
a read-only volume won't necessarily have its
"read only" bit set, you
see. In fact, it almost never will.
* Added a switch for Windows Absolute Paths (i.e. *D:\path\file.foo)
It is
"k" (Think 0K [Kelvin] - Absolute Zero!) This is only for
one-file, aka.
"root" checksums. If you have this set in your prefs,
"-k" will disable it.
* Fixed the verification tooltip. It now correctly displays the checksum
file being processed and the basename of the file currently being
checked, not the *full* path of the file, which could go clean off
your screen, and then some!
* fixed a bug I'd introduced in the last version where you would get a
double log. (I'm preparing the ground for the XHTML logs, see!)
* The web page should be pretty much up to date now. There's a nice,
fairly ordered list of all the switches there, handy if you are
cooking up something special.
0.9.15
* Added the
"1" switch to the switch checking routines. I could have
sworn I'd done that! Setting one_file in your ini worked fine.
* If you want, you can set a single generic name for your checksum
files. This obviously only takes effect when hashing folders.
Just like the log names, you can use @tokens in this name, so it can
be dynamic-generic! See log_names (below) for a full description of
the available tokens. The default setting is blank..
hashfile_name=
.. in which case checksum will name the hash file after the folder
it refers to. This is functionally identical to..
hashfile_name=@item
When creating your own names, you do not need to add an extension;
the correct extension (.md5 or .sha1) will be added automatically.
(unless, of course, you want two extensions, i.e
".my.md5")
* I uncovered an interesting bug in one of my supporting libraries
which manifested when creating folder checksums inside a folder
called, for instance..
I:\work\dev\all files\test\a
My GetParent() function was removing the
"\a", as expected, but
removing it from
"dev\all files", making
"devll files", unexpected!
This resulted in logs on your desktop instead of inside the checked
folder (unless you had specified a log location)
I've now written a more robust GetParent() function.
(btw, to users of
"corz_essentials" function library - upgrade!)
* Fixed a bug where, during folder hashing, empty checksum files were
being left around for folders containing only ignored files. No,
this was not some crazy corz.org advertising ploy!
* Fixed a bug I'd introduced in the last version, where under certain
conditions (which is a programmers way of saying
"most of the time")
the timer was being reset periodically during creation operations.
Actually, it only happened when you were there were existing checksum
files. But it was a good gag. ;o)
There were a couple of other foibles with the timing. It should all be
nailed down, now. Let me know if you see any strangeness!
* removed the erroneous log_folder entry in the default checksum.ini.
It's very likely that
"C:\Documents and Settings\cor\Desktop\wirefiles" doesn't exist on your system. sorree. :/
Truth is, I'm still getting to grips with trying to test all sorts of
scenarios on a single machine, and settings from one ini have been
seen to drift into another. I guess I should leave all this testing
to the, erm, beta testers. Good thinking cor! :roll:
* There is now a setting to tweak the magic stretch value of the tooltip.
* checksum will now correctly remember the position of the options
dialogs after the verify option. Previously it only remembered it
after creation options (both use the same setting). No one noticed.
* If you select multiple files in explorer and choose checksum from
the context menu, checksum will behave as the previous version,
presenting an error for the multiple launches, except, it will now
present only one dialog, regardless of how many items you selected.
* Added a setting for pause on completion
Normally, if you have the ToolTip enabled, checksum will pause at the
end of an operation, so you can see the final result. You can now
change the length of that here, in milliseconds. The default is 1000
(one second). Set pause to 0 to disable the pause, or pass 'n' (for
"no pause") on the command-line.
This was mainly added for seVen's cool command processor scripts; so
you don't have to endure a pause after each file in the queue; but
it's also a handy setting to have available, generally.
* Fixed a bug where checksum would refuse to quit if you asked during
a scan (building lists of files to hash, or verify)
Note: checksum will never exit during an actual hashing operation;
it would be too speed-costly to code this; if you are hashing a large
file, you must wait until it is done. It's okay to quit in the middle
a multiple operation, between files, so to speak.
* checksum will now attempt to bring its window to the front when
launched (if it isn't already) - holding down the SHIFT key in
windows explorer seems to do something to the z-index of desktop
windows preventing this happening naturally, though this could be
my own system doing this. At any rate, it's smart to do this.
* On verification errors, checksum's ToolTip windoid will flash red.
It will also turn red (with white text) for the final error message.
* Wrote some rudimentary notes and info for seVen's new D&D command
processors. There are currently in /extras/command processors, and
are designed to assist you when running in portable mode, or otherwise.
more information can be had in the local .nfo file.
0.9.14.1
* fixed an issue where if you attempted to launch more than one copy of
checksum simultaneously, you would get a cryptic error message. You
are, of course, supposed to get a terse, informative message.
A silly last-minute mistake; the new dialog time-out setting applying
to a dialog that could pop up before the location of the ini has even
been ascertained. Oops. This dialog will now time-out in 30 seconds
(as it's user-activated, it's unlikely to need to be up any more than
a moment)
0.9.14
* Using the 'q' switch (quiet mode) no longer affects the tooltip,
you can enable/disable that as required
* You can now enable/disable the tooltip with 't'/'-t', respectively.
This will override your ini setting, whatever it is.
* fixed a bug I'd introduced in the last version - leaving the
writeablity tests lying around. oops! 0.9.13 was unreleased, anyway.
* checksum will no longer allow multiple copies of itself to run
simultaneously. Apparently (and I can't replicate this - probably due
to my explorer context menu customizations - 'peek', I think) - if
you make a multiple selection and then choose checksum from the
context menu, it would open multiple copies, which would all jump into
action, working on a heap of files in the same directory. If these
were large files, this could have SERIOUS speed implications, just
like hashing p2p-downloaded files, the disk heads will be thrashing
around like crazy, doing a round-robin on the data-stream. Yikes!
Now checksum pops up a dialog for any extra launches, informing you of
the boo-boo, and exits.
* you can now choose to have checksum *not* notify you of success,
unless it was a
"long operation". Just how long constitutes a long
operation, is up to you. Remember, if there are failures, you always
get notified somehow, so this fits in with checksums broad design
goal of
"no news is good news!".
* At the end of a verify operation, the success/failure status is
displayed in the final tooltip.
* the log_file setting has been deprecated - checksum will now name files
automatically. However..
* You can now set a permanent folder for logging, if you wish.
leave blank to log to the top-most folder checked (the default)
if you specify a full path, checksum will use it.
if you specify something else, checksum will assume you wish a folder
named this to be created/used in the top-most folder being checked.
In other words, you can set a relative, or an absolute path.
* There is also a special token
@checksumdir
which you can use to specify checksum's current directory (where
checksum.exe is), so if you were running off a pen-drive, and had
a copy of checksum inside a top-level folder called
"checksum",
and wanted checksum to create a folder *inside* there called
"logs" (or use it, if it already exists), you would do (in your ini)..
log_folder=@checksumdir\logs
* And finally for logging (for now), you can configure the name of the log
itself..
As well as typing in a regular file name, such as
"checksum.log", you
can use cool @tokens to insert the current..
@sec seconds value. from 00 to 59
@min minutes value. from 00 to 59
@hour hours value, in 24-hour format. from 00 to 23
@mday day of month. from 01 to 31
@mon month. from 01 to 12
@year four-digit year
@wday numeric day of week. from 1 to 7 which corresponds to sunday through saturday.
@yday numeric day of year. from 1 to 366 (or 365 if not a leap year)
There is also a special token: @item which will be transformed into the name of the
file or folder being checked, and @status, which transforms into the success/failure status
You can mix these up with regular strings, like so..
log_name=[@year-@mon-@mday @ @hour.@min.@sec] checksums for @item [@status!].log
Put quotes around it if you like, though it doesn't matter.
The @status strings can also be individually configured..
status_fail=ERRORS
status_success=100% AOK
With the defaults, above, the final log name might be...
[2007-11-11 @ 16.43.50] checksums for golden boy [100% AOK!].log
chew on that, seVen! ;o)
* your status strings will also be tagged onto the end of the final ToolTip, so you can
check the final status at a glance; handy if you have the audio disabled, or are deaf.
* checksum will now correctly add the 'f' switch automatically if you add
the 'l' (log everything) switch.
* checksum will now correctly add the 'i' switch automatically if you add
the 'e' (file extensions) switch.
*
"beep_on_failure" has been deprecated in favour of
"beep_alerts"; reason
being, if you enable it; as well as failure beeps, checksum will emit
a final
"bebeep" (meaning; a slightly faster, double-beep - Hey! I got
that cool word from my camera's manual!), which will double in pitch
if everything was 100%. If you have long_operation set to a non-zero
value, this can be a handy background indicator of the status of the
in-progress and final verification status.
* checksum now posts the the item and total numbers, e.g.
"creating checksums: [folder 3 of 19][file: 2 of 264] movies\2001.avi" This also works when verifying checksums, though there may be bugs.
* If all this information annoys you, either disable the ToolTip, or simply
drag the tip over to the right-hand side of your desktop, positioning all
the bits you don't want to see, off-screen! It's quite nice running away
displaying only
"verifying [file: 3 of 1003] ", or whatever.
* Improved the configurability of the ToolTip - as well as enable/disable,you
can now also set the font, font size, background and foreground colours, as
well as snap distance (how close to the edge it can get before snapping to it).
Note: it's best to use a monospaced font, like Courier New, Lucida Console,
Consolas, monaco, ProFontWindows, etc.
* You can now set how long you want any dialogs to stay open for, in seconds.
The default is 60 seconds. If you set this to 0, dialogs won't time-out.
* checksum now pauses the tooltip (and performs the final double-beep) at the
end of the creation process, as well as after verification (if you have
audio and tooltips enabled, that is)
* fixed a bug where if you were presented with overwrite options, the timer
wasn't being reset, so even if the hashing took only 0.15 seconds, it would
be reported as 5 seconds, or however long you took to decide what to do.
* fixed a bug where pre-existing hidden checksum files would prevent checksum
from replacing them with new ones (if you chose the
"Yes To ALL" overwrite
option)
0.9.13
* Whilst solving an issue a beta tester mentioned, I brought some
interesting functionality into the mix..
I decided to add support for the creation of
"one file", aka.
"root" checksums, just like the sort of thing you might find on a Linux CD.
As well as providing all-hashes-in-one-file, which some might find
useful, it also provides a realistic fall-back in the event of
creating, or rather attempting to create multiple checksums on
read-only media.
The old fall-back strategy simply dumped the checksum files into a
single folder on your desktop, but this, as Jon points out, had
limitations; for example, if two files in checksum's creation path
shared the same name, bad things would happen.
The original functionality was added to catch
"rare instances", but the
more I think about it, and the more checksum gets
"out there", the more
I realize that folk in the real world will do a lot of this sort of
thing, and *intentionally*, probably with whole disks at a time!
To get
"one file" checksums, simply add a
"1" to the command-line.
NOTE: when creating these root hash files, checksum uses Linux paths
for cross-platform compatibility - you can verify md5sum files made
with checksum on any platform. checksum already recognises and verifies
Linux MD5, so this strategy makes the most sense.
* If checksum is asked to perform a regular recursive hash creation, and
discovers that the root folder is read-only, it will automatically
switch to the fall-back mode (currently
"one file", as outlined above,
though I have another in mind, for a future version)
* Added support for Absolute Windows Paths.
When creating root hash files, checksum can now record absolute paths
inside the hash file. A regular relative path looks like this..
"./file.gz" and has the advantage of continuing to work, wherever you move the
disk/folder to, even to a different platform. If you are ABSOLUTELY
sure that this data isn't going to move, you can set this to true, and
checksum will record the entire path, instead. e.g..
"C:\Documents and Settings\me\Desktop\distro\file.gz" ** simple checksum v0.4.9
fixed the issue where Ctrl-P would pop up simple checksum's
preferences, even when simple checksum wasn't at the front.
while I was as it, I improved that hotkey slightly, so that
Ctrl-P toggles the preferences windoid, regardless of whether
it, or simple checksum is at the front.
0.9.12
* Decided not to release checksum exclusively as payware.
What can I say? I dig free software, even if it hurts me!
So, there will now be a free (for personal use) md5-only version, and
I re-wired the internals to make room for this. A small fee will
unlock the SHA-1 hashing side of things. Well, that's the plan.
NOTE: Attempting to create sha1 hashes with the free version gets you
md5 hashes. What did you expect?
* Added support for verifying Linux file paths (switching slashes)
inside hash files.
* Added support for verifying one-checksum-file-per-volume type files,
commonly found in Linux distribution disks. Hashes for the entire drive
are contained within a single checksum file. Though it is very handy
to be able to *verify* these hashes from your Windows desktop, I
currently have no plans to add support for creation of these
monstrosities, though that may change.
These *nix hash files are usually named
"md5sums.txt", or sometimes
just
"md5sums", though you can set whatever names you need, and use
standard Windows file masks, too, in your checksum.ini; e.g..
unix_hashfiles=md5sums,md5sum*.txt
or simply..
unix_hashfiles=md5sum*
If you drag a matching *nix checksum filetype onto checksum, or verify
a folder containing one or more of these, checksum will treat them as
regular .md5 hash files. If it finds back-to-front slashes in the path,
checksum will switch them around. If it finds *nix-type
"./foo/bar" root paths, it will automatically convert them to valid Windows paths.
At the time of writing, I've only tested this out on three Linux CD's,
but they each contained quite different hash formats; checksum
verified them with ease.
* Added audio alert.
when checksum discovers a hash failure, it can optionally emit a small
beep from your peecee speaker.
Rather than simply on/off, you can specify the actual beep frequency,
in your ini, in Hz, from 37 - 19999 (the default is 1000Hz); e.g..
beep_on_failure=500
you can pass 'b' on the command-line, to enable beeping (if it is
currently disabled) or '-b' to disable it (if it is currently enabled)
NOTE: you can still have beeps when running in 'quiet' mode, checksum
leaves this decision up to you and your switches.
The default of 1Khz is good because it's a fairly
"cutting" frequency,
though doesn't describe the failure state as well as a lower value
would; something like 300Hz *sounds* like a failure.
* Added
"extras" folder to the distro, somewhere to put the cool
"checksum.cmd" I received from one of checksum's beta testers (seVen -
thanks!). It's a SendTo processor/wrapper that enables you to control
checksum's functions from your SendTo menu. If you don't dig explorer
context menus, this is for you. More details on the checksum page.
* By the way, probably no one noticed, but if you attempt to click the
recurse checkbox in the creation options, and the path in the path
input is invalid, checksum flashes the path input a couple of times
and un-checks the box again, to let you know. I thought I'd mention
that somewhere.
** simple checksum v0.4.8
plus some other minor improvements which I forget.
0.9.11
* Added
"portable mode".
On the outside, nothing has changed. If still comes with an installer
and so on. However, checksum will now also function in
"portable
mode". To achieve this, all you do is put a
"checksum.ini" file next
to checksum.exe, perhaps move your current ini there.
When it senses that it has an ini next to it, checksum will use it.
This also applies to simple checksum.
If you leave the ini file next to them, they won't access your app
data folder again, essentially becoming permanently portable from that
point. If you move the ini back to your appdata folder, they will
function as before.
Bottom line; you can use your regular installed version for your
regular desktop work, and have additional copies wherever you need
them, on pen-drives, DVD-R, or whatever, each using their own
customized settings.
If you don't want to
"install" checksum at all, no problem; simply
unzip the files from files.zip (in the installer folder).
** simple checksum v0.4.7
simple checksum can now also operate in portable mode.
0.9.10 [my new versioning scheme!]
simple checksum v0.4.6
* simple checksum will now save its preferences when no checksum.ini
is found; it will create the folder, and ini file, if they do not
exist. previously, it would only save the preferences if the ini
file was already present (i.e. checksum was installed/run)
This should rarely, if ever, be required. It's a
"just in case".
0.9.9.2 [first beta release - 60 day limited version]
* Fixed the 8.3 folder name issues.
* Fixed the music playlist recursion issue.
* Added Shoutcast (.pls) playlist support.
* The tooltip is now an actual application window that just *looks*
like a tooltip, and its position can now be altered by simply
dragging it around. It will snap-to the edges of your desktop..
* Enhanced the web documentation and comments within checksum.ini
* Added ignore files preference (for desktop.ini, folder.jpg, etc.)
* Added ignore file types; md5,sha1,sfv,crc,lnk,url,m3u,pls,log, etc.
** simple checksum v0.4.5
* Minor improvements to simple checksum, added all the options
to its application menu, so there's rarely a need to open the
preferences.
0.9 [first private beta]
* Added
"Quiet" operation.
0.1 - 0.8 [private development builds]
* Thanks to brother Mu for the synaptic challenges (and C i/o)!
..
current bugs and foibles:
These bugs are know, but for one reason or another (perhaps waiting for
something else to happen first) they will not be fixed just yet..
* Checksum can run out of memory if you instruct checksum to log
*everything* during operations involving many thousands of files. This
functionalility was added for debug purposes and was not intended
for regular use. Future versions may handle this better.