checksum

point-and-click MD5, SHA1 and BLAKE2 hashing for Windows..


verify data the easy way

The world's fastest hashing application, just got faster!

Welcome to checksum, a blisteringly fast, no-nonsense file hashing application for Windows, a program that generates and verifies BLAKE2, SHA1 and MD5 hashes; aka. "MD5 Sums", or "digital fingerprints"; of a file, a folder, or recursively, even through an entire disk or volume, does it extremely quickly, intelligently, and without fuss. Many people strongly believe it to be the best hashing utility on planet Earth.

Did I say fast? Not only mind-blowing hashing speeds (way faster than even the fastest SSD) but the quickest "get stuff done" time. With checksum you point and click and files, folders, even complete hard drives get hashed. Or verified. Simple. checksum just gets on with the job. Click-and-Go..

Available for 64 bit or 32 bit Windows (a basic Linux/UNIX/BSD version is also included).

Why?

In the decade before checksum, I must have installed and uninstalled dozens, perhaps hundreds of Windows MD5 hashing utilities, and overwhelmingly they leave me muttering "brain-dead POS!" under my breath, or words to that effect, or not under my breath. I always knew that data verification should be simple, even easy, but it invariably ended up a chore.

Either the brain-dead programs don't know how to recurse, or don't even pretend to, or they give the MD5 hash files daft, generic names, or they can't handle long file names, or foreign file names, or multiple files, or they run in MS DOS, or choke on UTF-8, or are painfully slow, or insist on presenting me with a complex interface, or don't have any decent hashing algorithms, or don't know how to synchronize new files with old, or have no shell integration or any combination of these things; and I would usually end up shouting "FFS! JUST DO IT!!!".

No more!  Now I have checksum, and it suffers from none of these problems; as well as adding quite a few tricks of its own..

What is it for, exactly?

Peace of mind! BLAKE2, SHA1 and MD5 hashes are used to verify that a file or group of files has not changed. Simple as that. This is useful, even crucial, in all kinds of situations where data integrity is important.

For instance, these days, it's not uncommon to find MD5 hashes (and less rarely now, SHA1 hashes) published alongside downloads, even Windows downloads. This hash, when used, ensures that the file you downloaded is exactly the same file the author uploaded, and hasn't been tampered with in any way, Trojan added, etc.; even the slightest change in the data produces a wildly different hash.

A file hash is also the best way to ensure your 3D Printed propeller blade hasn't been "redesigned" to self-destruct!

checksum on my Windows desktop, hashing like crazy..

It's also useful if you want to compare files and folders/directories; using checksums is far more accurate than simply comparing file sizes, dates or any other property. For quick file compare tasks, there's also checksum's little brother; simple checksum, simply drag & drop Two files for an instant hash-accurate comparison.

peace of mind for your optical data media, with hashing

If you burn a lot of data to CD or DVD, you can use checksum to accurately verify the integrity of your data right after a burn, and at any time in the future. If you distribute data in any way, maybe torrenteering your favourite things, run a file server of some kind, or just email a few files to your friends; hashes enable the person at the other end to be absolutely sure that the file arrived perfectly, 100% intact.

As well as providing secure verification against tampering, virus infection, file (and backup file) corruption, transfer errors and more, digital fingerprints can serve as an "early warning" of possible media failures, be they optical or magnetic. It was a hash failure that recently alerted me to a failing batch of DVD-R disks; I saved my fading data in time, and got a refund on the disks. I'll leave you to consider the million other uses. There's only one reason, though; peace of mind.

Absolutely no-nonsense file verification..

checksum can create (two clicks, or a drag-and-drop) or verify (one click) hashes of a file, a folder, even a whole disk full of files and folders in one simple, no-nonsense, high-performance operation. Basically, you point it at a file or folder and go! The parameters are controlled by command-line switches, but most folk won't have to worry about that; it all happens invisibly, and is built-in to your Windows® Explorer context (aka "concept", aka "right-click") commands (see above).

Note: while checksum operates with command-line switches, it is NOT a Windows® console application; there's no messy DOS box, or anything like that. But if you want to run it from a console, that's covered, too.

There are a wealth of command-line options, but most people find that checksum just works exactly as they would expect, without any messing about; right-click and go! But, if you are the sort who likes to customize and hack at things, you will find plenty to keep you occupied!

On-the-fly configuration..

If you want to change any of checksum's options on-the-fly, simply hold down the SHIFT key when you select its Explorer context menu item, and checksum will pop up a dialog for you to tweak the process. If you want to have anything permanently set, checksum comes with standard plain text Windows ini file for you to tweak to your heart's content. Anyone smart enough to use MD5sums, can edit plain text.

windows checksum creation options dialog

The options dialog is most useful when you want to only hash certain files in a folder, like mp3's, or movies. With your file mask groups, you can configure file-type specific hashing with just a couple of clicks.

checksum creation options dialog, file types group drop-down, regular Windows masks applyCommon music, video, and archive formats come setup and ready to go, and you can easily edit or add to these at any time.

You pop up the options by holding down the SHIFT key when you select the explorer menu item, so it's easy to get to the advanced options whenever you need them. Same goes for verification, though generally you won't need it - checksum is smart enough to just get on with the job, verifying whatever checksum files it finds in the path, be they MD5, SHA1 or BLAKE2, or all of the above, and you'll probably never need to use anything but the default verify command, no matter how advanced you are! And because checksum recognizes other formats of MD5 and SHA1 files (there is no standard BLAKE2 format), it can be used not only to verify and create new checksums, but also verify existing checksum files, even ancient ones, automatically.

I expect there is some weird MD5 file format out there that I don't have an example of, Wang, maybe? but in practice, checksum supports ALL known MD5 verification file formats, that is, known by me. If you find an MD5 file format that checksum doesn't support, send me that file!!

There isn't really a standard SHA1 format yet, but checksum's is pretty good (it's the same as the output from a *NIX sha1sum command in binary mode). Shall we?

windows checksum verfication options dialog

100% Portable..

checksum usually operates as a regular installed desktop application with Explorer context menus, custom .hash, .md5, .sha1 and .blake2 desktop icons, Windows start menu entries, and so on; but checksum can also operate in a completely portable state, and happily works from a pen-drive, DVD, or wherever you happen to be; no less than total portability.

Even with its little brother, simple checksum tagging along, the whole lot fits easily on the smallest pen-drive (the 32 bit version will UPX onto a floppy disk!), enabling you to create BLAKE2, SHA1 and MD5 hashes, wherever you are. To activate portable mode, simply drop a checksum.ini file next to checksum.exe (or run one-time with the "portable" switch), you're done.

It's no problem to run checksum both ways simultaneously, or to run checksum in portable mode on a desktop where checksum is already installed. Simply put, if there's a checksum.ini next to it, checksum will use it, and if there isn't an ini there, checksum uses the one in your user data folder (aka. "Application Data", aka. "AppData").

If you like applications to run in a portable state, even on your own desktop, no problem; you can skip the installer altogether and simply copy the files (checksum.exe and simple checksum.exe) to wherever you like. They are in the installer's files/ directory inside the main zip archive. There's also a checksum.ini inside the archive, so you can unzip-and-go.

Note: Regardless of whether you install checksum or run it in a portable state, its functionality is identical.

Introducing.. The Unified Hash Extension™
And Multi-Hashing™..

checksum uses the MD5, SHA1 and BLAKE2 hashing algorithms, and can create .md5 and .sha1 and .blake2 (or .b2 or whatever you use) files to contain these hashes. But checksum prefers to instead create a single .hash extension for all your hash files, whatever algorithm you use. Welcome to the unified .hash extension..

an imagean imagean imagean image

I feel there are quite enough file extensions to deal with, and with some effort on the part of software developers, this may catch on. I hope it does, anyway, and that you agree. A single, unified hash extension looks like the way forward, to me. All comments welcome, below.

As well as being able to verify MD5, SHA1 and BLAKE2 hashes, even mixed up in the same file, checksum can also create such a file, if you so desire. At any rate, if you start using BLAKE2 or SHA1 hashes some day, you can keep your old MD5 hashes handy, inside your .hash files..

The single, unified hash extension gives us not only the freedom to effortlessly upgrade algorithms at any time, without having to handle yet-another-file-type, but also the ability to easily store output from multiple hashing algorithms inside a single .hash file. Welcome to multi-hashing, which will doubtless have security benefits, to boot (a multi-hash is simply collision-proof).

Lightning fast..

checksum hashing progress fair zipping along

If you do a lot of hashing, you will know that it's an intensive process, and relatively slow. Well, checksum is fast, lightning fast.

Even on my old desktop (a lowly 1.3GHz, where checksum was initially developed) it would rip through a 100MB file in under one second. The latest checksum can crunch data faster than any hard drive or even SSD can supply it. Hashing your average album or TV episode is instantaneous.

With right-click convenience, intelligent recursion and synchronization, full automization, and crazy-fast hashing speeds, digital fingerprinting is no longer a chore, it's a joy!

Okay, I'm getting carried away, but seriously, this is how hashing was always meant to be.

Features..

If you like lists, and who doesn't, here's a list of checksum's "features", as compared to your average md5 utility..

True point-and-click hash creation and verification..

No-brainer hash creation and verification. In a word; simple.

Choice of MD5, SHA1 or BLAKE2 hashing algorithms..

Create a regular MD5sum (128-bit), or further increase security by using the SHA1 algorithm (160-bit). For the ultimate in security, you can create BLAKE2 hashes (technically, BLAKE2s-256, which kicks the SHA family's butt in both security AND hashing speed). checksum recognizes and works with all these formats, even mixed up in the same file.

hash single files, or folders/directories full of files.. no problem..

checksum can create hash files for individual files or folders full of files, and importantly, automatically recognizes both kinds during verification, verifying every kind of checksum file it can find. Also, when creating individual hash files, checksum is smart enough to skip any that already exist.

Effortless recursion (point at a folder/directory or volume and GO!) ..

Not only fully automatic creation and verification of files, and folders full of files, but hash all the files and folders inside, and all the folders inside them, and so on, and so on, through an entire volume, if you desire..  one click! ... Drive hashing is now officially EASY!

LONG PATH support..

All checksum's internal file operations use UNC-style long paths, so can easily create and verify hashes for files with paths of up to 32,767 characters in length. Goodbye MAX_PATH!

Full UNICODE file name support..

checksum can work with file names in ANY language, even the tricky ones like Russian, Arabic, Greek, Japanese, Belarusian and Urdu. checksum can also handle those special characters and symbols that lurk inside many fonts. In short, if you can use it as a Windows file or folder name, checksum can hash it!

"root", folder or individual file hashes, your call..

Some people prefer hashes of folders, some prefer "root" hashes (with an entire volume's hashes in a single file). Some people like individual hashes of every single file. I like all three, depending on the situation, and checksum has always been able to do it all.

Email notifications..

checksum can mail you when it detects errors in your files; especially handy for scheduled tasks running while you are away or otherwise engaged. checksum's Mail-On-Fail can do CC, BCC, SSL, single and multiple file attachments (including attaching your generated log file), mail priority and more.

Multiple user-defined file mask groups..

For instance, hash only audio files, or only movies, whatever you like, available from a handy drop-down menu. All your favourite file types can be stored in custom groups for easy-peezy file-type-specific hashing. e.g..

The most common groups are already provided, and it's trivial to create your own. You can also enter custom masks directly into the one-shot options, e.g. report*.pdf, to hash all the reports in a folder, create ad-hoc groups, or whatever.

Automatic music playlist creation..

Another killer feature; checksum can create music playlist files along with your checksums! When creating a folder hash, if checksum encounters any of the music files you have specified in your preferences; mp3's, ogg files, wma, whatever; it can create a playlist for the collection (i.e.. the album). Rather nifty, and a perfect addition to the custom command in the tips and tricks section.

As well as regular Windows standard .m3u/m3u8 playlist files (Winamp, etc.), checksum also supports .pls (shoutcast/icecast) playlists.

Effortlessly handles all known** legacy md5 files..

If you discover an MD5sum that checksum doesn't support, Send Me That FILE!

Create lowercase or UPPERCASE checksums at will..

Like many things, this can also be set permanently, if you so wish.

Automatic synchronization of old and new files..

Automatically add new hashes to existing checksum files.

That's right! Automatically add new hashes to existing checksum files!

Integrated Windows® Explorer context (right-click) operation..

The installer will setup Windows® Explorer context commands for all files and folders, so you can right-click anything and create or verify checksums at will. Very handy. "setup", the rather clever installer, is also available in its own right, as a free, and 100% ini-driven installer engine for your own goodies. Stuffed with features, easy to use, and definitely deserving a page to itself. Soon.

As explained above, you can also bypass the installer altogether, and simply unzip-and-go, for 100% portable checksumming. Or you can have both.

Scheduler Wizard..

One of checksum's special startup tasks is a Scheduler Wizard, which will guide you simply through the process of creating a checksum scheduled command in Windows Task Scheduler.

Click a few buttons, set your preferences in the familiar one-shot options dialog, and go!

No-fuss intelligent checksum verification..

Cut and paste your own checksum files if you like, rename them, mix and match legacy MD5 formats in a single file, even throw in a few SHA1 or BLAKE2 hashes just for fun; worry not; checksum will work it out!

Permanently ignore any file types..

Obviously we don't want checksums files of checksum files, for starters, but if you have other file types you'd like on a permanent ignore, desktop.ini files, thumbs.db, whatever; it's easy to setup. The most common annoying file types already are.

Ignored folders..

As well as a set of permanently ignored folders (like "System Volume Information", $RECYCLER, and so on) you can set custom ignore masks on a per-job basis, using standard Windows file masks, e.g. "foo*" or "?bar".

Real-time tool-tip style dynamic progress update..

Drag it around the screen - it snaps to the edges, and stays there (checksum also remembers its dialog screen positions, for intuitive, fast operation).

Tool-tip progress can be disabled altogether, if you wish.

Right-click the Tooltip for extra options.

During verification, any failures can be seen real-time in a system tray tool-tip, hover your mouse over the tray icon for details. checksum also flashes the progress tooltip red momentarily, and (optionally) beeps your PC speaker, to let you know of any hash failures. If there were errors, the final tooltip is red (by default). Anything to make life a bit easier.

Verify a mix of multiple (and nested) MD5, SHA1 and BLAKE2 checksum files with a single command..

Does what it says on the can!

Extensionless checksum files..

Traditionally, individual checksum files are named filename.ext.md5. Personally, I find this inelegant, and prefer them to be named filename.md5. I like it so much, I made it the default, but you can change that, if you like. When running extensionless; if checksum encounters multiple files with same name, it simply adds them to the same checksum file, so checksums for foo.txt, foo.htm, and foo.jpg would all go inside foo.md5, or better yet, foo.hash. Highly groovy.

On the verify side of things, checksum has always verified every possible checksum it can find, so these multi-hash file look just like regular folder hash files, and verify perfectly, so long as the data hasn't changed, of course!

Search & Verify Single Files..

With checksum, you can 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, be it in a folder or root (aggregate) hash.

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. Another fantastic time-saver!

This works best as an explorer context menu command (supplied).

Smart checksum file naming, with dynamic @tokens..

checksum file names reflect the actual files or folders checked! Automatically.

If you want more, you can specify either static or dynamic checksum file names, with a wide range of automagically transforming tokens. See below for details.

Report Changed/Corrupt/Missing States..

checksum can optionally store a file's modification date and time along with the checksums, like so..

#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 time stamp is unchanged.

These will show as a different color in your HTML logs.

You can 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 (below) 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!).

Automatically remove hashes for missing files..

Stuff gets deleted, on purpose; fact of computing life. When verifying your hashes, you can have checksum remove those entries from your .hash file automatically, so you never have to think about them again!

The number of deleted hashes, if any, is posted in your final notification.

Automatically update hashes for changed files..

Files gets mindfully altered; another fact of computing life - MP3's get new ID3 tags, documents get edited, and so on. Now you can have your hashes updated, too! That's right! During verification, you can instruct checksum to automatically update (aka. "refresh") those entries (and their associated timestamps) inside your .hash file. No more editing required!

The number of updated hashes, if any, is also posted in your final notification.

Effortless hashing of read-only volumes..

checksum can create BLAKE2, SHA1 and MD5 hashes for the read-only volume, but store the checksum files elsewhere; either with relative paths inside; so you can later copy the checksum file into other copies of the volume, or absolute paths; so you can keep tabs on the originals from anywhere.

checksum currently has three different read-only fall-back strategies to choose from; use whichever most suits your needs.

Extensive logging capabilities, with intelligent log handling and dynamic log naming..

checksum always gives you the option to log failures. But you can log everything if you prefer. hashing times can be included in the logs, and proper CSS classes ensure you can tell what's-what at a glance.

Relative or absolute log file path locations can be configured in your preferences, as can the checksum log name itself; with dynamic date and time, as well as dynamic location and status tokens, so you can customize the output naming format to your exact requirements.

In other words, as well leaving it to checksum to work out automatically, or typing a regular name into your prefs, 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   ...   numeric day of month. from 01 to 31
@mon   ...   numeric 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 is transformed into the name of the file or folder being checked, and @status, which automatically transforms into the current 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

The @status strings can also be individually configured in your prefs, if you wish. Roll the whole thing up, and with the settings above, the final log name might look like..

[2007-11-11 @ 16.43.50] checksums for golden boy [100% AOK!].log

HTML logging with log append and auto log-rotation..

As well as good old plain text, checksum can output logs in lovely XHTML, with CSS used for all style and positional elements. With the ability to append new logs to old, and auto-transforming tokens, you setup automatic daily/monthly/whatever log rotation by doing no more than choosing the correct name. You can even have your logs organized by section and date, all automatically; via the free-energy from your @tokens.

Click here to see a sample of checksum's log output, amongst other things.

Exit Command..

checksum can be instructed to run a program upon job completion. It can also pass its own exit code to the program.

Total cross-platform and legacy md5 file format support..

MD5 and SHA1 hash files from UNIX, Linux, Mac and Solaris, as well as a myriad of legacy Windows and DOS MD5 formats, in fact, every hash file I've ever come across, is supported. Throw any old MD5sum at checksum, and you'll get results. And if you don't (*gasp*), Send Me That FILE!

Work with hidden checksums..

If you don't like to see those .hash files, no problem; checksum can create and verify hidden checksum files as easily as visible ones. Like most options, as well as on-the-fly configuration via the options dialog (hold down SHIFT when you launch checksum), you can set this permanently by altering checksum.ini.

To create hidden checksums (same as attrib +h), use "h" on the command-line, or choose that option from the options dialog.

Don't worry about creating music playlists with the invisible option enabled, the playlists will be perfectly visible, only the checksums get hidden! (well, someone asked! ;o)

"Quiet" operation..

Handy if you are making scheduled items, etc, and want to disable all dialogs and notifications. Simply add a 'q' (or check the box in the one-shot options).

You can also set checksum to only pop up dialogs for "long operations". Just how long constitutes a long operation, is of course, up to you. The default is 0, so you get "SUCCESS!", even if it only took a millisecond. Check your preferences for many more wee tricks like this.

"No-Lock" file reading..

checksum doesn't care is a file is in-use, it will hash it anyway! And it won't lock your files up while it's doing it. Feel free to point checksum at any folder.

Audio alerts..

Unrelated to the "quiet" option (above), checksum can thoughtfully invoke your PC speaker to notify you of any verification failures as they happen, as well as shorter double-pips on completion (if your PC supports this - many modern PCs don't). You can even specify the exact KHz value for the beeps, whatever suits you best.

You can also assign WAV files for the success and failure sounds, if you prefer. A few samples can be found here.

Drag-and-drop files, folders and drives onto checksum..

If you prefer to drag and drop things, you can keep checksum (or a shortcut to it) handy on your desktop/toolbars/SendTo menu, and drag files or folders onto it for instant checksum creation. This works for verification, too; if you drag a hash file onto checksum, its hashes are instantly verified.

Note: like regular menu activation, you can use the SHIFT key to pop-up the options dialog at launch-time. You can also drag and drop files and folders onto the one-shot options dialogs, to have their paths automatically inserted for you.

User preferences are stored in a plain text Windows® ini file..

You can look at it, edit it, back it up, script with it, and handle it. Lots of things can be tweaked and set from here, though 99.36% of people will probably find the defaults are just fine, and the one-shot option dialogs handle everything else they could ever need. But if you are a more advanced user, with special requirements, chances are checksum has a setting just for you. Click here to find out more about checksum.ini

Comprehensive set of command-line switches..

Normally with checksum, you simply click-and-go; but checksum also accepts a large number of command-line switches. If you are creating a custom front-end, modifying your explorer context menu commands, or creating a custom scheduled task or batch file, take a look at checksum's many switches. For lots more details, see here.

If you simply have some special task to perform, it can probably be achieved via the one-shot options dialog.

Shutdown when done..

If your system doesn't normally run 24/7, don't let that stop you from hashing Terabytes of data! checksum can be instructed to shutdown your PC at the end of the job.

That's a lot of features! And it's not even them all!

checksum is jam-packed with thoughtful little touches, you might even call it Artificial Intelligence! Wherever possible, if checksum can anticipate and interpret users, it will.

checksum icon

Legacy and cross-platform MD5/SHA1 file formats that checksum can handle..

If you look inside any MD5/SHA1 checksum file - it's plain text - you find all sorts of things.

Here's what a regular (MD5) checksum file looks like..

01805fe7528f0d98c595ba97b798717a *01 - Stygian Vista (radio controlled).mp3

Each line begins with the MD5/SHA1 digest (hash), followed by a space, then an asterisk, then the filename. It's a clear format, flexible, relatively fool-proof ("*" is not allowed on any file system), and well supported.

Other formats I've come across..

single file single MD5/SHA1 hash types - these necessarily have the same name as the file, with ".md5" or ".sha1" extension added, and are often hand-made by system admins, or else piped from a shell md5/sha command) ..

01805fe7528f0d98c595ba97b798717a
4988ae20125db807143f84dbe09df9782c3c033a

space delimited hashes (before we figured out the clever asterisk)..

01805fe7528f0d98c595ba97b798717a 01 - Stygian Vista (radio controlled).mp3
4988ae20125db807143f84dbe09df9782c3c033a 01 - Stygian Vista (radio controlled).mp3

double-space delimited hashes (just silly, really)..
Believe it or not, this is the de-facto standard for md5 files, mainly because it's the output from the UNIX md5sum/sha1sum command in 'text' mode, which amazingly; is the default setting. By the way; md5sum's "-b" or "--binary" switch overrides this insanity.

01805fe7528f0d98c595ba97b798717a  01 - Stygian Vista (radio controlled).mp3
4988ae20125db807143f84dbe09df9782c3c033a  01 - Stygian Vista (radio controlled).mp3

TAB delimited hashes (I am assured these do exist!)..

01805fe7528f0d98c595ba97b798717a 01 - Stygian Vista (radio controlled).mp3
4988ae20125db807143f84dbe09df9782c3c033a 01 - Stygian Vista (radio controlled).mp3

back-to-front hashes in parenthesis - this is quite a common format around the UNIX/Solaris archives of the world (it's the output from openssl dgst command) ..

MD5(01 - Stygian Vista (radio controlled).mp3)= 01805fe7528f0d98c595ba97b798717a  or..
MD5 (01 - Stygian Vista (radio controlled).mp3) = 01805fe7528f0d98c595ba97b798717a  even..
SHA1(01 - Stygian Vista (radio controlled).mp3)= 4988ae20125db807143f84dbe09df9782c3c033a

checksum supports verification of all  these formats with ease, so feel free to point it at any old folder structure, Linux CD, whatever, or any .md5 or .sha1 files you have lying around, and get results.

And in case the above track names got you googled here, yes, checksum also works great in Microsoft® Vista, and Windows 7, Windows 8, Windows 8.1, Windows 10 and Windows Server of course, even XP! ;o)

simple checksum

the GUI of simple checksum, checksum's wee brother app for drag & drop hashing

Supplied along with checksum is checksum's little brother app, "simple checksum", a supremely simple, handy, free, and highly cute drag-and-drop desktop checksumming tool utilizing checksum's ultra-fast hashing library; for all those "wee" hashing tasks..

Drop a file onto simple checksum, get an instant MD5, SHA1 or BLAKE2 hash readout.

Drop two files, and get an instant MD5, SHA1 or BLAKE2 file compare.

Drop two folders, and get a hash-perfect folder compare (using checksum as the back-end).

Drop a file onto simple checksum with a hash in your clipboard, get an instant clipboard hash compare.

And that works from your "SendTo" menu, too (select two files - SendTo simple checksum.. instant file compare; send two folder, get a hash-perfect folder compare), as well as drag and drop onto simple checksum itself, or a shortcut to simple checksum.

Packed with intuitive HotKeys and time-saving automatic settings, simple checksum is Handy Indeed!

And simple checksum is COMPLETELY FREE, as in beer. Check it out..

128px version of simple checksum's icon

download

Download and use checksum, for free..

download

checksum

click to see zip archive contents

LIVE MD5+SHA1 Multi-Hashes..
# made with checksum.. point-and-click hashing for windows (64-bit edition). # from corz.org.. http://corz.org/windows/software/checksum/ # #md5#checksum.zip#2015.07.04@01.26:25 024f061d2262d95d0864fa558fd938f9 *checksum.zip #sha1#checksum.zip#2015.07.04@01.26:25 199ef31f91c06786a05eeead114c026a67426488 *checksum.zip
download

checksum x64

click to see zip archive contents

LIVE MD5+SHA1 Multi-Hashes..
# made with checksum.. point-and-click hashing for windows (64-bit edition). # from corz.org.. http://corz.org/windows/software/checksum/ # #md5#checksum_x64.zip#2015.07.04@01.26:28 72e1cac7bd2dfd4ce3cf862920350bfa *checksum_x64.zip #sha1#checksum_x64.zip#2015.07.04@01.26:28 86d8db98f96b5c8e196594667b9d324e066f4215 *checksum_x64.zip

NOTE: If your Anti-Virus software detects anything in this software, I recommend you switch to an Anti-Virus that isn't brain-dead. If you DO discover an actual virus, malware, trojan, or anything of that nature inside this software, please mail me, and I will send you a cheque for a Million Pounds, as a reward. In other words, this software is clean.

These guys agree..
(note: I've now removed checksum from most of these sites!)

the Softpedia 100% Clean logo the windows 10 download logo the mad download editor's choice logo CHECKSUM antivirus scan report at rosoftdownload.com checksum antivirus report at download3k.com CHECKSUM antivirus scan report at softoxi.com todaysoftware 100% clean award todaysoftware 5 star Excellence award 5 star award logo bluechillies 5 star award windows7download 5 star award logo checksum's TopShareware 100% CLEAN, of course. checksum's TopShareware award.. 5/5 sharewarecentral 5 star award logo top4download 5 star award logo top4download 5 star award logo download2pc 5 thumbs up award logo Shareup Networks checksum at  filefishstick Forte Downloads

(Ahh.. The beauty of PAD Files!)

License Upgrade

If you need to upgrade your ancient license to the new format (checksum v1.3+) go here.

Itstory..
aka. 'version info', aka. 'changes'..

This is usually bang-up-to-date, and will keep you informed if you are messing around with the latest beta, and let you know what's coming up next. Note: it was getting a bit long to include here in the main page, so now there's a link to the original document, instead..

You can get the latest version.nfo in a pop-up windoid, here, or via a regular link at the top of this page.

Leave a comment about checksum..

If you think you have found a bug, click here. If you want to suggest a feature, click here. For anything else, feel free to leave a comment below..


previous comments (fourty three pages)   show all comments

Caleb - 15.10.15 6:42 am

Hi I am happy to be testing your program and have a feature request that will make it even more useful:

Context: I have several terabytes of image (photo) files and perform periodic archiving of backup disks. At times I want to test the integrity of the archive disk (against themselves to ensure no file corruption) and also to tect the active master disk to against the archive.

I know I can do a top level directory hash and verify an entire disk. I also know I can set checksum to create separate hash files in each folder. Those options are great, thanks. At times I want to test a full directory, other times I want to test a sub directory e.g. year and others I want to test a folder.

When I check my working directory disks to my archive disks I expect some files to change, specifically .xml sidecar files to RAW files and jpgs and DNG files. These all change when Adobe Lightroom (or other raw processor) writes updates metadata written to non-RAW formats.

Based on the above...

Requests:

1) Root and Folder checksums in one pass: To avoid re-running checksum multiple times to produce BOTH the top level hash AND the folder level hash files could you enable a both level hash files be created in a single run, i.e. I could select both FOLDER (DEFAULT) CHECKSUM and ROOT CHECKSUM? Taking this one step further, might you consider an option for a checksum at each level of a directory tree? In my example then I could verify at root, year and folder levels.

2) Filter verification file target: Even more important than #1 is: It would be great if one could verify only a subset of the checksum files in a hash file. In other words, if I have a root checksum hash file and only want to verify RAW files or only want to verify files from a given year or subdirectory it would be great to have that option. This could be done with a combination of file type filter and a directory structure check-box that would permit checking/un-checking part of the drive directory to yield the desired levels/folders to verify. With terabytes of files and different verification needs at different times (weekly vs monthly vs yearly) this would save huge time vs verifying entire roots of all file types (or having so many different checksum hash files created for desired filters at multiple directory levels.

3) Filter/Hide/Sort log report: With huge drives holding hundreds of thousands of files it would be great to be able to filter/hide/sort the verification log/report. It would also be great to be able to export this to a text or other file for deeper investigation (possibly the filtering would be easy for the user if imported to excel, etc. The point here is that if one gets a large number of failures (or expected changed files from archive to working drive comparison) one wants to examine the results via filters/sorting/hiding to drill down to what is important to know from the verification result, i.e. too many failure listings become meaningless because cant digest quantity of raw info.

Sorry for the very long request. I spent the entire day researching programs like yours and find yours to be the best and am hoping you can incorporate these features I found in other less good programs.

THanks!!!!


An excellent feature request, albeit on the wrong page! smiley for :D (I may move it to the tricks and tips page, as it's a good example of how to ask for things)

OK, 1. I have considered adding an option to create root hashes at every level of a tree, for exactly the reasons you specify but decided against it at the time because the downside (massive time taken if someone simply decides to verify the actual root).

Creating both root and folder hashes in a single run sounds doable, but the code involved Vs how easy it is for users to create a batch script/batch runner job/run two jobs means it unlikely to be done soon, unless a) someone REALLY wants it and buys a big license or b) I figure out an elegant and quick way to achieve this.

I've been working on ffe for the last month+ so the inner workings of checksum are like childhood memories at the moment. I'll get back to you about this when I'm back inside checksum.

2. I like the first part of this idea and have added it to my 2do list. I am referring to verifying only certain files/hashes based on a set of filters/wildcards, e.g. "*.mkv".

As for the ignoring certain parts of the tree, again, this sounds like a lot of work that only one or two people would benefit from. And again, hey, if those people are generous, I'll dive into it! Besides, checksum can already do a lot of this if you utilize its ignore feature. Setup verification commands/schedules for different jobs with different ignore parameters. If you need lots of commands, check out Batch Runner.

As for 3, I'm pretty sure checksum can already output plain text logs (the HTML came later), do..

log_format=text

From there, you and your text editor can filter away to your heart's content!

Seriously though, I like the idea of filtering the logs. What sort of things would you be looking to filter in/out?

;o)



Kieran Vyas - 20.10.15 6:18 am

Hello! Thank you for this amazing software. How can I create an md5 checksum file with the extension .md5 instead of .hash? Thank you

Thanks! If you really must, see inside checksum.ini ..

unified_extension=false

;o)



Hans Schulze - 30.11.15 4:03 am

I have a library of large mp4 files on a NAS, and a trying to build a hash file on Win10.
After hashing a dozen or more files, the program crashes. I tried several times.

I looked into various things, and found a faulty lan cable. I changed the cable and found the problem goes away.

Maybe need a bit better error handling?

There isn't AFAIK a good automated way to simulate network errors, so people can test their software for failure modes. Unplugging the cable works smiley for :eek:

Hah! smiley for :roll: I'll add it to by test suite! Cheers!

checksum already handles disconnecting drives, ejected media and other interferences with aplomb. I'll see what I can do.

;o)

ps. you might want to look into Checksum for Linux (inside the main checksum distro), build your hashes locally.



Clark - 05.01.16 1:55 am

Hi Cor -

Been using checksum for about a year, now -- Really loving it, Finally I have peace of mind that I am not backing up corrupted files!!!

Is there a way to tell checksum to create a log that verifies checksum did run and that no errors were found (like in the pop-up when running it manually)?

Ideally, in the log filename, and maybe a the number of hashes verified in the log itself.

For example, File name: [2016-01-04] TUNES - NO ERRORS.htm
log contents: Success! no errors. All data is 100% intact. 4222 hashes verified.

What I've been doing so far is using task scheduler to run scripts -- First it moves any existing checksum logs from the log directory, then runs checksum, then checks for the existence of a new log (indicating errors found), then appends to a separate log whether there were errors or not. It works, but its convoluted, and kind of tedious because I have about 35 separate scripts that I use to verify all my data. So, then I need to open each of the 35 script logs and scroll to the bottom of the log to see whether checksum found errors or not. Then, if errors were found, go locate the checksum log and open it to see the errors. (Yes, I'm that obsessive about my files.)

It would be great to just open the checksum log folder, check the log file names and be able to confirm that checksum did run as scheduled and whether errors were found at a glance.

If this is mentioned in the .ini file, I apologize for taking up your time reading this, but I didn't see it. If not, maybe something you could work into a future release?

BTW, I registered checksum a couple months ago -- I hope you're doing really well, because your software is really top-shelf!

Peace!


First you need the "l" switch ("Log Everything" - note, this will create LARGE logs), then you need to include the status in the log name ("@status" token). But I don't recommend this.

It sounds like you are creating work for yourself. checksum's normal settings work fine. If there is no log, that means the data is 100%. Job Done. Simply checking for the existence (or not) of a log, is enough. Then, only if a log is created do you need to investigate further.

Remember also, checksum will return a non-zero exit code, which you can check in your script.

;o)

ps. Thanks. I'm great, but as for software sales.. not so much. I think I'm currently hovering around 20p/hour for my work on checksum. smiley for :erm: Perhaps I need to re-think my "use-it-for-free" policy.



Lucas - 25.01.16 4:24 am

You're the man Cor!

Thanks for adding the 2 flags I asked for, namely "delete_missing_hashes" and "update_changed_hashes". The last 2 things I was missing in your checksum software!

I got one question. It's not as important feature for me as the 2 above but I think it would be nice to have. Would it be possible to allow to change the "shutdown_when_done" flag dynamicaly per checksum process? I mean lets say I start a checksum operation and in the middle I decide I would like to shutdown the computer when it finishes. Currently (from my understanding) the setting is set in stone in the checksum.ini and it is unchangable after the checksum operation starts. It would be great if I could turn that setting on/off while the checksum operation is ongoing.


Good Idea! My machine never shuts down, so it's not something I think about, but I can see how this would be useful. I'll put that in the 2do list. ;o)



Mr. Hash - 01.02.16 1:06 am

Hi Cor! I've been evaluating checksum lately and find it quite useful and generally well-built. I do have some feedback which might be useful for you so I thought I would share it.

First, I managed to spot what I think are a few tiny bugs.

1) When asked to verify an individual file (checksum vi C:\test.txt), checksum will forget to look at individual hash files if there's file extension in their name (test.txt.hash); AND/OR folder-level hash files which have checksum.ini-configured custom names (hashfile_name=MyHash); the result is that it will report "No matching hash could be found!", even though the respective hash entries are available in the checksum-created .hash files with a naming scheme mentioned above.

2) When asked to hash the modified files in a directory (checksum vwm C:\dir), checksum will do so; however, every entry in the .hash file, which is modified via this routine, will have "md5" as hash name in its hash header, regardless of the actual hash type (the modified hash itself is of correct type). So you might see something like this, where the hash header says it's md5, but the hash itself is blake2:

#md5#test.txt#2016.01.01@12.00:00
d74dc3ac2ac95f346fb3bd30606d214e65ca7dc76f1dd6454f5a1d94b870benc *test.txt

Currently it doesn't break anything, since checksum seems to infer hash type from the hash itself, but I suppose that is not the intended behaviour.

3) When using allow_multiple=queue setting, checksum robustly misses some of the files which should have been added to the queue. For example, I can select 3 files and launch an individual verify operation (checksum vi file_path) via explorer shell menu on Windows 7, but only 2 out of the 3 files will be verified. Similarly, I can get 4 out of 7; even 4 out of 10. Tested on a few-years-old 3+GHz Intel 4-core processor. I suspect the root of the problem is in that checksum re-launches itself to process the next queued item (instead of making an internal call to the relevant part of the code), and that interferes with adding items to the queue, if the timing is right. This may be exacerbated by the unregistered version splash on startup (I assume the splash is removed upon registration) - cannot immediately verify that since I'm playing with the unregistered version so far.

Second, there are a few improvements which I feel like I should suggest.

1) I saw this one mentioned in another comment and you didn't seem to appreciate it. Normally, that would stop me from bringing it up, but being involved with software engineering and UX, I really feel this would make checksum more intuitive and powerful, AND the necessary code appears to be already there... What I'm talking about is that for a user who opens a hash file with checksum the reasonable expectation would be that checksum will check the entries inside the hash file against the file system, and report any inconsistencies. Any files that are not listed inside the hash file are irrelevant to that procedure. That is logical and makes sense. And that is how checksum does it. Now, for a user who right-clicks a directory and selects Verify the reasonable expectation would be that checksum will check the files inside that directory against the available hash files, and report all inconsistencies - be it corrupted, missing, changed, or new (unhashed) files. That is logical and makes a lot of sense too. I imagine that when checksum is run with cy flags it does most of what would be needed to implement this, the rest being in the code for the current verify. Why would this be useful? If you deal with a directory which was modified since checksums had been created, you may want to check its state before updating the hashes. When doing so you want to see whether the changes are aligned with your expectations (the missing files are the ones you deleted, the changed files are the ones you explicitly modified, the unhashed files are the ones that you have added, no corrupt files are present). This allows to update the hashes without doubt. Currently, I see no simple way to achieve this kind of verification.

2) Since the assumption behind checksum is that any file may become corrupted, unpredictably, and the function of the app is to reliably detect such corruption and inform the user - it seems reasonable for checksum to expect corruption of the hash file itself, and have at least some option to deal with it. Currently, every report about a corrupted file may mean one of two things: either the reported file had been corrupted, or the respective part in the hash file had been corrupted. Having a checksum of the hash file at the end of said hash file would solve this...

3) It's good to have a progress indicator during longer operations, but the (sometimes) very rapidly changing text in the Progress ToolTip can be quite annoying to some people. A simpler variant (e.g. with operation type & progress %) might be a good idea.

4) And this is a really tiny one. Checksum offers an option to open the log folder after it has logged something. Having the same kind of option where it would open the log FILE would be nice too.

Sorry for such a long post, I hope some of my feedback was worth reading.

In any case I want to thank you for your work on checksum, and wish you all the best!


Thank you for your detailed feedback. I will look into the bugs. 1. seems likely - that feature is still pretty new and barely tested (The downside of checksums immense flexibility is that I rely on others to try out the zillion possibilities that checksum offers!). 2. Aye, at this point, checksum does not rely on this information but as you correctly assume, interrogates the actual hash to determine its type. 3. I hadn't considered the unregistered splash's effect on queueing. Doh!

As for your suggestions, all reasonable and already mostly under consideration. A simplified progress indicator is on the cards. Opening the log file I hadn't considered, but is now in my 2do list.

A lot of work has gone into checksum's verify routines as you know; adding the facility to check for un-hashed files will now be easier to implement and this is something I hope to do in a future version.

Hashing the hash file is a nice idea, but storing it inside the actual hash file creates its own problems. Being plain text, they often find themselves being edited inside text editors and such, which would, of course, alter the file's hash.

Also, if the hash file itself becomes corrupted, its utility is obviously greatly diminished, so knowing that it is corrupted is not a big help, other than to inform us that the following results are not be trusted. And what if only the hash is corrupted? I briefly went here at the beginning of checksum's development (a decade ago) but decided it was a can of worms best left unopened.

A better approach for users who want this sort of double-protection might be to copy their .hash files to a second (backup) location. Even per-folder hashes can be easily collected up inside an archive and stored elsewhere. I should add, in all the years checksum has been around, no one has ever reported this happening!

Thanks again, good post.

;o)



Ivan Toniolli - 01.02.16 4:35 pm

I was wondering which is the best way to achieve this.
1) I have moved data from 4 hard disks to a single hard disk
2) I would like to check that the data from each disk has moved successfully to the new merged data disk
3) I don't want to do this folder by folder (we are talking about thousands of folders adding up to 4TB)
4) Ideally I don't want to write any files inside the nested folders (those are my movie folders and ideally I don't want to change anything inside those folders)

What is the best way for me to achieve this? if I do a DISK checsum for both disks and then compare them, what information will I get?

Create a root hash in each of the four original drives. Move those hash files to the new drives and then tell checksum to verify the new drive. That's it! ;o)



Ivan Toniolli - 01.02.16 6:57 pm

Thanks for the quick reply. Will it work also if I moved other data already onto the new drive (data that is not on any of the original four drives)

Yes, it will work. checksum will verify only the hashes it finds inside .hash files. If you have created new .hash files for your new files, they too will be verified. Start your verify in the root of the (new) drive and every .hash file in the drive will be verified. ;o)



Ivan Toniolli - 01.02.16 8:11 pm

You said that:

"Checksum will verify only the hashes it finds inside .hash files."
I assume this will happen when I right click on the hash file for the drive I moved across to the new drive from the old drive, and I select which entry exactly?

So this is my understanding of the steps required
1) I right click on the 4 old drives and select "create Checksums...", but also press the shift key so I can ask for a single root hash to be created. I leave everything else unchanged
3) Move the hash files created on the 4 old drives to the new drives
4) right click on each .hash file and choose which option?

What is the output of action 4? A report that will tell me that all the files in the hash file for the drive were found on the new drive, and were identical?


It's all good up to step 4.

You want to either a) right-click the DRIVE and choose "Verify checksums..", or else open the drive to the root folder and right-click in the empty space and choose the exact same option. Both actions do the same thing: verify every checksum file on the drive in one single operation. Assuming the directory structures have not changed, it will work fine.

If everything is 100%, there will be no output, other than a success dialog. If there are errors, checksum will let you know and possibly create a log file.

If you are confused, I recommend playing around with checksum on a smaller set of files until you are familiar with how it works.

;o)



CRV - 11.02.16 5:46 am

Hello,

Your checksum software seems great, and I would love to try it out, but I am concerned about some of the hits it gets on VirusTotal.com, especially when I would install it on my company's servers.

Could you give us a reason why some virus scanners show it as malware, or perhaps post the lines of code that you think is tripping up the scanner?

Thanks in advance!

CRV


Lesser AV companies tend old-school pattern-based recognition. The AutoIt code part is what does it.

Load this page with all comments for discussions along these lines.

;o)



SlrG - 04.04.16 2:39 am

Thank you very much, for this great utility! It makes generating and checking hashes a breeze. But I have an enhancement request. Could you add support for checking the longer blake2 hashes? I'm using another tool to generate blake2 hashes on my unRAID server, but sadly that are the long version blake2. Your tool seems to generate short version ones and when it encounters the long ones, it thinks they are sha256.


checksum doesn't consider any hash to be SHA256! As for the BLAKE2, there are no immediate plans to add other BLAKE2 algorithms to the mix. ;o)



next comments (2 pages)

First, confirm that you are human by entering the code you see..

(if you find the code difficult to decipher, click it for a new one!)


Enter the 5-digit code this text sounds like :

lower-case queue, Upper-Case Elle, thuree, lower-case en, Upper-Case Arrgh


 

Welcome to corz.org!

I'm always messing around with the back-end.. See a bug? Wait a minute and try again. Still see a bug? Mail Me!