checksum
a no-nonsense hashing utility for windows..
http:
(c) corz.org
itstory.. aka 'version history'.. aka 'changes'..
[known bugs at the bottom]
Key..
* Fixes
~ Changes
+ New stuff
++ Requested New stuff
£ Registered Users Only
NOTE: This file is stuffed with gems. As time allows, I transplant these into
the main documentation, but there are currently many useful tips that
exist /only/ here. Enjoy!
1.7.4.0
+ checksum now records its version info in the log's HTML footer.
1.7.3.0 [current beta release]
+~ Improved the recent command-line output functionality. You can now
specify a full path for the file so you can keep it outside your data
directory, if required. You can also use @Tokens in this path/name,
perhaps creating different files for different items/dates/whatever.
NOTE: Your old file/name/ preference will be automatically updated (in
this beta version) to
"@userdir\OldFileName".
You can now disable command-line output appending to the file,
essentially creating a new file (deleting the old one) for each and
every job.
* Fixed a bug where if you specified a non-existent output directory in
the one-shot options, checksum would, rather than prompt you about this,
continue in the original directory. checksum will now correctly prompt
the user in this situation.
* Fixed a bug where under certain unusual circumstances, discovering an
empty checksum file could crash checksum.
* Fixed a bug in the .tar.md5 handling, which was recently introduced. I
really must pay closer attention to those
"script breaking changes"!
simple checksum 0.9.5.0
+ The simple checksum window can now be set to automatically become opaque
when you hover your mouse over it. You can set the transparency up high
so it's nearly invisible, then when you go to use it, it's /there/.
I saw and like this feature in the NeTtraffic tool. (http:
* Fixed the erroneous checking of tray menu items.
1.7.1.3
++ You can now specify the number of errors that checksum will display on-
screen before automatically switching to log-to-file mode..
error_display_limit=24
On a 1080p monitor, you could easily manage 50!
++ checksum can write its most recent command-line to a file, for your
information. This file is written to your data folder (in portable mode,
it's right next to checksum.exe). In checksum.ini..
write_command_line=true
You can also specify the name for this file (also in checksum.ini).
NOTE: This file is available at the very /start/ of the job. Also note,
new commands are appended to this file. After a while, it might get big.
++ You can now specify a target root directory when verifying non-absolute
(aka.
"relative") hashes. For example, if you created a relative .hash
file for files in
"D:\my files" and put the hashes in a folder,
"e:\my
hashes" using a command-line something like this..
crd(
"e:\my hashes")
"D:\my files"
.. You can now verify this .hash file (
"e:\my hashes\my files.hash")
(or tree of hash files) /in-place/ using similar syntax:
vrd(
"D:\my files")
"e:\my hashes\my files.hash"
checksum prepends the specified path (
"e:\my files") to the beginning of
any hashes it finds on-the-fly, so a hash for
"foo\bar\file.doc" would
correctly translate to
"D:\my files\foo\bar\file.doc". Neat.
Thanks to Nacho for finally solving the dilemma of how best to approach
this feature. A switch, of course!
++ In addition to the current relative path support, I added support for
relative path /traversal/ so you can specify, for example..
checksum.exe cr
"..\foobar"
and have checksum hash a directory /next/ to the current working
directory.
++ You can now abort an entire queue from either the system tray menu or
tooltip windoid context menu. The option is
"Abort Queue". You won't
see this unless you have job queueing enabled.
+~ Improved the @parent token (used for specifying the hash file name). You
can now use multiple @parent tokens in a single command, e.g..
checksum.exe cr1j(@parent+1~@parent~@item)d(b:\backup\hashes)
"d:\biz\documents\reports"
.. which would output:
"b:\backup\hashes\biz~documents~reports.hash"
While I'm here; seeing as how you don't have a second, even a FIRST
floppy drive any more, wouldn't it be a neat idea to use drive
"B" for
your BACKUP DRIVE!
+ Added a special @parent token: @parent*
This will automatically create a string (for use in custom .hash file
names) that is the entire path of the item being hashed. Whatever
character immediately follows the switch is used for the separator. e.g.
crj(@parent*~@item)
"B:\Documents\Biz\Reports"
Specifies a
"~" (tilde) separator. This would create the hash file:
B~Documents~Biz~Reports.hash
+ You can now use relative paths inside d() switches, i.e. output
directory in creation mode and target root directory in verify mode.
In both instances, the path is calculated from the current working
directory. To change the working directory in a batch script, do:
D:
cd D:\My Files\Correct
You can also use relative path traversal in these switches, e.g..
cr1d(..\..\..\hashes)
"B:\documents\biz\reports"
+ checksum will warn you if you specify a non-existent output directory
for your hashes, and will ask you if you want to create the directory.
By design, there is no
"don't ask me again" option for this dialog.
If you decide to not create the directory, checksum will use its
standard fall-back protocols.
++ By request, checksum can ignore custom hash types stored inside .hash
files. For example, for use by a script that extracts only the data part
of a media file for hashing. e.g. to skip a hash marked so..
Use:
skip_hashes=true
skipped_hashes=md5_jpg
If you have multiple types to skip, separate them with commas, e.g..
skipped_hashes=md5_jpg,md5_mp3,my_type
~ The out_dir setting is no longer available as a checksum.ini setting,
you *must* use the command-line switch to set an output directory when
creating checksums using
"d(<file path>)". Sorry for any inconvenience.
Note: if you want this set for *every* job (risky!) you can add it to
your context menu commands. See the tricks & tips page for more info.
simple checksum 0.9.4.0
++ You can now have simple checksum close to the tray rather than exit,
when you click the close button (X).
This option is available (like most everything else) from the
application menu (aka.
"app menu") which you can get to by clicking the
main program icon in the top-left of the window, or in later Windows
versions also by right-clicking anywhere in the titlebar.
1.7.0.1 [current release]
++ During verification, checksum can now skip checking files which appear
to be unmodified, which is to say, it will perform verification
operations only on files with a modified timestamp more recent than
their recorded timestamp.
This is designed to be used along with the
"w" switch, to update the
hash and timestamp of a file or set of files you have /mindfully/
changed.
USE WITH CAUTION on volumes you know are free from corruption of any
other kind! Using this switch combination inside a scheduled, automatic
task could be a recipe for disaster.
I SAY AGAIN: Used incorrectly,
"wm" can become a WMD!
NOTE: If you are logging *everything*, these entries will appear as
"SKIPPED".
* Fixed a bug where checksum could crash under certain conditions when
using the search + verify feature searching for a file entry for which
there exists no corresponding hash.
1.6.6.6 (
"Optimistic Ocelot" - 15 Google hits!)
~ In addition to scanning .hash files, checksum will now also check legacy
files of the current algorithm (.md5/.sha1/etc.) when performing hash
search operations (
"i" switch). e.g..
vi
"C:\path\to\file\somewhere\file.txt"
Or scanning for a SHA1 hash (when MD5 is your default algorithm)..
vias
"C:\path\to\file\with\sha1\somewhere\file.txt"
This only happens if a match wasn't found in any relevant .hash files.
If you were /not/ using the unified .hash extension, there is no change;
checksum would be scanning your relevant .md5/.sha1/.b2 files, anyway.
*/~ VASTLY improved speeds when synchronizing hash files. I noticed that
when syncing large hash files, checksum was taking an unacceptably long
time (my new 1.2 million hashes test .hash file took over 12h, sorry
about that!).
checksum will now synchronize HUGE .hash files in /minutes/.
That same 1.2 million hashes test file now syncs in under ten minutes on
my lowly Celeron, including the time taken to scan the file system and
extract and parse the hash data (adding a few dozen small files -
obviously adding hashes for any large files would increase that).
* Fixed an issue where large *.tar.md5 files (files with checksums
concatenated to the end of them, usually tarred Android ROM files,
though it is a neat idea I suspect could catch on for other file types)
would cause checksum to run out of internal hash storage space. checksum
should now correctly reject such a file.
Then I thought to myself.. Why not ADD support for these files?
++ I made it so..
Rather than reject such files, users of *.tar.md5 files can now have
checksum do an integrity check of the *.tar archive using the stored
MD5. There is a preference to enable treating *.tar.md5 files as
"special", which is..
tar_md5_special=true
With this enabled (true), checksum will interrogate the final bytes of
*.tar.md5 files for a corresponding hash. Such a file has the internal
format:
<tar data + NUL bytes><MD5 hash> <filename>
e.g..
<TAR DATA> 923c5925c1b0b8694ea35db95e951cf5 recovery.tar
If the <filename> embedded within the *.tar.md5 matches the given
*.tar.md5 file name, minus the
".md5" part of course, e.g.
"recovery.tar.md5" >> (contains data+hash for) >>
"recovery.tar"
..checksum will pluck out the stored hash to compare against a hash of
the tar data part of the file. If the original tar part of the file is
intact, unchanged from when it was created, you get SUCCESS! as usual,
and if not, you get CHANGED. Simple.
By the way, to make such a file do (in Linux/UNIX/Cygwin shell)..
tar -H ustar -c recovery.img > recovery.tar
md5sum -b recovery.tar >> recovery.tar
mv recovery.tar recovery.tar.md5
NOTE: NEVER change the name of your *.tar.md5 files, at least if you
want checksum to verify them correctly. If you do do this and need to
recover the original file name, drop the file into a (CAPABLE) text or
hex editor and check out the last few bites, which will be the original
name. Then simply add
".md5" to the end. Then leave it alone! ;o)
+ Added support for embedded hashes, in *any* file using the file name
format: filename.<hash-format>.ext, e.g.
"RoboCop.sha1.mp4". Checksum
will work out the hash type from whatever
"pre-extension" you use. If
you use the unified hash extension, checksum will use the default
algorithm unless you specify otherwise, e.g..
v RoboCop.md5.mp4 >> Uses MD5
v RoboCop.sha1.mp4 >> Uses SHA1
v RoboCop.hash.mp4 >> Uses MD5
vas RoboCop.hash.mp4 >> Uses SHA1
Unlike *.tar.md5 files, there is no support for verifying multiple
embedded hashes. You must verify them individually - the same way you
make them, at least for now. They can still be hashed along with your
regular files, of course.
To force verification of any file, hold the Ctrl key down when selecting
the checksum item from Explorer's context menu.
If you want to play with this, remember that some files will NOT work
correctly once you concatenate a hash onto the end of them. Media files
and archives are usually fine.
~ Faster file system search routines. This will impact the file search
phase of checksum's operations, especially on LARGE file systems.
~ Improved speed when performing hash /search/ operations on large hash
files. For huge hash files the time difference will be dramatic. Also,
checksum now uses a 1/10th of the memory for searching.
~ Improved System Tray tips and progress windoid information.
~ With some internal rewiring, I increased the previous limit of 2,396,744
hashes per .hash file. The limit is now effectively around 16,777,215
hashes per file; what it was supposed to be. I say /around/ because
although unlikely, if you have a hash file with 16,777,215 hashes + info
lines + heaps of manually-added comments, during verification checksum
will flag the file as being too big to handle.
~ checksum will now move its one-shot option dialogs on-screen if they
are set (by the user) to appear off-screen, such as when you keep them
in the far corner of your desktop and then login via remote desktop on a
smaller device, such as a laptop or tablet.
* Fixed memory spike on initial .hash file read, specifically when
checksum was counting the number of lines in the hash file.
* Fixed an issue where the logging level wasn't being reset correctly
during verify operations, resulting in erroneous logging of DELETED
files, but only after CORRUPT or CHANGED files had been discovered.
* Fixed handling of ANSI MD5 files with foreign file names in them (which
I broke in the last version). These were being treated as UTF-8 and the
verification would result in apparently MISSING files. checksum will
once again automatically determine the file's encoding.
By the way, I DO NOT recommend you use any ANSI-only utility to create
MD5 sums of directories of files with foreign names. Even using extended
locales, your program will simply miss files. Of my test directory of 58
foreign-named files (including but not limited to Russian, Chinese,
Urdu, Greek, Icelandic, Swedish, Arabic, and more, as well as a
selection of just wild UNICODE character names), other apps will fail
on at least 30 of the file names. With the default UTF-8 encoding,
checksum can handle everything.
Simple Checksum 0.9.3.1
~ Simple Checksum will now disable checksum's beep for the first half
of a folder compare operation. If you have beeps enabled in checksum
you will hear that at the end of the completed folder compare.
1.6.0.8
~ Put the search+verify option (one-shot options dialog) into a group (by
itself!), to be more in line with the other options.
~ The text in the notification at the end of the verify dialog now
correctly states the number of hashes checked, as opposed to the number
of files - there may be multiple hashes for the same file, you see.
~ Added information about creating task folders to the task name input of
the Task Scheduler Wizard. By default, tasks go in a
"checksum" folder,
but if you can specify your own (using: folder\task-name).
+ UPDATED and DELETED events are now logged.
+ Updated the CSS files to cover the above (as well as BAD files)
* Fixed search+verify routines to correctly handle all possible path
variations.
* Fixed the wonky behaviour of the verify options log input on Windows 8.
The input should fly out when the mouse is over it, and stay that way
until the mouse leaves the control. Now it does.
* Fixed a vermicious bug where if you exited using the ToolTip menu at
*just* the right time whilst synchronizing hashes, you would get a hash
added to a file where one already existed, creating a duplicate hash.
* checksum will now respect a blank
"nameless_name" preference. Previously
it would always insert the default value, which is
"nameless".
* Fixed a bug in the plain text logging (no one uses this, right!) where
logs were occasionally being created even when there were no errors.
1.6.0.6
$++ Mail Notification on hash failures.
Yes! checksum can mail you when it detects errors in your files;
especially handy for scheduled tasks running while you are away or
otherwise engaged.
Your mail preferences can be edited from a cute GUI available from
checksum's System Tray menu (while one-shot verify options window is
open). It can do CC, BCC, SSL, single and multiple file attachments,
mail priority, all the usual goodies. (it uses the built-in Windows CDO
mail sending functions)
I've tested it successfully with a few outgoing servers including gmx
and Gmail (both using SSL on the standard port: 465) as well as my own
local Linux sendmail.
To attach files, you can either enter the full path of the file(s) into
the attachment input (separate multiple files with semi-colons
";"), or
else click the label
"Attachments" to browse for files (which will be
appended to your current input), or else drag & drop files directly onto
the input (which replaces the current input).
NOTE: You can use the
"@log" token (no quotes) to attach the final log
to the email - most useful! e.g..
@log;C:\some\other\file.txt;C:\and\another.png
Attaching you log file, as well as being extremely useful, has the added
bonus of (assuming you have inline attachments and HTML enabled in your
mail client) making the entire mail look cool like a checksum log!
Finally, you can also save mail settings as presets for later recall.
This makes it easy to switch between mail servers, if required.
+ The Mail-On-Fail dialog is also resizable, like the create options, for
the same (accessibility) reasons, and with corresponding checksum.ini
hacks available for permanent resizing (these are the minimum values)..
mail_options_width=265
mail_options_height=360
+ BAD files (those which appear to be .hash files, but are not - most
likely corrupted) will now be logged as well as reported. BAD files can
be sign of disk corruption.
~ Even faster startup!
~ The final total number of files processed is now also shown in the final
dialog during verify operations as well as creation jobs.
~ During search+verify operations, if checksum discovers a CHANGED file,
it will now update the hash (if you have this behaviour enabled - by
using the
"w" switch). Previously the
"w" switch had no effect in this
scenario.
+ I have added an option for search+verify to the one-shot verify options.
It's kinda thrown in for now, until I can get around to re-organising
that window. But it works!
~ If you have open_log_folder (
"g" switch) set during verification and
there are hash failures and the log folder is /already/ open on your
desktop /somewhere/, checksum will bring it to the front.
* Fixed a bug where a couple of the verify switches were not translating
into the checked items in the one-shot verify options.
£* Fixed the bug in the disable edit ini and custom preamble not being
available to registered users.
* Fixed a bug in the relative and fall-back logging locations. If a blank
log location is entered, the log will now appear in the top folder
checked, as expected. And if that is not possible, it will fall-back to
your desktop (and now with a file extension, as expected!). Almost no
one uses this (because the checksum dedicated log folder is such a good
idea!), which is how it escaped my attention so long.
1.5.8.4
~ Faster string search routines (now almost twice as fast). This impacts
hash synchronization, checking files from the list of existing hashes. I
have tested the new routines against a range of strange foreign
languages and Unicode characters with 100% success.
* Fixed recently introduced sync issue when using absolute paths inside
root hashes. This was leading to duplicate hash entries.
* Fixed issue with hash comments not respecting the always_store_unc pref
(they were using UNC-style paths even when this was disabled - it caused
no issue, but looked incongruous).
* Fixed a bug in applying unified extension to multiple legacy hash files.
This almost never happens, but if you happen to have .md5/.sha1/.blake2
hash files for a file and applied a unified extension, hashes for second
and subsequent algorithms were being re-calculated.
1.5.7.0
+ Added search + verify command to checksum's default installed Explorer
context commands. It's that handy! (see 1.5.6.3 changes)
If you want this NOW, either uninstall+reinstall checksum (all your
settings will remain intact) or else merge the sample registry file
found here: http:
++ Directory Exclude Masks. You can now specify one or more directories
which you would like to exclude from the hash creation process, using
standard file masks (?,*). The
"x" switch, followed by a set of exclude
masks in braces, enables this functionality. Separate individual masks
with a comma.
For example, you want to create a root hash, but not hash any
directories with a name that begin with
"foo", or ends with
"bar", or
starts with
"baz" AND ends
"qux", do..
checksum.exe cr1x(foo*,*bar,baz*qux)
"D:\MyDir"
* Fixed long path handling in search+verify function - Of course Explorer
is sending short paths. Doh!
1.5.6.3
++ checksum will now post the path that was hashed/verified in the final
tooltip, in case you forgot what it was you were hashing, e.g..
checksum completed verifying: e:\music\jazz\ in 3.55 seconds.. [100% OK]
++ Added new method (actually, the original method!) for testing
writeability of directories. Normally we use the most accurate method,
which is to write an actual test file to the directory. However, this
will also change the
"last modified" timestamp on that directory.
If you would prefer this to /not/ happen, you can do (in checksum.ini)..
relaxed_write_test=true
which will instead rely on the system's
"read-only" flag for the
directory. This works in most ordinary scenarios. However if, you ever
get a
"..having problems creating a checksum file" error, set this to
false and try again!
++ Added Individual file verification search feature. This enables you to
verify a single file, anywhere in your system, /from/ anywhere in your
system, regardless of where its associated .hash file is in the file
tree.
This is extremely useful when you want to verify a single file but don't
have an individual .hash for it, especially when the entry is inside a
.hash file with thousands or millions of other entries, or you aren't
sure exactly which .hash file contains the entry.
Normally, for verification you feed checksum .hash (or .md5, whatever)
files and it scans them looking for matching files to hash. Using /this/
method, you feed checksum a regular file path and it scans your .hash
files looking for a matching hash entry!
checksum will search up the tree, first looking for matching individual
.hash files, and then folder hashes, all the way up to the root of the
volume until it finds one containing a hash for your file, at which
point it will verify that one hash and return the result.
The final dialog will also tell you *which* .hash file contained the
entry for your chosen file.
Thanks to Brett Lang for the original idea, which he presented to me as
a DOS batch script doing a similar thing. I have to admit, it took me a
while to get my head around the idea (it's just so back-to-front!), but
once I did, I immediately saw how useful such a feature might be.
You can enable this operation by using an
"i" on the command-line, think
"individual" file verification, or perhaps
"Inverted operation"! e.g..
checksum.exe vi
"C:\some\path\to\file.ext"
This works best as an Explorer context command. Future versions will
have this built-in to the installer setup. For now, an example .reg file
is at http:
1.5.4.4
++ Exit command..
checksum can now launch another program/process/task on completion of
its job.
NOTE: you can use @tokens in this setting, including the new @exit
token, which will transform into checksum's exit code, to pass to the
program..
exit_command=c:\path\to\my\app.exe /foo @exit
There is also a special @fullpath token which you can use to insert the
full path of the item that was originally sent to checksum, and
@fullpathnounc, which does the same thing, except the path will NOT be
a UNC-style path, e.g..
@fullpath = \\?\C:\path\to\my\stuff
@fullpathnounc = C:\path\to\my\stuff
FYI, using the @item token would get you
"stuff" in this example.
You can enable processing of the exit command by either setting..
do_exit_command=true
.. in your ini file, or by passing the
"0" switch on your command-line
(zero, no quotes - think standard exit code). If it is enabled in your
ini, you can temporarily disable it by passing
"-0".
++ Custom blake2 extension. You might prefer
"b2" or
"blake2s" or something
else. Simply set the blake_name preference..
blake_name=blake2
++ Added count to final dialog, so you always know exactly how many files
were hashed at-a-glance. I can't believe I didn't think of this! Thanks
Badon.
+ Improved responsiveness of initial HotKey modifiers (Shift & Ctrl) so
that one should only need to hold them down momentarily, as opposed to
waiting for the options dialog (for example) to appear. Most people will
probably not notice any difference.
* Fixed an issue which caused checksum to crash when the (HUGE!) max
folders limit is reached. Of course, you could increase this in your
checksum.ini, but still, it wasn't being handled. checksum will now
automatically increase the folder limit if required.
~ Removed Max Folders preference (due to above - new automatic limit).
* The
"checksum was given nothing to do" dialog has been made *much*
smaller and now always opens a web page in your browser with more help
than can be fit into a dialog window. (it tells you it has done this).
With the advent of the new startup command facility (v1.5.2.0+), I
expect less people will be seeing that dialog, anyway.
1.5.3.0
++ Task Scheduler..
You can now create basic tasks for your system scheduler, to perform
checksum jobs on a schedule. Handy for hashing your morning torrent
downloads, weekly verifying your backups and much more..
A
"wizard" will ask you a few questions about the task, user name, time
and so on, and then pop open the options dialog (create or verify,
depending on the task), where you can set your options for the scheduled
task.
You can also have schedule setup as your default startup command (see
below - v1.5.2.0 changes)..
startup_command=schedule
+ You can now get to the
"Edit Prefs (ini)" tray menu option when checksum
is started with nothing to do.
1.5.2.0
Custom Startup Command..
When checksum is launched with nothing to do, rather than have checksum
display the
"Nothing to do!" dialog, you can have it do something
/else/. This might be a default checksum command that you use a lot, or
another program, or something else. e.g..
startup_command=simple checksum.exe
startup_command=c:\path\to\some\program.exe /foo /bar
startup_command=c:\path\to\my editors\editor.exe /open
"i:\my\document.doc"
startup_command=c:\some app.exe c:\some documents\document.txt
For checksum commands, send your regular command-line after a
"checksum"
flag; the word
"checksum", with a pipe character after it, e.g..
startup_command=checksum|crtbim(movies)
"W:\Completed Torrents"
And checksum will launch itself with the specified command-line. Simple.
If you use something like:
startup_command=checksum|cor
"C:\"
Clicking on checkum.exe (or a shortcut to it) will startup checksum with
the one-shot creatino options dialog open, so it seems like you are
running a
"regular" app! You can drag and drop in a folder, go for
it.
You can have checksum jump straight to the (almost) hidden System Info
Box..
startup_command=checksum|SysInfo
NOTE: If a DOS command isn't working as expected, use the DOS
compatibility flag
"dos", e.g..
startup_command=dos|compact.exe /C
"B:\hashes\*.*"
ALSO NOTE: like many prefs, you can use @tokens in this setting.
There is also a special
"shellex" flag, which I will now explain..
Normally, a command-line is an executable, optionally with some switches
and parameters required to complete the job. But you may want to launch
something else, for example a document or URL. For this, you can use the
"shellex" flag. The
"shellex" flag performs a system
"Shell Execute",
which can be used to launch just about any
"thing". It goes like this..
startup_command=shellex|Item|Parameters|Verb|Working Dir
Only the
"Item" is required. All others are optional, for example..
startup_command=shellex|C:\Users\Cor\Desktop\corz.org.URL
which will launch an internet shortcut I have on my desktop. Using the
"shellex" flag, you could also launch the URL directly..
startup_command=shellex|http:
The default verb is whatever your system would normally do with the path
you send, usually
"Open". But you can (usually, though not always) use
any verb avalable from your Explorer context menu, e.g..
startup_command=shellex|C:\Users\Cor\Desktop\page.indd||Print
NOTE: the double || because in this example, I don't want to send any
parameters but DO want to send a Verb. In other words, if you want to
skip a previous flag, leave it blank.
The many, many uses for this feature should be obvious. Self-contained
on-disk data checking is but one of them!
Finally, there is a prefs flag..
startup_command=prefs
..which opens up the checksum preferences (ini) in your preferred text
editor.
~ Improved relative path handling (again), you can now use .\ and ..\
constructs to checksum the current or parent directory. This is
especially useful when using checksum in a stand-alone mode, e.g.
when burned to a disc for on-disc data checking.
1.5.1.2
+ You can now set the string checksum uses to construct names when
creating .hash files from files with no names. By default, this is
"nameless". If you set this to blank, checksum can potentially create
".hash" files, which may become invisible on some systems. This may be
what you want. Though it rarely happens, it is now configurable.
* checksum will no longer perform a writeability test of the hashing
location where a custom output directory has been set (it will now
properly test the custom output directory). Another upshot of this is
that the original folder's modification time will not change.
simple checksum 0.9.2.1
~ fixed folder compare command-line to match new custom output directory
switch requirements in checksum. Oops!
1.5.1.0
+ Added new beta_channel preference.
I've (finally!) settled on simply releasing betas to anyone who wants
them, which is better for you, less work for me.
You can set this preference in your ini..
beta_channel=true
.. to get notified when updated betas become available (as well as the
major releases). By default this is set to false, so you only get
notified of major releases.
Major releases supercede all previous beta releases. The beauty of this
setting is that it will survive switching to and from a major release
when /it/ becomes the latest version.
Beta and release versions now behave exactly the same way - if you have
beta_channel=true set, as soon as a beta becomes available, you get a
notification.
* Fixed an issue where hidden checksum files were not being updated (when
using the w switch during verify).
* Fixed an issue where portable relative paths on the command-line were
being ignored. This means that you can now easily script self-contained
disk checking mechanisms with checksum on, for example, burned DVDs.
This was possible before, but not without obscure DOS substitutions.
* Fixed an issue where using braces in the custom output directory would
fail (checksums left on desktop, instead).
Note: You need to put custom output directory switches LAST, after other
bracketed switches, for (complex) example..
cr1qnm(movies)j(my-hashes)d(
"c:\some (dir) here")
"D:\My Movies"
1.5.0.0 [public release]
~ The monthly Shirtware reminder will now only bug you a maximum of three
times before disappearing for another month. Previously it would keep
bugging you until you click
"Yes" ONE TIME! - still the best way to get
rid of it!
* fixed a bug where the initial version check dialog could appear under
the one-shot options if you quit checksum's very first run.
* Fixed a bug where choosing the
"About checksum" options from the menu,
during an operation, would quit checksum.
1.4.5.1
* Fixed a silly bug in the queue handling.
1.4.5.0
~ When queueing multiple items in Explorer with the <SHIFT> key held down,
checksum will now apply whatever options you set for the /first/ item to
the /entire/ queue. If you would prefer to have the options dialog pop
up for each item (the old behaviour), set this new preference..
apply_options_to_queue=false
When set to true (the default), checksum will also automatically check
the
"quiet operation" checkbox for you (if quiet operation is not
already enabled), to prevent multiple final dialogs (if enabled) from
popping up; assuming you want minimal interaction with the jobs. Of
course, you can deselect this if you really want to see (and click!)
/all/ the final dialogs.
+ checksum will now check how much free space is left on the target drive
before beginning to write a hash file. If it estimates that the drive
will run out of space before completion, it will halt with an error to
that effect before it begins writing hashes.
Note: checksum will err /slightly/ on the side of caution in its
calculations.
+ When creating root hash files with absolute paths, you can now choose to
either always store UNC-style paths in your .hash file (the default) or
not. If you set..
always_store_unc=false
.. checksum will use old-style paths for short paths and switch to
UNC-style paths for long paths (that is, paths with more than 259
actual characters).
Note: checksum works with UNC-style paths internally so setting this to
true will be slightly (microseconds) faster when writing each hash.
++ The tray ToolTip will now display some basic information about what
checksum is doing, for those that prefer to run with the ToolTip Windoid
disabled (which is faster when dealing with lots of small files).
~ Optimized the non-hash file test and hash file line counting routines.
Every millisecond counts!
* Fixed an issue where dropping multiple files onto checksum's one-shot
create options dialog input where one or more of the files had no
extension would produce an incorrect entry in the masks list, i.e.
"*.".
* Fixed a bug where choosing to show absolute paths in root .hash files
created from the root of a drive would not show their UNC-style prefix.
checksum can handle this just fine, but it was inconsistent with
absolute path root hashes produced from some path deeper inside the
drive (which do show the UNC-style prefix). Also, other hashing apps
would most likely choke on long path with no UNC prefix, that is, if
there were any other hashing apps that could handle long paths to begin
with!
* Fixed a bug in the show_unc_paths preference, which was being partly
ignored when set to true.
* Fixed a bug in recognizing single
"piped" hashes with no line-breaks.
* Fixed a bug where selecting multiple files to hash directly after an
upgrade could scramble checksum's ini file. Of course there was a backup
made, but still. Ouch!
* Fixed a bug in the version checking routines - unless you had already
set the interval (in the release version or manually) you would never
get the option to do so!
1.4.4.2
+ You can now drag multiple items onto the one-shot create options path
input and checksum will create a file mask group from the dropped items,
for example, if you dropped these three files..
E:\Docs\report.pdf
E:\Docs\stuff.txt
E:\Docs\more-stuff.doc
The path: input would be set to
"E:\Docs", and in the file masks input
you would have
"*.pdf,*.txt,*.doc".
As usual, the resultant .hash file would contain only hashes for files
matching these extensions.
~ When launched with a file on the command-line (via Explorer right-click,
etc.) the file name will be placed and selected in the masks input.
Previously it not selected. As before, if a folder is sent, the masks
input is set to the default mask
"*.*".
~ When dragging files onto checksum's one-shot create options dialog, the
name of the file will now be added to the masks drop-down list and
selected in the file mask: input. Previously it was added to the
drop-down list but not selected.
~ Some more minor cosmetic fix-ups, out-of-place linefeeds in read-only
notices and such-like.
* Fixed a bug with setup where installing an old version over a new
version would send the installer into a dialog loop (if the user chose
to uninstall the newer version first). Of course, almost no one would
attempt such a thing, but still. This should now work as expected.
1.4.4.1
~ Minor fixes in cosmetics, text placement in dialogs and such.
* Fixed a bug in setup where uninstalling checksum after multiple upgrades
of previous versions would leave files in the ProgramData folder. This
was due to a mangled entry in HKEY_LOCAL_MACHINE\SOFTWARE\corz, which I
had recently introduced changing the
"long" name from
"corz checksum
utility for windows" to simply
"checksum", which I did because people
kept naming checksum,
"corz checksum", which was mildly annoying! It's
corz as in
"Cor's", see? No? Oh, forget it! ;o)
1.4.4.0
++ We have a new algorithm! checksum can now create BLAKE2 hashes of your
files. For more information about BLAKE2, see here:
https:
You wanted a strong hashing algorithm - it doesn't get much stronger
than this!
BLAKE2 is superior to any of the SHA2/3 family of hashing algorithms,
offering the best security available in a cryptographic function, yet is
comparable, speed-wise, to our current SHA1 hashing (on x64, it's faster
- last night I hashed 1TB of archive files, whilst working away on other
things on my busy workstation, in under three hours - pretty good).
Technically, checksum uses BLAKE2s-256, producing digests (hashes) of
sixty four characters in length. The code is based on the public domain
C implementation of BLAKE2s by Samuel Neves, available from the above
URL.
Thanks to Alberto for turning me on to BLAKE2 - Impressive Stuff, Sir!
++ During verification, checksum can now update (aka.
"refresh") hashes of
CHANGED files. This enables you to automatically update your .hash file
with new hashes (and timestamps) of files you have /mindfully/ altered.
Lots of people asked for this!
NOTE: you need timestamps (check_date=true) for this to work.
IMPORTANT NOTE: checksum can only update hashes for checksum-created
hash files. When verifying non-checksum hashes (e.g. piped Open SSL
hashes) there are only two states, OK and CHANGED. CHANGED files MAY be
corrupt, but checksum cannot know this because there is no date/time
information stored with the hash. So, if you request that CHANGED files
be updated, only those inside checksum-created hash files will be
updated. It may seem inconsistent, but actually makes perfect sense!
++ The one-shot options dialog has been expanded and now includes BLAKE2
hashing (of course) as well as new options for custom output directory,
quiet mode, and shutdown when done.
++ The one-shot create options dialog is now resizable, in case you have
your screen fonts set to some large size (for accessibility reasons) and
the options are squished together.
By the way, I recommend KDE-Mover-Sizer for quickly resizing *anything*.
See here: http:
Note, if the above paragraph applies to you, you will probably want to
create the following two preferences in your checksum.ini, to have the
options dialog permanently resized..
create_options_width=370
create_options_height=251
Those are the minimum sizes allowed, but you can set them to anything
you like, within reason (i.e. your desktop size).
This is a bit of a hack, but hopefully should help anyone who needs it.
+ The one-shot verify options dialog has also been expanded to include
BLAKE2, as well as adding options for deleting hashes for missing files,
updating changed hashes, go to log folder on log creation and shutdown
when done.
+ The verify options dialog is now also resizable, like the create
options, for the same reasons, and with corresponding checksum.ini hacks
available for permanent resizing..
verify_options_width=380
verify_options_height=219
Again, those are the minimum settings, so feel free to make it bigger,
if required.
+ Added experimental support (designed for automated folder compare -
see simple checksum changes, below) for supplying the hashfile_name on
the command-line. The swith is
"j" (as in
"John" - it's the last letter
available for switches!). As with output dir, you enclose the name in
brackets directly after the switch, like so..
j(my-hashes)
Just like the hashfile_name preference in checksum.ini, you can use
dynamic tokens with this name.
NOTE: you CANNOT successfully use this in the options dialog switches
input. If people request it, I will consider adding this facility to the
one-shot options.
~ checksum will no longer automatically fill in your ignore_types
preference with its default basic values (md5,sha1,hash,sfv,crc), so if
you really want to, you can make .hash files of .hash files!
~ Updated the CSS files with styles for DELETED and UPDATED hashes. I also
put back the fallback background images from corz.org - they somehow got
removed during my HTML5 update. Sorry about that!
NOTE: If you have edited your CSS file (the one sitting right next to
checksum.exe) You will need to delete/rename it to get an updated CSS
file with the new styles. checksum will only update the file if it is
unchanged from the original install (v1.3.*/v1.4.*b).
~ Optimized the read-only checking routines - the long path support makes
things easier, which is ironic, because it was the new long path support
that had slowed it in the first place! This will only be noticable if
you are creating individual hashes of LOTS of small files.
* Fixed a bug in the verification algorithm choices and made the tooltips
clearer in the verify options dialog. Hopefully the behaviour now makes
sense!
~ Updated to the setup program slightly. It should now be more friendly
on XP (no one is still using XP though, right?), as well as prevent
users from installing the x64 version of checksum on 32 bit systems.
Also, it won't attempt to install dividers on XP, because they simply
don't work!
!! On Beta build, you can put do_debug=true in your ini file and get GOBS
of debug output in the working directory. If you are reporting a bug,
PLEASE send me this output (as well as a copy of your checksum.ini).
simple checksum 0.9.2.0
+ simple checksum can also calculate BLAKE2 hashes of files and strings.
+ When getting the actual hash of compared files (with ALT+C) the title
bar will momentarily display the name of the file the hash corresponds
to.
+ The simple checksum window can now be resized. There is no accessibility
reason for this, but I thought you might like to a) be able to see your
entire BLAKE2 hash, or b) make it *really* small, for extended desktop
usage.
A good size for seeing all BLAKE2 hashes is simple_width=460, but you
don't need to set that - simple checksum will remember whatever width
you resize it to. Changes in height are ignored.
+ Added folder compare. That's right! So long as checksum is installed,
simple checksum can now happily accept two folders on the command-line
(or via drag-and-drop, etc), and will automate the process of hashing
both folders in turn (using checksum), then compare the two resultant
.hash files (by hashing, of course). If they are identical, you get..
"Folders MATCH!"
If they are NOT identical, you get..
"Folders DO NOT MATCH!"
Simple as that!
~ simple checksum now hides the
"hash it" button during hashing
operations, to prevent users from accidentally creating false hashes
by clicking it during a hashing operation (the click would be buffered
and the final hash would be a hash of a hash!).
1.4.1.5 [beta]
++ Added CPU process priority option, an integer from 0-5 (0 = low/idle,
5 = realtime). The default is 2 (Normal). Setting a priority outside
this range gets you 2 (Normal)!
++ During a verify operation, checksum can now remove hashes for missing
files from your .hash file
pref: delete_missing_hashes=true
command-line switch: x
Once set, this will happen transparently, unless you have chosen to log
"everything", in which case they will show up in your logs as
"DELETED".
There is also a notice in the final dialog which lets you know how many
hashes were deleted, if any.
NOTE: Whenever checksum deletes hashes from a hash file, a backup is
stored in your system temporary folder, named
"checksum-deleted-backup.hash". If you make a boo-boo, for example, by
enabling this preference and clicking on a fallback .hash file, you can
always grab the original from there; at least until you repeat the
mistake!
ALSO NOTE: If ALL the hashes inside your .hash file are deleted, the
file itself is also deleted.
This
"post-processing" capability opens the door for other post-job
tasks we might need. Watch this space!
++ checksum can now shutdown your computer at the end of an operation.
Handy for big jobs on systems that don't run 24/7.
pref: shutdown_when_done=false
command-line switch: z
~ If you had the <SHIFT> key down whilst queuing a job in explorer,
that will be remembered (the options dialog will pop up). If you had it
pressed while selecting multiple files, it will pop up for each job.
++ Added support for TAB delimited hash files. I have never seen one of
these in the wild, but a couple of checksum users have assured me that
they do exist! Enjoy!
++£ You can now hide the
"Edit ini" tray and context menu items to prevent
underlings having easy access to the main settings.
++£ You can now disable the preamble altogether, if required. This had
existed for a while, but there was no preference for it.
+ checksum beta releases now have their own version checking URL, so if you
are playing with the betas, you can be assured of staying up-to-date
with the latest developments.
* The ToolTip windoid and synchronize dialog will now honour your
show_unc_paths preference.
* Fixed a bug where slashes were being used instead of backslashes in
relative paths. checksum doesn't mind either way, but passing your .hash
file to some other (lesser!) hashing app might have caused problems.
Note: You still get forward slashes when nix_paths is enabled.
* Fixed a minor bug where the backup ini file had a double .ini extension.
!~ checksum will no longer work with Windows 2000. XP is the required
minimum Windows OS version.
1.4.1.2 [beta]
~++ The hashing library has been rewritten to correctly handle UNICODE file
names/paths. Now we can happily hash Russian, Japanese, Greek, anything!
This works regardless of your current locale.
The previous
"upstream" changes were problematic, so I bit the bullet!
++ Support for LONG PATHS (beyond the Windows MAX_PATH limit). That's
right! You can now hash files with paths as long as 32,767 characters!
+ Improved error handling in hashing library. Your .hash file will now
correctly inform you of permission denied and other error states.
~ The convert_names and convert_level preferences have been removed,
with full UNICODE file name handling there is no need for it, ever!
~ The log folder will not open automatically if it is already open on your
desktop.
~ The dialog that pops up if some of the hash files were invalid is now
editable, so you can copy/paste the information somewhere / open the
location, etc., if required.
Note: This dialog respects your dialog_timeout preference, unless you
click inside the editable area, which halts the timer.
* A few other minor fixes and optimizations.
1.3.6.2
* Fixed an issue on TrueCrypt drives where certain ignored folders being
set would halt checksum.
~ Improved handling of files where the user's Anti-Virus software has
denied access to the file (or rather, presented it as a zero byte file)
~ Improved handling of fall-back where checksum was unable to write .hash
files due to the location path exceeding the Windows PATH length
limitation.
1.3.6 [current release version]
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 (now at v0.6). 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
exclamation 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 can 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 believe 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. After installation, it will ask you one time about how regularly
to check for new versions. If you want to change it after that, you will
need to edit the ini. Feel free to check daily, my server can handle it!
£++ Customizable preamble string (the comment at the top of the .hash file)
£+ Customizable
"licensed to" name in About Box.
+ 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 is a facility for existing Licensed users to upgrade their
license key, here:
https:
+ setup now puts icons in the context menu on systems where this is
possible. It also installs
"Directory Background" menu items (the one
you get when you right-click . This almost makes up for the loss of
Windows 7 app menu functionality, at least for checksum!
++ 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 queue 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.
~ checksum grudgingly now uses plain ANSI for regular .m3u files and
enables users to select .m3u8, if required. It's a real pity
"they"
didn't just keep one extension, but certain music players will balk on
UTF-8 .m3u files, so this has been added for maximum compatibility. pls
files are still always UTF-8.
~ 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 performed no action.
* Fixed an issue where if you had the ToolTip disabled on launch and then
quickly enabled it while checksum 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.
~ The keep_dll setting has been deprecated - now it just stays put in
portable mode.
~ The binaries are no longer packed. Originally, it was fantastic, being
able to fit the whole lot onto a floppy disk, but you have to ask
yourself,
"what the hell is a floppy disk?"
simple checksum 0.8.4 [current release]
~ 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
line break at the end (usually 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.
+ 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 therefore been added to the menu:
"Clear the Clipboard".
+ New About Box, more in line with checksum and my other apps (but there's
no SysInfo, which would be too much duplication - you can get that from
checksum if you really need it).
+ simple checksum will now post an error message if your chosen (ini) editor
could not be launched, as opposed to simply doing nothing.
++ By request, I have added a switch to take you directly to the SysInfo box
easter egg. That switch is
"SysInfo" (no quotes). Enjoy!
* Fixed a bug where simple checksum would continue, even in the absence of
the hashing library. Now it will post its message and exit.
setup:
+~ There have also been a few improvements to the installer (setup) app. It
is now 64-bit aware, as well as being better at cleaning up after itself
(specifically, it will no longer leave an empty top folder in your app
data folder after a complete uninstall).
1.2.*
++ 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!
++ 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.
++ 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.
* 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.*
+ 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) job 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:
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:
* 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 job 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-licensed 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..
* 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 job, 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 job 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:
You can see demos of the log output here..
http:
http:
* 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:
* 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
(the first time a log is created). 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:
.. or a regular http:
* 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_location 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..
* This is an installer issue..
The neat and so-handy directory background context menu items (the ones
you get when you right-click and empty space inside a folder) get
duplicated into Explorer's navigation pane context menu. So you have two
sets of identical-looking menu entries and the second set does not work.
I hadn't realised that Explorer duplicates the folder, drive and
background menus into the nav pane. Quite strange behaviour! My nav pane
context menu (which I activated for the first time, today) is about 150%
bigger than my screen height! Mad!
I have literally Googled my fingers sore looking for a solution, but
none can be found. In the end I posted a question on MSDN, so I'll have
to wait and see what happens there..
<https:
If it annoys you, you can delete the directory background context menu
entries (these are the ones causing the issue) either manually, here
(in the registry)..
HKEY_CLASSES_ROOT\Directory\Background\shell
.. (there are four entries - two dividers and two commands) or else
uninstall checksum, then delete/comment out that section of setup.ini
(the last section) and re-install checksum.
Of course, you now have no directory background context menus. Bummer.
I suspect most people don't use the nav pane, and if they do, they don't
do much right-clicking on it, or else someone would have reported this
earlier. Thanks to George Lin for spotting this.
* Checksum can run out of memory if you instruct checksum to log
*everything* during operations involving many hundreds of thousands of
files on systems with limited RAM. This functionalility was added for
debug purposes and was not intended for regular use. Future versions may
handle this better. Normally, only errors are logged.