##### ### ## ### ######## ### ## ### ###TM ####### ####### ####### ######## ####### ####### ####### ### ### ### ### ### ### ### ### ### ## ### ### ### ## ### ### ### ## ### ## ####### ####### ## ######## ### ####### ## ###### ##### ### ## ######## ### ### ## ### #### checksum a no-nonsense hashing utility for windows.. http://corz.org/windows/software/checksum/ (c) corz.org itstory.. aka 'version history'.. aka 'changes'.. [known bugs at the bottom] Key.. * Fixes ~ Changes + New stuff ++ Requested New stuff £ 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://venea.net/) * 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.. #md5_jpg#Always_updating_this_EXIF_data.jpg#2012.09.29@07.18:00 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()". 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: e.g.. 923c5925c1b0b8694ea35db95e951cf5 recovery.tar If the embedded within the *.tar.md5 matches the given *.tar.md5 file name, minus the ".md5" part of course, e.g. "recovery.tar.md5" >> (contains data+hash for) >> "recovery.tar" ..checksum will pluck out the stored hash to compare against a hash of the tar data part of the file. If the original tar part of the file is intact, unchanged from when it was created, you get SUCCESS! as usual, and if not, you get CHANGED. Simple. By the way, to make such a file do (in Linux/UNIX/Cygwin shell).. # tar the file.. tar -H ustar -c recovery.img > recovery.tar # concatenate the MD5 onto the end of the tar file.. md5sum -b recovery.tar >> recovery.tar # rename to show change.. mv recovery.tar recovery.tar.md5 NOTE: NEVER change the name of your *.tar.md5 files, at least if you want checksum to verify them correctly. If you do do this and need to recover the original file name, drop the file into a (CAPABLE) text or hex editor and check out the last few bites, which will be the original name. Then simply add ".md5" to the end. Then leave it alone! ;o) + Added support for embedded hashes, in *any* file using the file name format: filename..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://corz.org/windows/software/checksum/files/ ++ Directory Exclude Masks. You can now specify one or more directories which you would like to exclude from the hash creation process, using standard file masks (?,*). The "x" switch, followed by a set of exclude masks in braces, enables this functionality. Separate individual masks with a comma. For example, you want to create a root hash, but not hash any directories 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://corz.org/windows/software/checksum/files/ 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://corz.org/ 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 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://blake2.net/ 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://corz.org/windows/software/accessories/ 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 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 . 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.. #md5#Björk - Hunter.flac#2009.09.26@19.49:36 fba7b0f424d3c217d312bcd84728ac8f *Björk - Hunter.flac #md5#Desirée.flac#2009.09.26@19.49:36 00073fa1652f74961c1a9696afa7a992 *Desirée.flac #md5#info.nfo#2009.09.26@19.49:36 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://corz.org/windows/software/checksum/upgrade.php + 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 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 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 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://corz.org/windows/software/checksum/files/ I had this penciled in for v2, but got an early request! ~ Removed the dividers from the Explorer context menu in the default install; if folk want those, they can uncomment the lines in setup.ini. Apparently these cause issues (weird entries) on non-english language systems. NOTE: if you want to *remove* these dividers, simply uninstall checksum before running the rc5 installer. i.e. do not "upgrade". Your settings in checksum.ini will not be lost. * Fixed an issue where checksum's automatic ini upgrade could leave unexpected comment lines tagged on to the end of the new updated ini. 0.9.23 [rc4 - 1st public beta] * Fixed a bug where under certain (unusual) conditions, checksum could fail to find your system's default browser, and crash. Now, even if you don't *have* a system browser, checksum won't crash about it. * Fixed a bug in simple checksum where OnTop status was being saved to the ini file even when it hadn't changed. This could potentially cause system warning dialogs when running simple checksum in portable mode from read-only media. * Fixed a bug in simple checksum where the current hash case setting wasn't reflected in the prefs dialogs (everything should happen LIVE). * Fixed a bug in simple checksum where the options dialog position was only being read at launch time. If you moved your prefs, closed them, and them opened them again, they would be at the old position. * Fixed an inconsistency in simple checksum's preferences dialog, where OnTop status was being immediately saved to checksum.ini, but algorithm and case settings were only saved if you clicked "okay". Now all settings are saved immediately. This was always true of setting preferences from the application menu. In fact, all the preferences are now in the application menu (and more), so the preferences "dialog", per se, is redundant. However, some folk may prefer this way of doing things, so there's no harm in leaving it in simple checksum, for now. Note: Ctrl+P also closes the preferences dialog, works as a toggle. * Fixed a bug in simple checksum where the options window wasn't dynamically updating its transparency setting when you altered the main windows's transparency (if you had preference transparency enabled in your ini). * Fixed a bug in simple checksum where the hashing dll was being removed on close in portable mode, even when you had specified in your (checksum) prefs that it should stay put. ~ simple checksum now checks for out-of-range transparency, wonky algorithm, and out-of-desktop window settings in the user's ini file, and automatically corrects them. + In preparation for a release proper, checksum and simple checksum got funky new icons, including a larger 48x48 size icon. I also did new document icons, which now read, "hash".. + Added unified hash extension. Rather than create .md5 files for MD5 hashes, and .sha1 files for SHA1 hashes checksum can use a unified ".hash" extension for both type of hash. This is the way forward for hash files, methinks.. checksum, uniquely (syat) interrogates potential hash files on a line-by-line basis, and so will verify both kinds of hashes, even mixed up in the same file; the file extension is irrelevant in determining the format of the hashes contained within. Also, in the future, there will likely be many more hash formats in general use so it makes sense to stop the senseless creation of extraneous file extensions in its tracks! NOTE: if the unified extension is enabled, checksum will merge ("upgrade") existing hash files to match, so you don't end up with both types, but only files of the algorithm you are currently using, so if you are using the MD5 algorithm, checksum will merge only .md5 files in the path, not .sha1 files. In the unlikely event of both .md5 AND .sha1 hashes existing in a folder, running a second checksum create over the folder with the second algorithm, and choosing "Synchronize" from the "File Exists!" dialog will merge the second file into the .hash file, one hash at a time. Any new hashes will be added after that. Both MD5 and SHA1 hashes will then be inside the .hash file. checksum still works with .md5 and .sha1 files exactly as it did before, and the unified extension is completely optional. And once enabled, you will still, of course, be able to verify all the old types. This is "extra" functionality. NOTE: The unified hash extension is ENABLED by default. If you *need* to use legacy .md5 and .sha1 files, simply disable this in your checksum.ini Hopefully other software writers, at least writers of software that utilize hash files, will adopt this unified approach, but for now, only checksum will create and recognize files with a .hash extension. BETA TESTERS NOTE. The "hash" extension will be automatically added to your "ignore_types" preference; you don't have to add it manually. + Improved checksum's cross-platform Line Feed handling, and introduced a new master "line_feed" preference. checksum has always been able to open checksum files from any platform (even mixed up in the same file), now it can intentionally create them, too. At any rate, you can set a master line feed character, which will be used in *all* file writing, that is; checksum's hash files, text/html log files and music playlists. You can choose between "CRLF" (the Windows - and checksum - default Line Break character), "LF" for UNIX Line Feeds, and "CR" for Mac Carriage Returns. You only need this if you need to create hash files to be used on a specific non-windows platform. Most *nix tools can handle checksum files with Windows CRLF line breaks, as well as all Windows tools, of course, so that's the smartest default, but you may have other needs. + Made a slight alteration to the olive.css - errors are now more clearly colored in olive logs. + Introducing... multi-hashing With the unified hash extension working beautifully, there was nothing to stop me; save the fear of throwing a spanner into checksum's finely-tuned inner cogs, and some fun coding; giving checksum the capability of *creating* files with more than one hash algorithm in them. Welcome to multi-hashing. SHA1 AND MD5 hashes in a single file. Yes, a clever inner wrapper enables checksum to do its usual synchronization, and line-by-line checksum interrogation, except rather than skip creating a checksum because one already exists, it will examine the existing hash format, and if the current algorithm isn't there, add the new hash. So now we have the capability to "multi-hash" (TM) our files, and all inside a single unified .hash file. e.g.. 28b7bef31e5fbda6cfb4a4990622c754 *golden boy ep1.avi f0d474af22b9e29843c6aeeb554b88ecac3d04ca *golden boy ep1.avi Multi-Hashing (patend pending) most likely has super-dooper security benefits, too. That's pretty much everything I wanted for a public release. * Release delayed while I chase a few silly bugs I've recently introduced. ~ Rather than simply append any legacy .md5 or .sha1 files onto .hash files, checksum will now interrogate the file and add the old hashes individually. This prevents all sorts of potential unwanted situations and should make switching to unified hashing fairly painless, no matter what kind of hash you've been using previously, even if you used both - checksum will now synchronize everything inside a single unified .hash file, and add all new hashes into that file, regardless of their algorithm. I've still not decided whether or not to make unified hashing the default - I have a feeling that although it may alienate some people (those who wouldn't realize/find out that this could easily be set back to legacy .md5 files, if required), it's the way forward, and so helping folk get there is good. Hmm. ~ During checksum's initial interrogation of potential hash files, checksum will grab only 1MB of data from the file, which prevents someone from running into memory problems by doing something crazy like forcing checksum to treat an DVD ISO image as a hash file. NOTE: checksum will still check the *entire* file for hashes, which has no impact on memory usage, regardless of the size of the file. * Fixed a bug where checksum could be forced to create a hash for a non-existant file (which would be empty). checksum will now halt with a warning if you send it any invalid path. ~ nix_paths paths (for one-file root checksums) is now disabled by default + checksum's ini upgrade process will now retain ALL sections of the ini file, even ones it doesn't know about. This enables writers of custom GUI/wrappers to store their preferences inside checksum.ini, and have them remain after a checksum upgrade. NOTE: checksum produces quite a few different exit/error codes which you can utilize in your applications. They aren't very clever, for now, but if there's enough interest, I could work up a more precise system. Let me know. This is a good place to let you know about hashDROP, a rather cool wee batch-processor GUI for checksum, which I got in my mail yesterday. Thanks seVen! Good work! For hashDROP, see here: http://hashdrop.50webs.com/ * Fixed a bug where your shirtware registration code could be obliterated during an install, and if then inserted, would crash checksum - I haven't paid enough attention to the registration aspect! ~ The Explorer context menu item for regular files has been changed to simply "checksum", which, as well as being neat and verb-like, should prove less confusing if people are using the Ctrl modifier to switch to verify mode; "Create checksum" would be plain wrong. + checksum will now notify you if it applied any unified extensions to legacy hash files. 0.9.22 [rc3] + I've brought back the status information to the final verification dialog, in other words, it will now read.. CHANGED » foo.jpg MISSING » bar.png CHANGED » foobar.png etc. ..as opposed to merely listing the erring files. This functionality slipped away back in 0.9.17 when I created the fancy XHTML logging, but some folk (myself included) missed it, and so it has returned. + checksum can now create music playlists (m3u or pls) with your "root" hash files, as well as with regular folder hashes. This enables you to create One Big Playlist for an entire music archive, or perhaps just your trance albums, or whatever you like. Note: the "nix_paths" setting for root hashes also affects playlist creation; both the direction of the path slashes, and whether or not there's a "./" at the start (true). The music players I've tested don't mind which way round the slashes go, or whether or not you put ".\" at the start of the path, so it's probably cosmetic, though I suspect some players might balk on back-to-front paths on one platform or another. All this is only really worth noting if you share your playlists with others, or other computing platforms around your network. And even then, like I say, most media players don't care. ~ It may not be noted elsewhere - I'll pop it in the prefs, too - but regardless of your checksum file encoding options, music playlists are *always* utf-8 encoded. If you know of a media player that can't handle utf-8, let me know. Same for the logs. * Fixed a bug where under certain rare conditions (creating hashes for files on read-only media, where no valid hashable files exist; for example, they were all "ignored" types) checksum would create an empty checksum file along with the usual info file in the checksums folder on your desktop. These items are now created only when real checksums have been calculated for locked or read-only media. ~ checksum will now only attempt to set the compression bit on your main log folder; that is, the one set in your main preferences. It will still attempt to compress all individual log files, no matter where they are created. + Added a setting for "warn_color", which is the color the progress tip will change to if there are errors. Previously, this was fixed at red. ~ Improved the content of generated info files (e.g. "checksum.nfo") which gets dropped when you create checksums for files on read-only media. I also did a wee ascii "checksum" logo. ;o) * Fixed a bug where exiting checksum during the initial "building list of files" stage of checksum creation caused checksum to crash. ~ checksum will now always present a dialog at the end if you manually exit the creation 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

text that is the name of the checksum file itself. Similarly, a new css class "day_fails" can be accessed to give the main

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 (

date/time). It's a bit ugly, so is disabled by default. But if you want this, there it is. This is not the total time taken for the entire operation, but an exact running tally of the time taken to process each individual hash. NOTE: If "display_times" is disabled, "total_times" is also disabled. ALSO NOTE: If you disable these logging timer prefs, checksum won't bother to time individual hashes, and so there may ironically be a performance improvement. So you have to ask yourself, are you more interested in *seeing* the hash times, or the *actual* hash times! ;o) The difference will be negligible, but still, food for thought. Neither of these two new setting has any effect on the overall timer which displays in the final ToolTip; a single, simple, overall timer. NOTE: these changes also apply to plain text logging. * At some point recently, a local path change in my own system meant the .md5/.sha1 document icons weren't stored inside checksum.exe, as they should be. They are back now. Running the installer (upgrade) will sort everything out, and refresh your desktop icons, too. * seVen sent me a nice olive theme for the logs, so I messed with it, and made an olive version of the background image to accompany it, and dropped it in the extras folder. You can set it as your fallback style, or master style, if you like, or use it as a template for embedded styles. It will also always be available here.. http://corz.org/windows/software/checksum/files/olive.css You can see demos of the log output here.. http://corz.org/windows/software/checksum/files/checksum-example-log-output.html http://corz.org/windows/software/checksum/files/checksum-example-log-output-olive.html * I changed the location of the background image into the same folder as the css files (sorry testers! any logs you made with the old version will point to the wrong place - but I'll leave the image there for a while, yet. If you really need a background image in those old logs, a find & replace will fix them!) I figured it made sense to keep all these resources together - as well as the example logs, and css, there's also alternative css and reg hacks in there. So I've made the folder accessible from the web, and it becomes as kinda drop-box for "extras". Help yourselves! .. http://corz.org/windows/software/checksum/files/ * checksum can now prepend the (base)name of the path checked to the main titles, so you get.. [2006] Rodrigo y Gabriela @ 2007-11-21 14:14:00 instead of just the date & time. If you log all your checksums for a particular path in the same file, you probably don't want this behaviour, but if you do, do.. path_in_titles=true * By default, checksum logs will now open with all the sections closed. Reason: if your logs start to get *large*, all those sections open can slow down your browser's page rendering. You can, of course, click the main title to open all the sections in one go. If you prefer them open, use your own template.html (details below) * Times in the log now have their own style class; "log_times", rather than simply being text, 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:///C:/Design/styles/checksum.css .. or a regular http://address, or whatever you need. * One final note about the log files (for now): checksum drops its header template into your temporary folder while it is working, BUT, if you happen to have a file called "template.html" next to checksum, it will use that instead. You might want to make better JavaScript, or something. To get started, simply copy the output from a log file, down to.. ..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.. 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.