# checksum a point-and-click sha1 and md5 hashing application for windows..

## After years searching for the perfect Windows file verification utility, I decided to write it!

Welcome to checksum, a blisteringly fast, no-nonsense file hashing application for Windows. checksum is a program that generates and verifies SHA1 and MD5 hashes; aka. "MD5 Sums", or "digital fingerprints"; of a file, a folder, or recursively, even through an entire hard drive, does it very quickly, intelligently, and without fuss. I think it's the best checksum utility on planet Earth, of course.

Normally I would put a cute image of the program here, but generally speaking, you don't see checksum running, it just gets on with the job. However, checksum does - optionally - pop up a cute progress ToolTip windoid, so I'll show you that instead..

### 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 any combination of these things; I usually end up shouting "FUXAKE! JUST DO IT WILL YA!!!".

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

### What is it for, exactly?

Peace of mind! 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.

It's also very 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.

If you burn a lot of data to CD or DVD, you can use a hash checker 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; checksums enables the person at the other end to be absolutley 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 checksum 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) both SHA1 and MD5 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.

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.

Common 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 or SHA1, or both, and you'll probably never need to use anything but the default verify command, nomatter how advanced you are! And because checksum recognizes other formats of MD5 and SHA1 files, 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 it to me!

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?

## 100% Portable..

checksum usually operates as a regular installed desktop application with Explorer context menus, custom .hash, .md5 and .sha1 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 a floppy disk (remember those?) or pen-drive, enabling you to create SHA1 and MD5 hashes, wherever you are. To activate portable mode, simply drop a checksum.ini file next to checksum.exe, 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 extract files.zip to wherever you like. It's in the installer's files/ directory. There's also a checksum.ini inside the archive, so you can unzip-and-go.

Note: Regardless of whether you install or run checksum portably, its functionality is identical.

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

checksum uses the MD5 and SHA1 hashing algorithms, and creates .md5 and .sha1 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..

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 both MD5 and SHA1 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 SHA1 hashes some day, you can keep your old MD5s 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.

### Fast, bloody fast..

If you do a lot of SHA1 or MD5 hashing, you'll know that it's an intensive process, and relatively slow. Well, checksum is fast, very 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. Hashing your average album 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 or SHA1 hashing algorithms.

Create a regular MD5sum (128-bit), or further increase security by using the SHA1 algorithm (160-bit). checksum recognizes and works with both 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!

#### Multiple user-defined file mask groups.

For instance, hash only MP3 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..

music=*.mp3,*.wav,*.ogg,*.flac,*.ape,*.shn,*.mpc,*.mp2

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. reports-*.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 playlist files (Winamp, etc.), checksum also supports .pls playlists (shoutcast/icecast). Your call.

#### 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.

#### 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 hashes just for fun; worry not; checksum will work it out!

#### Can be configured to 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.

#### 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 and sha1 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!

#### 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.

#### Effortless hashing of read-only volumes.

checksum can create 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 fallback 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.

#### 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 checksum 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 the dialogs. Simply add a 'q'.

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 ini for more wee tricks like this.

Unrelated to the "quiet" option (above), checksum can thoughtfully invoke your peecee speaker to notify you of any verification failures as they happen, as well as shorter double-pips on completion. 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.

#### 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, 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.

## 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

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 of course. ;o)

## simple checksum

Installed 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; for all those "wee" hashing tasks..

Drop a file onto simple checksum, get an instant MD5 or SHA-1 hash readout.

Drop two files, and get an instant MD5 or SHA-1 file compare.

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), 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 Very Handy Indeed!

LIVE MD5+SHA1 Multi-Hashes..
﻿# made with checksum..  point-and-click hashing for windows.
# from corz.org.. http://corz.org/windows/software/checksum/
#
7024ccb56480d868b82127e53bdb7a6e *checksum.zip
52c83b9c396d30f474b6eff6cc625b2311158be1 *checksum.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..

(Ahh.. The beauty of PAD Files!)

## 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..

## itstory is here

CJ - 02.10.07 5:04 pm

Will checksum do a hash of a complete drive as well? Is there a size limitation?
Situation: I want to confirm an accurate duplication of a hard drive.
Also, can it create a printout to report time and date and the two hashes?

cor - 02.10.07 7:55 pm

I don't know what you mean about "the two hashes" (each file gets only one), but apart from that..

Yes, complete drives are no problem, I hash entire DVD's regularly. I recently checksummed my entire archive drive, too (160GB)

No, there is no size limit, at least, theoretically. I've not tried anything much over 1.5GB, but there shouldn't be any problems hashing even really huge files.

Logging only takes place on verification, but yes, you can tell checksum to log every single item, success or fail, and the log is always timestamped, looks something like this..
checksum report [2007-10-02 19:54:18] ..
--------------------------------------------------------------------------------
Passed: P:\audio\-= world modern =-\-=Trilok Gurtu=-\[2004] Broken Rhythms\01 - Broken rhythms.mp3
Passed: P:\audio\-= world modern =-\-=Trilok Gurtu=-\[2004] Broken Rhythms\02 - Kabir.mp3
etc.
Send me a mail; I'll be putting out the latest beta some time this week (all those who have previously mailed will get something in their inbox very soon) so you can play with it, and let me know how big it really goes.

for now..

;o) Cor

ps. about the "two hashes", do you mean, the original drive, and the duplicated drive? I suspect so. The way to do it is simply run checksum on the drive before duplication, and then afterwards, run checksum again (in verify mode) on the duplicate drive. The checksum files will have been duplicated along with the drive. Keeping the checksum files along with the real files is the best method, by far.

phil - 11.11.07 11:45 pm

hello,

very interesting what you wrote down here, what do I need to do, in order to get a copy of your program :-)

currently I'm using md5summer (http://www.md5summer.org/download.html) to get the job done, but your app looks much more powerfull.

hope you release it as GPL?

Best regards from berlin/germany

- Phil

cor - 12.11.07 9:07 am

I agree, Phil! Very interesting indeed!

How do you get a copy? Join the "ßeta program", unless you are running XP, I have enough XP testers! However, I am keen to enroll someone running Vista - mail me for details.

You're right, checksum looks much more powerful. That's because it is. Nothing even comes close. From a recent mail from one of the beta testers (all hardened MD5 utility users)..

I must say, the more I use checksum the more I love it. It's pretty hard not to love it. Once it comes out of beta it will easily capture the hearts of many. That I know for a fact! Now... back to testing

I love that quote!
I already have a bag of similar quotes, and it's not even released!

Guys! Post them HERE, eh!

hope you release it as GPL?

No.

Ironically, all my other apps are open source, and though they get many downloads, source packs, too; no one ever mails me about them, or offers their appreciation and thanks, or asks about the licensing terms - copy+paste is easier. Okay, my /windows area hasn't been up for long, but still; already THREE people have asked me if I plan to release the code for checksum! What does this tell you?

But no. I plan to keep this one all to myself. I know from experience that when you release code, it just gets ripped off, and folk go on to claim it as their own (I've got loads of php 'out there', thinly disguised as other things). Almost never will you get actual credit. I don't mind too much, I do it for me, and release it because I can, and have a knack for readable documentation.

With checksum, I decided that there was just so much cool stuff going on inside, no way was I going to let someone come along and just steal it. It's MY baby!

The other reason is that I plan to charge for the full version (the free version will be MD5-only) because I'd like this place to start making some cash! An artist's gotta eat, you know.

for now..

;o) Cor

phil - 12.11.07 9:20 pm

I just came across another app that gets the job done:

www.slavasoft .com/fsum

While I can understand, that you hope to get some ca$h, but the problem I think that every security related application has to be OpenSource so that everybody can check the source-code if there are any threats. But of course I can also understand if you want to earn some money - hope it doesn't cost too much, but from what I understand there will be also a free version, nice. I sometimes use paypal to honor good work from people, releasing their work for free. keep us informed about future updates - if you're interested in beta-testing for win2k, drop me a line. - Phil cor - 12.11.07 11:02 pm I just came across another app that gets the job done: www.slavasoft .com/fsum One of many many many that will "do the job", but not in a way that this human finds acceptable. And judging by my inbox recently, many other humans, too. While I can understand, that you hope to get some ca$h, but the problem I think that every security related application has to be OpenSource so that everybody can check the source-code if there are any threats.

No. Checksum implements widely-known, open-source algorithms. There's nothing inherently secure or insecure about checksum itself, so these sorts of concerns would be completely misplaced.

Both the MD5 and SHA1 algorithms are not only open source, they are public domain - feel free to check their robustness at any recognized code archive, as well as checksum's ability to 100% comply with their specifications using the reference checksums provided at MIT, wikipedia, etc.

Even if I wrote the loosest, most insecure code on the planet (which I don't), it wouldn't affect anyone's security in the slightest, so long as the checksum's themselves are 100% accurate, which they are. Bottom line: the only person that needs to see the source, is me.

But of course I can also understand if you want to earn some money - hope it doesn't cost too much, but from what I understand there will be also a free version, nice.

Yes, I do! I've been releasing open source code for years, with tens of thousands of users, yet I could count the donations on one hand. But in spite of that, yes, there will be a free version. The only difference; the free version will do MD5 only. For the vast majority of people, md5 is all they need, so even with the SHA1-enabled payware version, it will still be a miracle if I can cover my domain fees!

Simple checksum (included, and also free) works with SHA1 as well as MD5, though on a one-shot basis. checksum "pro" (haha!) will be around £10.

I sometimes use paypal to honor good work from people, releasing their work for free.

You are, quite literally, one in a million! Feel free to browse around the corz.org/engine !

keep us informed about future updates - if you're interested in beta-testing for win2k, drop me a line.

The itstory (aka. "changes") above these comments, is dynamically included, and sometimes you can quite literally watch it grow, live (with a page refresh, anyway). If something happens, it'll be there.

I'll see if if I can find your email address in the list (I'm assuming you entered it at some point), because I'd like to know if everything's okay on Win2K. I today got confirmation that it's working swell on Vista, so 2K would be the Hat-Trick.

Thanks!

;o) Cor

seVen - 18.11.07 9:04 am

phil wrote:
I just came across another app that gets the job done:
www.slavasoft .com/fsum

Hey phil,

FSUM was one of the many hash checking utilities I've tried during my quest to find the perfect one. Although it's a very good one, it simply cannot handle the types of "jobs" I've been able to accomplish with checksum.

I've written advanced batch scripts for FSUM which have greatly enhanced its "out-of-the-box" capabilities but even then it doesn't handle certain situations as well as checksum does.

If you just need a program that will let you make a checksum file for certain files/folders, or a program that will let you verify a single checksum here and a single checksum there whenever you need to, then I agree with you, FSUM will get the job done. But if you need something more powerful, then you will love checksum.

And just when you think it can't get any better, it gets better! cor is always adding new features and making improvements in one way or another. checksum really is great software and I highly recommend it.

-seVen

cor - 18.11.07 1:58 pm

I agree with seVen!

And just when you thought it couldn't get any better.. Along comes spiffy HTML Logging!
Here's a sample of the output..

http://corz.org/windows/software/checksum/files/checksum-example-log-output.html

;o) Cor

phil - 05.12.07 11:13 am

When will checksum leave the beta-testing-phase ... I'm just curious to try it out myself and I want to make sure, that I really don't need to look any further for another checksum-utility.

cor - 06.12.07 3:31 am

The current version is bug-free, as far as most of my testers are concerned - but actually contains a couple of beauties. They only occur under unusual circumstances, but still, it will need a little more work yet before a general release.

I'm tied up for the next couple of weeks, so it's unlikely I'll be fixing them until after that, but if all goes to plan, the release version will hit this page at the start of the new year.

Something to look forward to, eh!

;o) Cor

ps. about the source (from earlier) I meant to mention, I am referring to the checksum program source; not the actual MD5/SHA1 routines in the hashing dll; the source for which you can easily check by following the credits in the dll's version information (via Explorer properties dialog).

Joe - 19.12.07 3:48 pm

Excuse me,

dp - 09.01.08 4:12 am

This would be an absolutely awesome program to integrate into a file level scan for a file copy/compare process. Parsing large (> a TB) volumes of millions of small files could largely benefit by a file system scan via hashing. It would allow the user to create a hash, copy all files to a destination as a backup, then the following day another run could be commenced copying the differential data to the destination, but the origin file system could be scanned via hash rather than a scan and compare operation. Sounds fast anyway.

db - 05.02.08 10:40 am

Any updates on a release date?

Bob - 12.02.08 3:51 am

If you have a feel for a release date, please let us know. Really interested in seeing checksum and simple checksum in operation.

dj - 13.02.08 10:26 am

thm - 18.02.08 10:09 pm

Cor,

Your beta history section lists version 0.9.19
on 4th Jan, but nothing past v0.9.18.1b seems
to be available...

-thm

cor - 26.02.08 9:17 am

In short, I'm just back from a rather long tech-break (though sadly not a holiday!) and checksum is definitely on the list of jobs for March.

I've decided to just release checksum for free (actually, "shirtware" - see recent blog for more details), and the next checksum job is to rip out the payware code and run some tests. There will be one more beta release (rc1) in a week or two (God-willing) for the beta testers (at least, those that mailed me along the lines of "hey! my beta ran out!"). If all the reports come back favourable; a proper release will follow soon after.

In the meantime, those who haven't read the itstory are urged to do so (starting at the bottom!); not just to appreciate the tremendous amount of hard work that's gone into checksum, but also to get a handle on its many features, some of which aren't documented elsewhere.

for now..

;o) Cor

S - 26.02.08 1:13 pm

I'm so sad. I spend all that time reading the page and getting excited about checksum...and it's in closed beta testing.

Boooo

cor - 26.02.08 7:07 pm

In the trade, we call this "building anticipation".

;o) Cor

vdzph - 27.03.08 5:29 am

Are you planning to add SFV support down the line? I know there are good current utilities for Windows but it'd be nice to get them all in one reliable package.

cor - 27.03.08 9:18 am

I haven't even considered SFV support; basically because it's fairly worthless. An "upgrade SFV checksums to MD5/SHA1" might be doable. Creating SFV, however, is not on the cards.

;o) Cor

noname - 30.03.08 5:30 am

ive been waiting for this since last year. any news on the release cor??? i think youve built up enough anticipation.

cor - 30.03.08 9:33 am

Hey, if you're that desperate, mail me, and I'll throw you in with the beta testers!

;o) Cor

galva12 - 30.03.08 1:01 pm

Hey, I have a question. I know that MD5 software can usually be used to check the contents of a burned data DVD against a MD5 file. But what I'm interested in is checking burned DVDs as a whole. Like in ImgBurn, when you go to verify a previously burned DVD against the original ISO file, and it shows you that the MD5 checksums of each of them match. I'm looking for a way to do the same thing, except using a MD5 instead of an ISO file for verification. Will your program work for that?

noname - 02.04.08 11:49 am

cor, i sent you an email from a gmail account. look out for it.

cor - 03.04.08 10:33 am

galva12, what you are trying to do sounds, to me, like a poor second-cousin to what checksum actually does. It also sounds like you are keeping the old ISO around, which would be a huge waste of space.

Doing things the checksum way gives you way more flexibility - you can check every file on the disk with a single checksum file, or one checksum for each file, with the checksums on the disk, or elsewhere, or both. If you need to know the status of a single file, or all files, you can do that.

I don't see any advantages to the ImgBurn method. In fact, I think an md5 which changes because dates and times of file access change, if a recipe for user confusion. No, checksum won't be going there!

Having said that, you could do what you want with checksum, by simply ripping an ISO of the disk at any time, and comparing it to the original iso md5.

Thanks noname, I'm still catching some up after my birthday celebrations, but I did get it your mail. Expect a reply soon.

;o) Cor

defier (previously known as noname) - 03.04.08 1:05 pm

I didnt know you had your birthday recently cor. happy belated birthday! i hope you got heaps of presents. i look forward to getting your reply.

galva12 - 04.04.08 4:30 am

Hey cor, thanks for replying. I don't think I explained what I'm trying to do properly though. As you said, keeping the ISO files around would be a massive waste of space, which is why I'd rather verify my burns after the fact using premade MD5 files.

I'm dealing with images that don't contain just easily-accessible data files though; they're in some kind of convoluted format that makes it impossible to scan them file-by-file; they aren't listed in Windows explorer. I need a checksum of the DVD image as a whole.

In ImgBurn, when you verify a DVD it's shown that the checksum of the original ISO file is identical to that of the burned DVD. I'm just looking for a way to cut the ISO out of it, and use a premade checksum of the ISO instead. It's no task to get the ISO's checksum, but I haven't yet found any method to get the checksum of an entire DVD, as an image and not file-by-file. I wonder how ImgBurn does it?

cor - 04.04.08 5:01 am

It simply reads the disc into an ISO image. You can do this with most burning tools; Nero, MagicISO, etc. Once you have your image, you can checksum it, and compare it with the original ISO md5.

ImgBurn probably just hashes-as-it-reads, which is kinda slick, as you don't have to dump the ISO file anywhere, missing out the middle step.

;o) Cor

ps. cheers defier!

notnymous - 18.04.08 1:45 am

I'll be emailing you in a few minutes. I have tried all of the software listed at these two sites

http://en.wikipedia.org/wiki/Comparison_of_file_verification_software
http://koolmonkey.bravehost.com/sfv-md5.html

and even the ones that cost money are not very good (I can't afford them anyway). I am religious about the security of my data, and I the only good piece of software I've been able to find is ViceVersa (http://www.tgrmn.com/index.htm), which does automatic backups as soon as you edit a file, and then it does a CRC32 check to make sure the backup is good. The advantage ViceVersa has over a RAID 1 mirroring setup is that ViceVersa also keeps old copies in an archive. I can't tell you how many times I've spent two days editing a file, and then realized that the version I had 3 days (or months) ago was much better, and I was glad that VV kept the old copies for me. It's not CVS versioning or revision control, but it's good enough for just me on my machine, while I work on something that may have come from a revision control system (RCS) like Subversion or SourceSafe.

Anyway, I've got backup reasonably solved with ViceVersa. Now I need Checksum for general purpose use, like the times when I need to make a manual backup copy. Gimme? Beta? Please? Desperate!

cor - 18.04.08 2:03 am

I got that, ta.

I feel the same way about my data; more and more people do. My approach was to bug the developer of my favourite text editor to add comprehensive backup facilities, and now I have a folder with every single version of every single thing I've worked on, timestamped in neat directory-named folders. Pretty cool, though sometimes it does get HUGE, and needs to be archived. Suits me fine. Btw, surely you mean RAID5.

As to the checksum applications, yup, they're all crap! Well, okay, one of them is actually slightly faster than checksum (that's the only good thing about it!), and a couple of them have kinda cool (though pointless) GUI, but apart from that.. pfff. That's why we're here!

I just put out rc1 to the beta testers on Wednesday. Early feedback..

I love it, love it, and love it... Bravo!

..and as I work on rc2, I'm looking to widen the net some; let a few more folk try it. There will be no more free licenses, but as I'm putting it out as Shirtware, I guess that's less of an incentive, anyway.

Look forward to some juicy download details in your inbox in the next few minutes. All feedback welcome.

;o) Cor

notnymous - 18.04.08 2:35 am

I like raid 1, since it's not about write speed for me, just cheap redundancy with only 1 extra disk. My text editor does backup too, but I just let viceversa handle it, since it'll back it up as soon as I change something.

cor - 18.04.08 2:48 am

Yup, that's what Editplus does. Every single change creates a new backup. If you enable it, that is.

Ahh right.. RAID1. For some reason I get RAID0 and RAID1 mixed up. I don't use either, is probably why.

;o) Cor

seVen - 19.04.08 11:00 pm

What's up cor!

Glad to see checksum is close to being released to the public! To tell you the truth, it's so good that it makes me feel guilty that I (as a beta tester) get to use it daily while the rest of the world has to deal with the pains of using inferior hash-checking software.

Don't worry guys, hopefully you will all have it soon. Only then will you truly understand

cor - 20.04.08 7:44 am

Yes, we're making the world a better place for our children, and our children's children! Hopefully we can handle the pain of guilt for a wee while longer, yet!

Hey! I did add another batch of testers to the latest release (rc2), yesterday. Anyone who has mailed over the last few months about testing checksum should definitely check whatever address they used - there could be juicy download details waiting for you right now!

I'm thinking I might go semi-public with rc3. I've been messing around with my mailer this week, getting it ship-shape to handle the thousands of folk who have signed up for "corz odd mailing" (a list I've not used yet) with a view to letting them have a crack at checksum before a full release. But it's slow going, and I keep finding reasons to do something else instead. I might just install PHPList and be done with it!

Anyways, in ever increasing circles, it's coming folks, and real soon.

;o) Cor

strat - 27.04.08 1:31 pm

The only checksum utility I could find on the net.
Thanks a lot

notnymous - 29.04.08 5:10 pm

I just read through the changelog. It looks like checksum is getting a lot of work done on it to polish it up for a release. Thank you very much for all the work you've done.

cor - 02.05.08 9:50 am

Yes! And so far only a single bug report for rc3 (which is already fixed).

So it's looking like Real Soon Now!

;o) Cor

Para Noid - 08.05.08 7:51 am

This is just what I've been looking for! I can finally replace the non-recursive QuickSFV A pity it's not done yet. I'll watch this page closely for the release.

As for speed I really can't see how you can improve much. On PCs today you're usually limited by disk I/O rather than processing power. Not that less cpu usage isn't welcome

Can you compare two directories with this tools without generating md5 files everywhere? E.g. to verify that a file copy has been done without errors.

Any thoughts on including par2 support or some other repair capable algorithm in the future?

Enough nagging
Thanks for using your spare time to make this. If it works as well as you say I'll recommend it to everyone I know, and I'll definatly donate some money.

cor - 08.05.08 10:15 am

Para Noid, thank you! Yes! I've been working on it whenever possible, check out the itstory for details - the last thing I wanted before calling it 1.0, and letting it out, was a "unified hash extension", as I like to call it. I'd already done the tricky bits, teaching checksum how to interrogate files line-by-line, and not give a damn about the file extension. Who knows what hashes might be in future files, and one more file extension is quite enough!

I got that done a couple of nights ago, and the unified .hash extension is with us now; checksum phase two, complete. Pretty new icons and a funky PAD file followed suit.

As for speed, yes, I had a similar conversation with a beta-tester, and it's totally true; utilizing 100% cpu for a file hash is, for now, a pipe-dream, and file system I/O is always the deciding factor. Having said that, it's nice to get a file into ram and just go Woosh! See that's possible. It is rather fast, and the the aforementioned conversation is definitely at back of the most recent batch of speed improvements - I had to get it into the top-three! And as storage devices get faster, so will checksum!

Ideally, I get T-Shirt Three-of-Three ready, and then do one grueling night of checksum promotion, dropping blogs, signing up with download sites, dropping a link right here being the one I look forward to most. This page needs some completion! Especially since the beautiful search engines of the world are already sending people.

But Three-of-Three is "The Amazing Metaphysical Traveling Map", and for years it has caused me no end of grief, refusing to settle itself into one simple design. I literally have hundreds of sketches, the concept being more important, of course, but design is important, too, as any user, even potential user of checksum appreciates. I'll get there, but if I don't nail it within a week; that and an even smarter way to "upgrade" multiple hash files to the new unified hashing scheme, then it's getting released anyway.

A week, tops.

Can you compare two directories with this tools without generating md5 files everywhere? E.g. to verify that a file copy has been done without errors.

Well, they wouldn't go everywhere! Just inside the directories in question. I know what you mean, though. No. checksum makes real hash files*. However, it will happily work with hidden checksum files, creating or verifying them, so you don't have to see them if you don't want to**. Having said all that, hash files a) are rather reassuring, sitting there, and b) have a really cute new icon, took me ages!

It also seems wrong, somehow, to not keep the hash data. We used CPU cycles to create something, a state of things, captured. Why not keep that data? I like to think that we'll all get used to living with hashes. They are so small and beautiful, and perfect! "Perfect until your data isn't!". Keep 'em! I say!

Any thoughts on including par2 support or some other repair capable algorithm in the future?

All I know of Par is that you make tiny wee extra files that somehow can be used to re-create missing parts of very large files, usually Rars. It seems to defy the laws of physics, even though I'm reliably informed that it's all true. Which is to say; No, I haven't considered it. I'm not at that stage with PAR, yet, and even if I was, I'm not sure it's something checksum should be doing, anyway. Of course, I'll happily accept enlightenment on this topic!

Keep 'em coming!

;o) Cor

ps. I had to dash out in the middle of that post, sorry about that!

references:
* I have considered giving checksum the capability to do a spot-check file compare for when two files are dropped onto it. I haven't implemented this, nor considered, until now, having this capability extend to entire folders.

For quick file-compare tasks, I more usually use simple checksum, checksum's wee brother. And the more I think about it, the more I think that if I added these capabilities anywhere, it would more likely be to simple checksum.

** I used to always keep hidden files visible in my desktops, but more and more these days, I like to keep hidden things hidden - I did a macro to hotkey between the two states, when required.

JkR - 19.05.08 6:59 am

I totally agree with your blurb. Making MD5s was always a pain! I Have been checking this page regularly for a couple of weeks since I first found it. It's great to see checksum released at last! AWESOME! It's exactly what I've been looking for!

Thank YOU!

JkR

p.s. It was a bit weird my md5 files becoming hash files but I totally get where you are coming from with that and I hope it catches on. Good luck!

seVen - 19.05.08 8:10 am

Looks like JkR is another happy camper

I agree, it's awesome to see checksum finally out in the open. I bet cor is PROUD right now.

As a beta tester, I've been lucky enough to have checksum by my side for quite some time now. And over time, I sometimes forget about all the trouble I used to go through just to verify a couple of folders or recursively create hashes. checksum is just so simple, and well, it just "makes sense".

Why did it take so long for something like this to be created? That's something I'll always wonder. It's like all those other developers of hashing software just didn't care... I'm glad one of them did.

cor - 19.05.08 11:25 pm

Thanks guys!

I actually started on a new feature minutes after I uploaded rc4; a request; WAV file alerts. Tonight, I also made a wee change to the installer's setup.ini (removed Explorer context menu "dividers"), and built an rc5. It's up now, in the same download place.

Keep the feedback coming, here and in my inbox, it's all good, even the bad! - though don't be insulting, cuz I'm a right c*nt when I'm annoyed!

It's about ready to be labeled v1.0, and promoted left, right and centre, I think; which will probably be at the weekend, when I'll have more time to trawl the popular download sites*.

Feel free to tell anyone and everyone about checksum, even torrent it at your favourite tracker, whatever; it's good, so let's get it out there!

for now..

;o) Cor

references:
By the way, did you know that if you are a developer, you can buy "Editor's Pick" slots! I got the offer in my mail the other day (I'd deleted my HUGE Thunderbird training.dat - a good move - and hadn't informed it that <insert download site> was just spam). That blew me away - I'm so naive! - I'd always assumed that the editor had actually picked something, you know, because it was good. Och well, they can stuff it!

notnymous - 20.05.08 3:16 am

cor - 20.05.08 3:25 am

If you use a regular web browser, and don't try anything funky, there's absolutely no reason your download would fail. And if it does, email me, and I'll gladly send you a copy by hand.

How's that for service!

And by the way, the popular download sites will most likely just post a link back to here. Why wait? It's already here!

;o) Cor

notnymous - 20.05.08 6:23 am

when you going to make a tshirt with your emoticon logo thingy?:

;o) Cor

June - 21.05.08 4:36 am

Great work. Thanks.

cor - 22.05.08 12:47 am

notnymous said..

when you going to make a tshirt with your emoticon logo thingy?:

;o) Cor

It has crossed my mind, but my self-indulgence-o-meter is already in the red, so I'll probably at least wait until I get the first three designs ready. Also, it encourages "fans", and that was one of the reasons I got out of the music industry when I did!

I guess digital fans is okay; buying shirts, as opposed to ripping them off your back! It's a cool smiley, but, would YOU buy such a shirt?

;o) Cor

ps. if I could find a manufacturer that could reproduce my site gradient on a T-Shirt; yes, I'd go for it, even just for myself.

meHomey - 23.05.08 2:47 am

I've been using a command line MD5 utility that does only files. But if a folder matches the filespec it attempts to access it and fails and quits. Inane behavior.

cor - 24.05.08 1:41 am

Oh, I've seen a lot crazier behaviour than that in hashing utilities! But let's forget about those, and look to the future: checksum.

;o) Cor

Mr. Snout - 26.05.08 2:43 pm

Thanks a lot for writing this! I'd been using a command line md5 tool and was looking forward to point-and-click ease.

I deal with big (1GB - 13GB) video files that are typically moved around or backed up individually, so I always use the "individual checksums" option. I would like this to be the default. Unfortunately every time I right click on a directory and choose "Create checksums" I get one checksum file in the dir. The only way to get the "individual checksums" is to do the shift-key thing every single time, which gets old. Is there any way to have the "individual checksums" choice stick?

Also: Is there any way to be have an audio alert only when there is an error? The pc speaker beep quickly becomes very irritating.

Thanks ...

cor - 26.05.08 4:12 pm

Hey, Mr. Snout, no problem!

checksum's operation is completely controlled by switches which makes it extremely flexible, so although there's no actual preference for "always create individual checksums" (I hadn't considered someone might want this set permanently, though I'll be sure to add this for a future release - cheers!), it's easy enough to achieve right now, simple add the i switch to your explorer context menu commands.

There are at least two ways to achieve this; probably the quickest is to add the i switch to the directory and/or drive commands in the registry..

HKEY_CLASSES_ROOT\Directory\shell\01.checksum
HKEY_CLASSES_ROOT\Drive\shell\01.checksum

Currently the switches in the command will be cr, so make them cri, and from then on, folder checksum commands will always create individual checksum files. Of course, if you occasionally want the usual per-folder checksums, you can do the SHIFT thing.

You could also create additional commands specifically for creating individual checksum files directly from the explorer menu in much the same way as the custom music file commands I outline in the tricks & tips page, here. You could even make the context menu entry specific to movie files, using crim(movies).

If you don't want to play with the registry, simply edit the installer's setup.ini file, adding the switches in there, instead..

HKCR\Directory\shell\01.|name|\command="|InstalledApp|" cri "%1"
HKCR\Drive\shell\01.|name|\command="|InstalledApp|" cri "%1"

and then reinstall checksum to get your updated Explorer context menu items. Actually, that's probably even quicker than editing the registry!

As for the audio alerts; if you want checksum to not beep on successful completion, yet still beep on any failures, simply set beep_success to a blank WAV file.

checksum will still alert you of failures with either a WAV or beep, depending on your preferences, but all success notifications will be completely silent. I've uploaded a small, blank WAV file for the purpose, here.

Of course, audio alerts can also be disabled completely in checksum.ini, if you wish.

Have fun!

;o) Cor

cor - 28.05.08 10:24 am

To those who have read the page, and are now just following the comments..

There is a new section!
Check this out!

;o) Cor

Laz3r - 02.06.08 10:10 pm

Very good. I also was thinking hashes should be done with point and click.
Thanks!

chris - 06.06.08 2:26 pm

Hey cor. That's a nice tool - unfortunatelly it isn't what I'm searching for. Though it might be possible to make it such easily.

I'm actually looking for a tool with which I can easily check a file against a hash published on a web site. You too publish the hashes for your file here but to check the downloaded zip against it, I'd have to generate a hash file, open it, compare it against the one on the website, close the file and delete it.

So any way to generate and just display a hash to compare it visually? Or even better compare it automatically if a hash is found in the clipboard.

Thanks, chris

cor - 06.06.08 2:53 pm

Hey Chris. I anticipated this need, and created "simple checksum", checksum's wee brother, which does exactly what you want. It's also very slim, and designed to sit out of the way somewhere, so you can do visual comparisons easily with your browser open - you can even make simple checksum semi-transparent, and leave it there.

As a bonus, you can also switch easily between MD5 and SHA1 (there's an application menu item and HotKeys for both) and simple checksum will recalculate the other algorithm for you, without the need for a second drag-and-drop. It comes free with checksum, just start it up!

Cheers, Laz3r. In fact, you pre-empted my new checksum slogan, there! Once the new beta goes up, I'll upload all the new pages, and you'll see what I mean.

;o) Cor

chris - 06.06.08 10:25 pm

Well cor, that surely works. But where to put that app to be invisible when not used but at hand when needed? Holding Ctrl while starting the app from context menu does something else than without but I'm not that sure what it is for. I still think it would be a nice behaviour to tell checksum to only display the result when a modifier key is pressed.

BTW, when a hash files content is verified, checksum tries to start cmd.exe. If I prevent that, everything still works. What ist the aim of this?

cor - 07.06.08 1:31 am

Nonono chris, simple checksum is a totally different application!  If you ran the checksum installer, it should have been placed beside checksum.exe, in the program folder; it's the one with the green icon. Click this link; it's a page all about simple checksum.

There are no modifier keys for simple checksum. You just run it, and it stays open, displaying hashes for whatever you type into it, or drop onto it. You can toggle it (show/hide) by simply clicking its tray icon.

checksum doesn't display hashes, ever. checksum's job is to create and verify hash files.

But neither checksum or simple checksum attempt to start cmd.exe, at any time, for any reason; I suspect something else is happening on your system. Feel free to mail me more details about this if you like.

However, checksum will attempt to run compact.exe after creating logs, to compress them (more details in the itstory), and though compact.exe is a console application (it's built-in to windows) it should all happen in the background, and shouldn't be seen. If it's not happening in the background on your system, then I definitely want to know more about it; OS details, etc, in my inbox, or here, cheers!

;o) Cor

Para Noid - 09.06.08 9:12 pm

Hi again!

I've been testing checksum on about 1 TB worth of files and it looks good so far. Easy to use and has several features. There are however a few features I miss which you can consider or just file under /dev/null

- Delete missing files from hash files
I have replaced several files with newer versions but the old files are still listed in the hash files which lists them as missing every time I do a verify. I can delete them manually from the hash files of course but where's the fun in that? Should not be a default option of course.

- Rename files to match filename in hash file or vice versa
Let's say a file has been renamed for some reason. Could be an irc server replacing spaces with underscores for instance. Or someone has renamed a file to match their own personal format.
The idea is to calculate the checksums for all files in a dir that isn't listed in the hash file(s) and see if it matches the checksum of any hash entries that are missing it's file and rename it accordingly.
Some considerations: Empty files should be ignored (and very small ones?). Multiple hash files can point to files in the same dir so it's probably a good idea to try to merge as many as possible to find the files that doesn't have a hash.
Another option that's much simpler to implement is to set it to only run on single hash files. It could then look for missing files in that hash file regardless if they're listed anywhere else.

I'm sure I can give you more suggestions if you're interested. :-)

Keep up the good work :-)

Randy - 10.06.08 9:49 am

Yes, good work! I've just been testing checksum out on my archive, very impressed. It does lots of things I've wanted to do but couldn't until now. Now I just have to acquire a "decent text editor" (as you say!) so I can have a proper fiddle with all the preferences.

No one has mentioned simple checksum I see, it's very handy too. They make a good pair.

Slimbo - 11.06.08 7:53 pm

Excellent! Thank you.

notnymous - 11.06.08 10:01 pm

I don't see where version 1.1b can be downloaded. Has it been released yet?

cor - 12.06.08 1:00 am

Thanks guys!

Cheers for the suggestions, Para Noid (and the other thing!). "Delete missing files from hash files" sounds useful, but highly risky; like you say, it wouldn't be the default! I'll definitely consider a special switch for this, though.

"Rename files to match filename in hash file or vice versa" I'll have to think about. If I did something like this, it would almost certainly work on a line-by-line basis, so the location of changed file names would be whatever scheme the original name was, regardless of relative or absolute paths. You can mix them all up real good in the latest version.

Setting this for only "single hash files" is is doable, so long as we remember, the idea of a single hash file is purely a virtual one, at least in verification (there is no "i" switch for verification, for this reason). A hash file is viewed simply as a container for hashes. Where each individual hash points, is determined on a line-by-line basis. I'll definitely consider all this, though.

notnymous, it's mostly done. Unfortunately, I've been away a lot this last week, and that will be true for a few days, yet, so the list is slow-going. I'm hoping to have 1.1b up this weekend, but that's not a promise!

Meantime, you could play with Batch Runner, a small but useful wee app I put up tonight; something I've been trying to make time for all week. I built it to run batches of tests on checksum before releases, but it's already proving handy for other jobs.

;o) Cor

ps. Randy, also, their icon colour schemes compliment each other beautifully!

RugReaver - 19.06.08 12:31 pm

Nice. Thanks.

muza - 03.07.08 6:34 pm

awesome!!

Bobz - 18.07.08 8:03 am

I got an error installing on Vista (SP1) about the zip.dll not getting registered. I got the folder out of the zip, and ran it again and it worked, but I thought you should know.

Great app, it was worth it!

Allthe best.

Bobz

cor - 20.07.08 10:39 pm

Sorry about that, Bobz. It's actually sorta fixed, but y'all have to wait. For others who experience this, simply unzip the files.zip inside the "files" folder (yup, that's right, it will be /files/files/) and edit the setup.ini to read "files" instead of "files.zip". Continue as normal.

That x-zip plugin has been more trouble than its worth, and while working on corzipper (to come) I decided to bin it. I've now built a whole new zip plugin especially for my own stuff, which will be used for the installer, as well as some of my other apps (corzipper/backup/and more). As well as great performance, it boasts password-protected zip and unzip, which I utilize elsewhere.

x-zip will still be supported (my apps will look for my own zipper first, and fall-back to x-zip if it's not available) but I'll be phasing it out ASAP. As well as occasionally not registering itself, it uses available memory for all its operations, so while it's good for small things, installers and such, it starts to wobble as you increase the size of the archive. The new zipper plays nice with your RAM, and never use more than around 8MB to zip or unzip an archive of *any* size.

The new zip plugin is just one of a whole host of new stuff coming to the corz.org windows software area, soon. I also plan to install Vista myself this week - I hear SP1 makes Vista "not-crap", so here goes!

Probably all my stuff is full of Vista-related bugs, so if all goes to plan, I'll start squashing them in a few days.

l*rz..

;o) Cor

Jeff - 13.08.08 8:00 am

Just wanted to add my support for Para Noids suggestion for dealing with renamed files. Would definitely save time as opposed to renaming them in the hash file since a lot of the time I will hash files as soon as possible when i get them and only worry about renaming them later.

Totally awesome program though! Was exactly what I was looking for. Its amazing how far behind most of the other programs out there are.

Thanks Cor
PS: noticed you are hashing "Van Diemans Land" in the other screenshot. I live in what used to called Van Diemans Land!!!

Vorlon - 13.08.08 5:38 pm

Hi Cor,

Your software looks like what i've been looking for, although I'd like to confirm a few things.

I've used a few crc/md5/sha file checkers that will do just that, ie compare a single file to a published MD5 value et.
However, I'm after a program where I can say create an MD5 of the sum total of folders with hundreds of files (or even a volume with hundreds of folders and thousands of files etc.

After there being some problems in the past with external hard drive (usb) chipsets vs file sizes etc. Plus where any data is being moved say from your PC to Flash Memory, DVD media or an external hard drive, I would find it useful to check if the files are an exact copy. I don't need to have an MD5 created for each file, but simply if I copy and paste a whole Volume (bar hidden system files etc) can i use your program to confirm if the 100Gbytes of data was copied to it's destination successfully?

Thanks.

cor - 13.08.08 8:07 pm

Fated to use checksum! That's just what I happened to be listening to when I did this page. In truth, I don't even know where Van Diemans Land is! Ireland? *ahem* anyways..

Thanks Jeff; I'll definitely be looking into the renamed files thing during my next code block; though it will most likely be a special function, quite removed from the regular create and verify processes. Reason being, during verification, checksum doesn't care what files are in the folder, doesn't even look; its only concern is files listed in the hash file, so checking for renamed files could potentially introduce some overhead which I wouldn't want affecting regular (super-fast) usage. Perhaps a "refresh hash file" function. Hmmm.

The way I usually do it, currently, is to verify the hashes, then make changes, renaming, ID3 tags, etc, then write a completely fresh hash. It only takes moments with checksum. Still, a refresh function would be handy.

Vorlon checksum has no problem handling whole volumes with hundreds of Gigabytes, even Terrabytes of data (I recently received a gushing thank-you mail about checksum's brisk work on a 5TB archive, so I can say that with certainty!), and if you wish, you can put all the hashes into one single "root" hash file (again, checksum can handle massive root hash files). Though initially dubious of the usefulness of root hash files, I do find myself using them more and more myself these days, particularly in cross-platform work.

Also, checksum will happily hash hidden files, system files, even locked and in-use files, so you can be 100% certain that the volume was copied exactly. Or not, as the case may be!

Give it a whirl!

;o) Cor

ps. here's a tip.. I note that someone mentioned (either here, earlier, or in a mail) that they found reading two hashes (to compare them) a choreful process; here's how I do it.. Paste hash one into an editor, then select all and paste hash two over the top of it. If you then Undo and Redo you can see any variations at-a-glance. I think most people just read the first and last few characters, anyway!

In the future, simple checksum will do this automatically, but that's for in the meantime!

Vorlon - 18.08.08 12:13 am

Hi Cor,

Is it possible to do retrospective checking on read only memory storage ie previously burnt cdr/dvdr media with checksum?

Scenario:
Say you have already burnt an archive DVD-R of your drivers and apps etc prior to having installed or even known about checksum, but the directory/file structure still remains exactly as it was on your hard drive volume when you did the copy.
Could you then install checksum to your system and then hash that original source volume/drive/folder/file structure etc, then afterwards use checksum to verify the DVD-R but use the *.hash files of original source (on the Hard drive) as the MD5 reference of the files on the DVD-R?

Basically does checksum need a *.hash file/s on the media it's checking in all cases or can it do it "remotely" (so to speak)?

Best regards,
Steve

cor - 18.08.08 1:46 am

Yes Steve, checksum's operation on read-only volumes has received quite a bit of attention, internally, and there are a number of ways to achieve what you want.

Probably the easiest method in your situation, is to work in reverse, that is; create a "root" checksum of the read-only volume, and then simply copy that to the original location on your hard drive, and click it. You're done.

Note, checksum won't create a root hash file by default; you can either use the one-shot options to set that, add the "1" switch manually (if working from the command-line), or if you do this sort of thing a lot, you might want to set checksum's read-only "fallback_level" to 1, in checksum.ini.

I should add, you can also create and verify hashes containing absolute paths, for truly "remote" hashing, as you put it. This can be highly useful, but could be limiting if some fixed volume got a letter change in the future, or was moved to a different machine where its original drive letter was not available.

However, in a future version, I plan to add path "mappings" where absolute hash files can later be transparently remapped to new locations. It's one of those features that would probably be rarely used, but occasionally extremely handy; at least, it would be useful to those not familiar with regex search and replace in their text editors!

Anyway, that's for the future; what you want is doable right now, with a simple root hash.

;o) Cor

Jeff - 21.08.08 7:04 am

Hey cor,

Tasmania, Australia was first originally named Van Diemens Land.

Hashing is a great way to track file changes but is there any way to safegaurd against the hash files getting corrupted?

cheers

Jeff

cor - 21.08.08 11:21 am

Tasmania! What a beautiful word that is.

Guard against corrupt hash files? There are a few ways. You could start by making a backup of the hash files. It's fairly easy to create an archive of only the hash files, even from a volume of many individual hash files. When decompressed in-situ, all the hash files would drop back into the correct locations. Also, hash the archive!

Then there's absolute (aka 'remote') hashing, which I discussed in my previous post. You could keep the hash files somewhere else, and still hash the original files as if they were right next to the hash files. The hash file itself could live on some solid-state, read-only volume.

For the extremely cautious, after hashing the volume as normal, you could temporarily remove .hash (or .md5/.sha1 if you use those extensions) from checksum's ignore list, and do a root hash of *only* the hash files, using absolute paths, and store that hash file somewhere safe. Before checking the file hashes, you would check the hash hashes!

And don't forget double-hashing! You can have a sha1 AND md5 hash for each file, inside the same hash file, if required. It would be extremely unlikely, if corruption is the potential issue, for both hashes to become corrupted.

Finally, if intentional tampering is a possible issue, storing absolute hashes elsewhere is probably the best method. And don't forget, checksum will happily make invisible hashes, always handy.

for now..

;o) Cor

vikram - 01.09.08 1:42 pm

gud utility

Byron - 30.09.08 8:41 pm

Absolutely Superb!!!

Thank you.

Vorlon - 06.10.08 12:37 am

Hi Cor,

I've finally got around to using Checksum proper and started moving some of my old data from an old PC to my new build. Checksum is fantastic in it's "intelligence", ie knowing that you are using Read Only media when making a root hash and storing safely on your hard drive for later reference. At first I was looking for where to enter a path for the hash to be stored as the media being checked was read only. But guessing you had catered for that I just ran the program to see what would happen - brilliant!

Another great thing with the root hash is folders on your PC like say the Steam Folder which might contain GB's of data, can be copied from say your old PC to your new PC and then checked without worrying that Valve's VAC system might see innocent hash files in some of the directory structure as modifications. Of course you could remove the individual hash files after moving the data, but that would take time.

I just realised that I made a mistake adding the k switch along with the 1 switch especially when comparing Removable media with a different drive letter - doh! (and you had pointed that out - above). Well it was late and I was trying to be thorough, although I did realise that the k switch gives absolute path (ie including drive letter), I hadn't realised there was still a wealth of information given in the log file by default, ie subdirectory path. I had thought the use of the k switch implied all or nothing, ie full path or just the file name.

Checksum has got to be the best utility I have found and used in recent years.

Steve

cor - 06.10.08 11:51 am

Thanks for your comments, Steve - I always get a kick, hearing other folk appreciate checksum's "intelligence", as you call it. A lot of thought goes into it.1

The main design goal, with checksum, was to create a hashing utility that would "JUST DO IT!", skipping as many pointless steps as possible, and as far as possible, getting on what the user wants done, immediately, and without prompting. I'd already wasted a significant portion of my life instructing daft hashing utilities to do the same thing over and over. As Kosh said, It was necessary!

But, as you have discovered, checksum is also able to handle those "unusual" jobs, and absolute, root hashing is but one of its many tricks. If you find yourself doing this sort of thing a lot, I definitely recommend you check out the 1.1 beta, which hasn't prompted a single bug report (it will become the release version soon enough). Being able to see (and edit) the switches inside the one-shot GUI can be extremely useful.

By the way, if you inadvertently add a "k" switch; being plain text, it's a fairly trivial operation to run a search & replace on the .hash file, in your preferred text editor; switching the drive letter to another, or even removing it altogether; making the hashes "relative". I've done it more than once, myself.

;o) Cor

references:
1. I'm currently "thinking" about how checksum might elegantly update renamed files.

Vorlon - 06.10.08 3:41 pm

Quite right about the "Kosh" comment Cor :-)

I had forgotten to add to my above post that I an using the Version 1.1beta, which works fine.

Checksum has already brought something minor to my attention, through the use of burning a DVD with the Full Nero 7. Occasionally I save technical webpages especially along with some utilities, so i don't have loads of printed paper etc. However and I have noted this before, Nero (as with other burning utilities) truncates long file names, which are used in abundance these days on webpages.

So after checking my DVDr media, Checksum alerted me to X amount of files were missing. Of course Nero had effectively renamed the files and directories of the saved webpages by truncating them. I believe the basic Joliet system allows upto 64 characters, but I have found some info on the Net (not from the nero site unfortunately) that they relaxed this limit on Nero 7.

Anyway, something I hadn't even checked or considered (although I had seen it before) was picked up by Checksum.
The beauty with Checksum in this scenario, is that it's not limited to just reporting a different ie non matching checksum, but alerting you too, to missing files....

Also I like the html format report summary....

Steve

Vorlon - 06.10.08 6:56 pm

Hi Cor,

Would it be possible when you Verify with Checksum and check the "Log Everything" Box (and add your own LOG path if neccessary, that the resultant HTML Report File Groups "Passed", "Missing" and (I assume as I haven't seen it)"Fail" together?

No doubt most people would just use the default of logging a problem, but then I would assume "Fail" & "Missing" wouldn't be grouped either?

Although the html report is very clear, you still have to scroll through it to make sure you haven't missed a specific error amongst a plethora of "Passed" or "Missing" etc...

Thanks,
Steve

cor - 07.10.08 7:37 am

checksum has brought a few things to my attention, too; things I would have otherwise missed. Interesting about the Joliet truncation; I'll see if I can get checksum to look for those shortened DOS file names during verification. I haven't encountered this myself - when I burn disks, I generally relax everything; it's not like computers are going backwards!

To avoid long file names in saved pages in the first place; investigate MAF. I use this almost exclusively for saving web pages. Essentially, it's a zip file, with all the resources safely tucked inside; very handy (so long as you do NOT use the "MAF Zip Archive" format - regular MAFs are zips already - strange but true).

One highly cute thing about .maff archives is, if you have multiple pages in a series, you can save over the old .maff file, and rather than overwrite it, Firefox adds the new pages to the old .maff. Another interesting undocumented feature I discovered about MAFs, is that if you save your pages in reverse order, when you click on the .maff file, the whole lot loads back into your browser, in the correct order. Nifty.

About the logging; true, most people log only errors, but even if you log everything, it's easy enough to locate a fail using type-to-find. I see you use Firefox, and I'm assuming it still has this capability (all browsers will have this, eventually, surely!). I use it hundreds of times a day.

One caveat; if I recall correctly; by default, this functionality doesn't auto-start, or only works on URLs or somesuch. At any rate, the following in Firefox's user.js, gets it working beautifully..

// "Find As You Type" settings..

// main on/off switch

// set to true Find As You Type
// if set to false (the default), you must hit / (find text) or ' (find links) first

// set this to true to only search for links. how crazy is that?

// only applies to above, with this true, you have to type the *first* characters of the link

// how many miliseconds before Find As You Type stops watching your keystrokes..

Grouping the failed and missing files in the log would be problematic to code - checksum basically logging-as-it-goes, but I'll certainly look into it for a possible future option.

Thanks for the feedback.

;o) Cor

Vorlon - 07.10.08 5:13 pm

Thanks Cor,

I will check MAF properly and see if it would preferable for me to use it, which it looks like it might be :-)

Talking about "Nifty" ideas, I keep noticing refinements in Checksum, that if it were another utility, probably wouldn't be added to version 6,7,8,9 etc.....
The more I use it, the more I can see that so much is already catered for.

Hopefully it'll get a lot more exposure, because imo, its one of those "Must Have" utilities.

Steve

cor - 10.10.08 9:38 am

Agreed. Agreed. And Agreed!

I love it when folk notice how special checksum is! I guess I would say that; at least here I would; when it comes to more exposure "out there", I leave that to you guys, having a strict no-self-promotion policy!

In other words people, feel free to drop a link to this page anywhere you like! I see you already did, Vorlon. Much appreciated, ta!

A little while back, someone made a post about a Windows accessory of mine1 (KDE-Sizer) on lifehacker, and as well as sending downloads through the roof; got its page posted and linked-to in all sorts of places over the globe. If something similar were to happen to checksum, I'd definitely approve!

About the MAF archives, Steve, there's one drawback - the contents don't show up in a search-in-files2, being inside a zip archive. Because of this, I tend to give my MAFs long, descriptive titles - I'll definitely need to relax everything when burning those to disk!

Keep on Hashing!

l*rz..

;o) Cor

references:
1. In fact, it's only partly mine, but I think I added the best bit!
2. Google Desktop can search inside them; check out the the IFilterShop Google Desktop Search plugin.

Matt - 25.10.08 2:03 am

Sterling work.

BlackholeForever - 07.11.08 8:50 pm

Cor,

I just checked out your utility in addition to a few others today. The synchronize function could be a little more robust.

Google a utility called SmartMD5. The author has not updated it in a while, but take it for a spin and then examine his hash file. It's not completely standard, but the additional metadata does facilitate fast, intelligent hash updates.

I like that you provide command-line functionality.

cor - 13.11.08 8:40 am

BlackholeForever, if you have any specific issues with the sync, I'd very much like to know the details.

As for SmartMD5, I remember testing it a couple of years back (I grabbed it again just now to check - yup). Aside from the infuriating gui and usual bag of assorted time-wasting foibles that checksum was specifically designed to avoid (that's as far as I got with it, last time around), it uses a completely non-standard hashing format. That's not really a lot of use these days. checksum can work with any standard md5/sha1 hash format from any platform, but I do not plan to even consider adding support for that!

As for "metadata", that would easy enough to add, and without messing up the hash format itself, either. The trouble is, I can't see any reason to. I'm always open to good suggestions, though.

I'm glad you appreciate the command-line functionality. Every program has a command-line, so it makes sense to make the most of it!

And really, about the sync; if you have any issues with it, anything at all, I want to know. If you have a lot of details/data, mail me. Ta.

;o) Cor

Carsten - 30.11.08 12:56 am

I'm a bit late to the party, but, in response to Cor's tip of pasting two sums on top of each other into an editor to compare them:

You can paste just one of the sums into the editor and search for the other sum. If a match is found, both sums are the same, obviously. And you don't even have to read a single number...

But yeah, I mostly just scan the numbers to see if they're similar.

LiLo - 05.12.08 5:19 pm

I use simple checksum to compare files, drag one in, see its hash, then drag the other, and it's easy to see any changes.

Great app! (both of them!)
LiLo

LowTek - 14.12.08 8:02 am

Cool app. Glad to see more work being done in the checksum space. I tried checksum' and when it encounters filenames greater than MAX_PATH, it seems to ignore the files, but does not give an error. Sounds like a feature for V2? Thanks!

cor - 15.12.08 8:20 am

Thanks for the feedback, LowTek, but understand, it is the Win32 API itself that does not support filenames greater than 260 characters (MAX_PATH)..

http://msdn.microsoft.com/en-us/library/aa365247.aspx

While it would likely be possible to create a workaround using Unicode path schemes, such as \\?\C:\<path>, I'm not entirely sure that would be wise. Files who's path length exceeds MAX_PATH cannot be manipulated in the shell, and a scenario where checksum might actually create such files, is unthinkable. The error-checking and fall-back handling is a headache in the making.

It would be doable, but certainly not trivial. And the benefits would only be felt by a slim minority, who haven't even bought a license!

;o) Cor

No-One - 20.12.08 3:11 am

Awesome

cor - 28.12.08 9:09 pm

In case you watch these comments, as folk do; simple checksum now has file compare. If that was good news to you, than I recommend you subscribe to the /devblog/, it's fairly low volume, but the plan is to announce all dev news there.

FILE COMPARE!

Simply drop two files onto the input instead of one. Dropping onto the program icon works the exact same way; simple checksum hashes one, then the other; and then reports whether or not the files match. Simple.

Have fun!

;o) Cor

p.s. The beta is in the checksum beta folder.

foomonger - 28.12.08 10:27 pm

THANK YOU!

This is the one thing I felt was missing from the checksum package, so thanks. I'm always comparing files. I've just tested it (XP, SP3) and it's working great.

Truth is, I've been looking for a good reason to post I've told a few people about checksum - and sent them hash files! - and got a good respose back too. Anyway, good stuff! Keep it up!

-fm

cor - 28.12.08 10:55 pm

This is gonna be one of those nights! First, thank you. And that's doubly, because I would have thanked you before, but didn't know how. If that's cryptic, then know, I know you! Well, of course, I don't know you, I but I have something you did, with a hash! And so that's that's thanksX3! For the added publicity

By the way, they need a general release, know what I'm saying..

;o) Cor

Mamboza - 29.12.08 8:04 pm

Very nicely implemented!

Peter - 08.02.09 12:38 pm

First off - LOVE the app. I'm moving 6TB of data from two RAID 5 arrays to another single store and had no simple way of checking it worked perfectly. Of course, now I have to wait a while for 6TB of data to hash...

Secondly - a feature request: I am hashing the files on RAID arrays on multiple drives (as in entirely separate drives, not just logically different), and as such I can do at least two checksums at once with no issue. Could you add an "allow multiple instances" option for use in such cases? It would literally half the amount of time my hashes will take!

cor - 08.02.09 4:31 pm

Hi Peter. First off, thanks. I wager if I had given checksum less features, or perhaps more bugs, many more would drop in to say stuff like that. *phew*

Secondly, your requested feature was added back in v0.9.22, you simply need to mindfully enable it in the prefs..

allow_multiple=true.

In my latest (beta) version of checksum, if you have this set to false and attempt a second instance, it pops up a dialog telling you exactly how to do it (rather than just let you know that you currently cannot).

If you use checksum a lot, I definitely recommend have a read through the version.nfo, there are a lot of tricks and tips in there, though it is rather long. At the very least, chuck checksum.ini into a text editor and have a scroll. There's probably other things you wish it could do that it already does!

for now..

;o) Cor

Flipper - 17.02.09 8:50 pm

AMAZING Software! I've been using it for weeks and it's way better than anything else for hashing. Now a feature request! I'd like to be able to rename files that I've already made checksums for. Is that possible? Pretty Please!

wraithdu - 19.02.09 5:20 pm

Is the checksum 1.1.6b beta available for download anywhere? I see it in the changelog, but can't find it anywhere, not even the beta section of your distro machine. As always, keep up the great work!

Nameless Checksum - 28.02.09 4:53 pm

Hi Cor,

First, thanks for a great program. Very fast and does everything you stated in an intelligent way.

Second, a feature request. Suppose I wanted to create a checksum for 10 thousand historical images that I intend to back up in archives to be burned to dvd. I want a checksum to remain on my hard drive so I can verify if any of the new images I accumulate are ones I already have. In this case, the fact that the name must be identical is a problem, as many files get renamed.

Out of 10,000 files, could your program give a similar message to this: "9939 exact matches, 57 hash matches with wrong names, 4 missing files. Would you like to add the exceptions to the log? (Y/N)"

This would not require going into the .hash file to rename anything, but it does let me know that out of 10,000 files that I have some of them already (with different names) and can delete the newer duplicate files before I make my next dvd backup.

This would add tremendous functionality to an already great program. Imagine being able to know whether or not you already have a file (verified by md5 or sha1 instead of crc32) on a dvd without having to pull it off the shelf and unarchive the contents. That the file has been renamed is of little consequence to me in my scenario, but the program would specify exact matches versus matches with wrong names so as to meet everyone's needs at the same time.

Thank you for considering my suggestion.

- Nameless Checksum

cor - 01.03.09 2:54 pm

This sounds like tremendous functionality with tremendous overhead. For example, I have a folder with 100 files. But I only keep hashes for 25 of them, this in intentional. With this functionality enabled, checksum would NEED to hash every single file in the folder, to discover if any of the hashes match. The whole operation, then, would be 300% slower. It's something I might consider having on a switch, but not the default behaviour.

The fact that your newer files might have different names from the original files sounds like a situation specific to your own archiving scenario. In the real world, files usually get new names only when we give them one. Somehow you have downloaded files you already have, except it has a new name somehow. And because of this error (renaming the file in the first place, whoever did that), you download it again, not realizing you have it already. And then you delete it anyway. The solution is to stop this crazy renaming at its source! Mail them!

At any rate, the whole "rename" business is something I am already considering, and will doubtless tackle when next I sit with the checksum code (i.e. when I get motivated to devote yet more time to it). The functionality you seek will be rolled into this anyway, your dialog would more likely read.. "9939 exact matches, 57 renamed files, 4 missing files. Would you like to: [rename hashes to match files] | [log errors and continue] | [just quit]" or something along those lines. We might be looking at a special rename mode.

In the meantime, you do not need to unarchive the file to discover a duplicate. Simply hash you new file (maybe drag into simple checksum, perhaps with auto-copy enabled) and then search the .hash file for the hash string; a few key presses, much quicker than pulling a dvd from the shelf!

;o) Cor

Nameless Checksum - 02.03.09 2:48 am

Thanks Cor for the quick reply.

I downloaded your program the day I wrote, and am still putting it through the paces and becoming familiar with all of its features. I have bookmarked your site, and when finances allow I hope to return to thank you for your work.

I see now that my request was more complicated than I realized. I have made CSVs before with another program for the DVD verification scenario that I mentioned, but it was not as fast as yours, nor as thorough (crc-32 only) so I was naturally curious how closely yours could come to what I was already familiar with.

Renamed files is a huge problem. I could have "Abraham Lincoln.jpg", "Abe Lincoln.jpg", "Abe.jpg", "Lincoln.jpg", "President.jpg" etc. etc. and not know it. That is why I asked about hash matches with wrong names, so I would know which files I can delete today rather than archive. I do not expect to be searching a hash file on an item by item basis on the possibility that some of the files are duplicates, however. There are too many other pleasant things in life to enjoy, and life is far too short as it is.

At any rate I enjoy your site. Good luck to you.

- Nameless Checksum

cor - 12.03.09 11:40 am

Not so quick this time!

The more I read about your situation, the more I think you could be doing with some kind of specific synchronization utility. When I was playing with Vista, I came across a rather good free one, from Microsoft, of all people. "SyncToy", I think it was called. Many of these apps (and there are many) will allow you to keep off-line databases, so to speak, of the archived files, and automatically synchronize the two based on a set of user-defined rules.

I'm still curious as to how you come to have so many potential duplicate files with differing names. This seems so much like a problem with the other end of things, where the images enter the system in the first place.

Good luck!

;o) Cor

Michael - 15.03.09 1:42 pm

Hi cor,

great program you wrote!

I have a question and a comment.

If I create a central root checksum file for a tree of many big files (in my case: .TS video recordings of my DVB-S receiver), I can simply include the checksums for the new recordings I copy daily/weekly to the folder structure.

But If I decide to move already existing (on disc and in the central checksum file) files to other folders in this tree (for example: I decide to move the folder 'The Simpsons" from the folder "Comedy" to the folder "Animated stuff", the relative and absolute path of the files changes... and the old entries will not be deleted automaticlly out of the central root checksum file. This is "wanted" by design (and it's good in my eyes)

The question is: is there a switch / option I can set so checksum "cleans" to central root checksum file by deleting entries for no longer existing files ?

If not, maybe you consider implementing such a switch:
"Clean checksum file" -> deletes old entries from checksum file (but does not create new entries or verifies files in the same run).

And the comment:

>I'm still curious as to how you come to have so many potential duplicate files with differing names.

one guess: you download thousand of music files or picture files from whereever you get some. You have no influence of their names...and you can not get the "publishers" or "creators" to sync themselves in name schemes.

(yes, it's a typical scenario of people doing illegal things... but no real scenario where I download thousands of files comes to my mind...)

Michael

Interested - 25.03.09 10:40 pm

Looks like you've got a winner of a tool here, but I've got one key question:

Is there a way to get checksum to recursively check a folder (and its sub-folders) and drop the checksums into a *single* file that's located somewhere else? I don't like intermixing .hash/.md5/.sha files with the normal data files, even when hidden (my Windows Explorer default is to show hidden files).

This would be very similar (I believe) to how you handle read-only media.

Friend - 13.04.09 3:04 pm

I have same issue like Michael posted,

I want to remove old entries in the hash file, due to i moved them around, or to new place.

Can you develop this?

If this is available, your software is indeed complete and i would buy it many times over!

cor - 13.04.09 3:37 pm

Interested, yes, create a "root" hash. Launch checksum with the SHIFT key, and you will see the option in the one-shot dialog. You can also set it in the prefs to always create hashes this way, if you prefer. There's also a command-line switch for it. See the help files.

Friend, that's not how it works. You support the author, THEN he gets motivated to add extra features. But so few do. I've already put in hundreds of hours for near-zero financial reward. People keep telling me how great checksum is, but I already know that, I use it dozens of times a day. I'd now prefer some cash, thanks.

Michael, Friend, it's definitely doable. In fact, I have something similar penciled into my 2do list. The plan is, on verification, if there are missing files, checksum will ask if you wish to remove those hashes from the checksum file. Simple.

Of course, the question is whether or not I can get around to adding these things. Currently, nothing could be farther from my mind!

;o) Cor

Me - 14.04.09 2:15 pm

trogan horse generic_c.AJOW Is this for real or part of the program?

cor - 14.04.09 6:33 pm

See here.

;o) Cor

Jakesome - 17.04.09 9:27 am

A quality product. Thank you.

Vorlon - 17.04.09 12:40 pm

@Me

Re: Virus False Positive.

There are a few AV products out there that use the same engine and hence the same definitions and of course if one says x file is a false positive - they all will.

However, for peace of mind, i always use on any file my AV might throw up a false positive on www.virustotal.com
I tend to hoard some files, like say Nvidia/Ati drivers (for example) and it's amazing that these files have been "clean" through years of scanning and then suddenly my AV suggests I have some sort of Virus/Trojan on one of them. 99% of the time too, they "have" (apparently) a virus that has no write-up or no database entry and are AV vendor specific. Sometimes too (and it can be months) that suddenly they become "clean" again.

I'm quite wary of files and download sources anyway and can honestly say that since 1994 (and an early Norton AV Dos version not long after that), I've only had one confirmed virus/trojan ever, which was happy99.exe

Use VirusTotal though as it will check the file with many up-to-date Antivirus programs, including the Industrial strength Sophos Anti Virus (amongst many)
If it says the file has already been uploaded (ie someone has tested the file) you can always upload yours and have it retested.
Its interesting to see which AV's show the false positive, because often you can see they use the same engines, ie kaspersky might license their engine for another vendor to use. The real giveaway is that the Virus definition version is the exactly the same.

I bought two because I use Checksum on my laptop and pc, although Cor tells me one would have been sufficient. However at just £5 and for the amount of time and hassle checksum has saved me (plus peace of mind) it's well worth imo much more than that - hence I Wanted to by two.
When i see some other utilities, say through Cnet downloads (or similiar) at £20-£25 ($30-40)that do very little AND impose strict time allowances or functionality "for testing/trial purposes", Checksum IS a bargain. I hope Checksum gets more exposure as it wouldn't surprise me if there are companies out there with large databases that would find Checksum more than just useful in data transfer integrity checking, but an absolute Must. EDIT Cor, having problems with downloading latest version of Checksum with both Firefox and IE. Unusually the result of the download is around 200k (few times). It seems after a few attempts i've managed to get an uncorrupt version of the zip file. I don't usually get any corrupt downloads. P.S. I'll have to look up one of my old emails from yourself, but is the entering of the license info the same in the new version of Checksum? cor - 17.04.09 3:50 pm Hi V! (who represents 50% of my licensed user base!) You know, when I started working on making checksum something I could distribute, that exact thought was at the back of my mind. I saw, and still see, a gap in the market, where an intuitive yet highly functional data integrity checking utility like checksum would fit perfectly, and actually does. The stampede of checksum industrial licenses, as I saw it, would easily sponsor my other activities, keep all my media and information free, and my software "trial periods" infinitely long. How wrong can a man be? It's definitely an exposure thing. I see a new site with a post about (my) KDE sizer almost every other day, after a single post on lifehacker months back. I'm getting by right now, so I can just watch and muse and think wishfully. Of course, that won't last forever, and the whole shirtware license thing will likely need to be overhauled. Bummer. It's a culture thing, I guess. We're used to getting stuff for free; software, music, media, because mainly it's theft from "large, corrupt corporations", and is morally okay in most people's eyes. The trouble is when that thinking spills over onto the hand-crafted output of the likes of me, making the viability of any business model relying solely on the honesty of its users dicey, at best. Och well.. ;o) Cor ps. I've just tested both browsers, and again on a remote desktop, just to be sure. 100% every time (around 1.04MB). Erm.. Maybe some cache between you and me? Otherwise, usual tricks; delete browser cache and cookies, restart it. If that fails, it's never a problem to mail me for the latest copy. I'm always happy to go the extra mile for my users! pps. YES! That reg code is good for the life of checksum v1.*, and as checksum users will be aware, there's a lot goes on between one version digit and the next, so it will probably be years before you need to think about buying another. ppps. Yes, my feet are a mess of bullet-holes! Kha - 22.04.09 8:40 am McAfee detects setup.exe as W32/Autorun.worm.gen - type Virus. How come? James - 22.04.09 10:12 am Hey there, just a quick note, very nice and useful software. Don't buy too much whiskey with my £5! One small issue though, hashing across the network seems rather slow... I copied 274GB (all legal I swear, Officer!) to my local drive at around 30MB/s, and hashed it locally in 74 minutes (so roughly 61MB/s). However hashing the same data stored remotely is running at not more than 9MB/s i.e. a lot slower than the capacity of the link would suggest. I would've thought that hashing the data is simply a linear read operation? Unless I am missing something here. Anyways not a big deal, it'll be done by tomorrow morning. Thanks again for this very handy piece of software! - James Vorlon - 23.04.09 7:54 pm Kha - 22.04.09 8:40 am McAfee detects setup.exe as W32/Autorun.worm.gen - type Virus. How come? Looks like a False Positive For peace of mind, check the file with around 40 AV scanners at www.virustotal.com Qriist - 24.04.09 2:34 am Looks like a great program and I would love to switch over, but would you be willing to add CRC-32 (.sfv) verification to the routines? I am part of www.redump.org, who hash many things, and a one-stop shop for hashes (as well as only posting a .hash file instead of .sfv, .md5, and a .sha1) could help make the site smoother and help convert a fairly large community to your program. Of course, CRC-32 verification/generating needn't be mandatory, perhaps a .ini setting? Looking forward to your reply! ---Qriist Qriist - 26.04.09 7:06 am PS, Also, maybe add a function switch in your "hash type selector" to automatically do all hashes types? Cheers! ---Qriist cor - 28.04.09 9:15 am Thanks James, I look forward to getting that! (note, my PayPal was offline for a few days - I forgot to update my site prefs with my new PayPal email address - oops!) As for your network, I dunno; there's not enough information to draw any valuable conclusion. I didn't have networking specifically in mind when I created checksum, and all tests passed, though its file routines are most definitely optimized for local files. The data is read fairly linearly, yes. But like I say, I'd need more info to consider this. Feel free to mail me wads of it, and I will look more closely. Qriist, this has been asked before, or thereabouts. I might add Automatic SFV Conversion/Update; perhaps. I've currently completed my 2do list for the hashing dll (where this code would need to live), so it wouldn't be any time soon. Having said that, if I were to suddenly receive large amounts of support, I could definitely look at squeezing something in! And having said THAT, isn't about time you update your folks to a decent verification algorithm? checksum could convert them all. An extra option for "both hashes" is already on my 2do list. Future versions of checksum may have the ability to keep the "one-shot" options open, so they are no longer one-shot. Tied-in with this capability, would be the discreet capability to perform double-runs, so-to-speak, and automatic multi-hashing™ would be one side-effect. It's not at the top of the list, however. But even if that didn't happen, some other way to perform automatic multi-hashing is definitely on the cards. ;o) Cor ps. cheers V! Qriist - 29.04.09 4:26 am It isn't much, but you may expect a payment from me come the end of the week. ^_^ HenryY - 29.04.09 10:52 am Great software-discovered today. Does all I wanted and more! Thanks heaps! And cngratulations on the editor's pick award at Brothersoft! Def deserved. (HY) cor - 30.04.09 2:52 am Ha! Nice find Henry! (Brothersoft is one of only three sites officially allowed to promote checksum, so this is definitely okay) I dunno if you read all the earlier comments here, but that's double-plus funny with a little history! I swear guys, I DID NOT PAY A DIME! And there's no bs links on this page, either! Good stuff! I noticed a couple of new tutorials this week recommending checksum as the tool if choice, too. Always gives me a warm fuzzy glow, albeit temporary, and not entirely effective against the bitter Scottish Winters. But it's April now.. Cheers, Qriist. Though I'll reserve my actual thanks, for now. As we say in Aberdeen.. Heard it! Editor's Pick, eh… ;o) Cor Qriist - 30.04.09 9:09 pm Heeey... Cor! Check your recent orders... ^_^ ---Qriist cor - 01.05.09 2:43 pm Thank you very much, Qriist! And within minutes (okay, like 110 minutes, but still, WITHIN MINUTES!) another happy checksum user drops some beans into the big money-go-round, and the checksum licensed user base almost doubles, just-like-that! Happy days, indeed. I wonder if this has anything to do with my new, highly subtle checksum license page? l*rz.. ;o) Cor Qriist - 03.05.09 4:34 pm Glad I could help. By the way, I really got a kick out of the reg_code! Gary - 04.05.09 4:33 am After reading this page I thought no way checksum could live up to all your hype. but it does! Way to go! Thanks m8. a guy - 04.05.09 3:46 pm Re: false positive, even after analysis from Avira GmbH date Mon, May 4, 2009 at 6:50 AM Dear Sir or Madam, Thank you for your recent inquiry. We could not find a virus in the attachment you have sent us. This is a false positive. We will take out the pattern recognition in one of our next updates. We thank you for your assistance. <snipped> Thanks for the report. Most of the AV companies that messed up have now re-classified checksum as a false-positive, so hopefully there should be no problems along these lines from now on. But that's not a guarantee; it's nothing to do with me! ;o) John Doe - 22.05.09 2:54 pm I had checksum installed for quite some time but I had to uninstall it as it created far too many .hash files which I never created. It's as if it was creating hash files for any files my PC accessed. I searched for .hash files on my PC and 7500 of them were found. Of that 7500 files I created less than 20 myself so why was checksum creating so many unwanted files? The amount of wasted CPU time must be considerable which is why I had to uninstall it. All the file modified dates of these files were dated in the time that checksum was installed and there is nothing else installed to create checksums other than hashtab which does not create such files. So why was it creating these files? cor - 22.05.09 3:16 pm Under no circumstances will checksum ever create .hash files "by itself", syat. You, or someone at your workstation must have created them. Remember, by default, checksum creates hashes for all the files and folders it finds in the path you specify, and all the folders inside those. If you want to change this behaviour, hold down the SHIFT key during launch, and un-check the recurse option, or set that permanently in your preferences. ;o) Cor Qriist - 25.05.09 8:28 am It is likely, especially since it was right after install and not used to the extra buttons, that he simply hit create checksums and....finito, 7500 lovely wasted cpus...But you damn well better believe those files were hashed like no others! To that end, I kinda sorta did this myself....very shortly after install, though I caught it and stopped it. I must say, it isn't a big problem after a couple days. cor - 25.05.09 11:47 am Hmm.. maybe. I guess after using software that tends towards mollycoddling, checksum's just-do-it style of operation could lead to a small period of adjustment! Whether this is related, dunno, I'm looking at making checksum stand-alone, in the sense that it will no longer need an installer, and will be able to setup your explorer menus itself, file associations and so on (and remove same settings). I've used this approach on other apps I've been working on recently and it feels much cleaner. ;o) Cor idkj - 30.05.09 7:33 am - VirusTotal.com Scan Results - May 30, 2009: http://www.virustotal.com/analisis/81a02d38056d7b29047bbb80e03eceac2906b379a125d6f6046db86f73f20e21-1243663817 Great work, too! John Doe - 16.06.09 5:51 am With regard to my previous post and the thousands of hashes created. I could of right clicked folders/drives and mistakenly hash checked all of them. But I have since re-installed it to give it another try but I have found .hash files which I know I did not create as they were programs that I had been running! Unfortunately I deleted them without checking the contents. I will monitor it and check the hash files next time to see what is creating them. I do have a few hash programs installed. I completed a Virustotal scan yesterday and again a short time ago. Note the hashes which do not match the hashes of idkj VT scan. The hashes for the file I uploaded match the hashes supplied by Cor underneath the download button. So this is the accurate scan. I don't know what idkj uploaded but it was NOT checksum. http://www.virustotal.com/analisis/e149250716a2dfdd8b3888ca9ba316604ff9b8e7b993be6d2de79def0edb0085-1245044141 CAT-QuickHeal is now off the list http://www.virustotal.com/analisis/e149250716a2dfdd8b3888ca9ba316604ff9b8e7b993be6d2de79def0edb0085-1245127745 I have attempted to contact a few of the AV companies to see if I could get them to update their databases so that they don't report checksum as infected. CAT-QuickHeal have responded saying they have removed the false from it and white listed the file. But McAfee still have not responded and Nod32 which many people use sent me an email saying my email did not contain a valid ticket number so they have not read it. ESET (Nod32) are a terrible company when it comes to contacting them. They never reply to virus submissions or add them to their databases after 6 weeks or more so I don't hold out much hope of a successful false removal from them. The best part about it is their forum gives directions on how to get a false positive removed but after following it they send an invalid support ticket automated response. Unfortunately Nod32 gets recommended by many online sites and magazines so people will use it. But I know their poor support so would never use or recommend that software to anyone. I would tell people to avoid it. janwm1956 - 16.06.09 10:08 am thank u Florencio - 21.06.09 7:31 pm excelentes caracteristacas ahora a probar hey - 26.06.09 5:00 am Finally, something worth it !!!! I gonna donate you$1,000,000...
Thanks

Qriist - 26.06.09 11:09 pm

Hey Cor! If you happen to get that million, share the wealth with some new features!

carlitos - 17.07.09 6:12 pm

does it work with vista?

Qriist - 18.07.09 3:31 pm

Checksum does work with vista, and in the 64-bit flavors, as well.

uyiyuiy - 22.07.09 10:55 am

very good

Are they all at fault?! - 24.07.09 12:40 pm

From "http://www.virustotal.com/analisis/e149250716a2dfdd8b3888ca9ba316604ff9b8e7b993be6d2de79def0edb0085-1248435459":

File checksum.zip received on 2009.07.24 11:37:39 (UTC)
Result: 8/39 (20.52%)

Antivirus Version Last Update Result
-------------------------------------------------
a-squared 4.5.0.24 2009.07.24 Worm.Win32.Podik!IK
AhnLab-V3 5.0.0.2 2009.07.24 Win-Trojan/Xema.variant
:
eSafe 7.0.17.0 2009.07.23 Suspicious File
:
Ikarus T3.1.1.64.0 2009.07.24 Worm.Win32.Podik
:
K7AntiVirus 7.10.801 2009.07.24 Trojan.Win32.Malware.3
:
McAfee 5686 2009.07.23 W32/Autorun.worm.gen
McAfee+Artemis 5686 2009.07.23 Artemis!73F82F2D64F1
:

Are they all at fault?! - 24.07.09 12:44 pm

Just on checksum.exe:

File checksum.exe received on 2009.07.24 11:43:18 (UTC)
Result: 3/41 (7.32%)

eSafe...7.0.17.0....2009.07.23...Suspicious File
Prevx...3.0.........2009.07.24...High Risk Worm

http://www.virustotal.com/analisis/86ccbc1209087aab77fa0b0d937b070fd7df5d604986fa966e8391ef548ceb7b-1248435798

Qriist - 24.07.09 9:43 pm

That may be true, but look: they are knocking the autoit portion. Autoit is a scripting language, easier to learn the ropes of than some others. A lot of virii are made with Autoit language and so many times valid programs are buggered because of this.

Janna - 28.07.09 8:39 pm

When generating log files to a SD card is there a way to know if these files are tampered with later on?

Qriist - 30.07.09 2:58 am

It sounds awkward, but you could always hash the logs when you generate them.

Janna - 03.08.09 2:13 pm

Qriist - The problem is that the SD card resides in the field and someone could eject the card and alter a file and then replace it. I was hoping that there might be a way that each file is automatically hashed as it is created.

a friend - 08.08.09 12:54 am

Good night

You can contact the following Antivirus producers and to correct any information is related with a false positive.

All them were run by the virustotal service ( www.virustotal.com )

a-squared 4.5.0.24 2009.08.08 Worm.Win32.Podik!IK
AhnLab-V3 5.0.0.2 2009.08.07 Win-Trojan/Xema.variant
eSafe 7.0.17.0 2009.08.06 Suspicious File
Ikarus T3.1.1.64.0 2009.08.08 Worm.Win32.Podik
K7AntiVirus 7.10.813 2009.08.07 Trojan.Win32.Malware.3
McAfee 5701 2009.08.07 W32/Autorun.worm.gen
McAfee+Artemis 5701 2009.08.07 Artemis!73F82F2D64F1

Vorlon - 10.08.09 2:41 am

Re: The False Positives

I'm mega careful about viruses/spyware/trojans/rootkits/adware etc and can say i have only had 1 (one) confirmed virus since 1994, the rest being False Positives (even those only run into less than a dozen).

VirusTotal is an excellent checker and a service I use from time to time. But seeing non of what I would call the top AV's ie Sophos, Norton, Kaspersky identify anything wrong with checksum, I feel confident the software is clean. Equally even those that do detect "something" amount to 20% of the bunch and often some of those AV's use the same engine, so are essentially the same.

Eventually, if Cor has got time it would be good to iron things out with the AV vendors (False positive wise) if anything, to boost the popularity of this excellent product. I have purchased two licences because I have found checksum to probably be the best utility i have ever used. Equally, Cor has offered a "non crippled" program essentially for free and hoped people would make a contribution purely on trust. Because of that (and I never have met Cor) I genuinely feel Checksum is a "clean" piece of software. I've Not had any "issues" in any regard with Checksum.

Vorlon - 11.08.09 11:12 am

I noted whilst checking ValveSoftwares Steam platform the other day the amount of PC Games that are seen as "suspect" by "NOD32, ESET, Avira, and others" when of course they are legitimate.
https://support.steampowered.com/kb_article.php?ref=4361-MVDP-3638

FDGFD - 18.08.09 9:54 am

The hashes for the file I uploaded match the hashes supplied by Cor underneath the download button. So this is the accurate scan. I don't know what idkj uploaded but it was NOT checksum.

Sam - 20.08.09 4:44 am

I was thinking you should make it so it'll read *.md5* and *.sha* since not everyone uses .hash and the point of using the program is for ease of use so I'd rather not spend any time editing the extension so the program will verify those files.

Otherwise, excellent program, three thumbs up.

Mike - 20.08.09 7:16 pm

I downloaded the file "CentOS-5.3-x86_64-bin-DVD.iso" and the associated MD5 and SHA1 hashes via the ".torrent" file from the following CentOS website:

http://mirror.its.uidaho.edu/pub/centos/5.3/isos/x86_64/

Using your checksum program, I attempted to verify the "CentOS-5.3-x86_64-bin-DVD.iso" file against the CentOS supplied hashes. The MD5 hash checked out no problem. However, when I used checksum to verify the file against the SHA1 file, it showed and error and indicated the file has been changed. I notified the CentOS team about the file not matching the hash and they double checked it and said it worked.

So I downloaded another hash verification program called ExactFile (www.exactfile.com). Using that program, I created a SHA1 hash of the "CentOS-5.3-x86_64-bin-DVD.iso" file and it matched the CentOS supplied SHA1 hash perfectly. Then I used your checksum program to create a SHA1 hash of the "CentOS-5.3-x86_64-bin-DVD.iso" file and it was completely different. Here are the SHA1 hashes:

f8ca12b4acc714f4e4a21f3f35af083952ab46e0 CentOS hash
f8ca12b4acc714f4e4a21f3f35af083952ab46e0 ExactFile hash
d0b44cf7c32ed3851da1df42c594c4eda8363ca2 Checksum hash

In short, I believe your Checksum program logic for SHA1 hashes is faulty.

Mike

Qriist - 20.08.09 9:08 pm

There is a known flaw with SHA1 starting at exactly 4 gigabytes. Cor is working on it.

jerry - 30.08.09 10:28 pm

helful thanks

LaSenal - 03.09.09 2:45 am

Hope this is as easy as you say.

Nirmala - 03.09.09 3:01 am

Thanks for this cool tool. It works great from command line. But when I execute this tool using "system" command from C++ program on Windows, it takes 2seconds to create or verify checksum for "checksum.exe" file itself. The tool status shows the action is done in 0.02 seconds but the system command returns only after 2 seconds. I am not sure what the issue is. Could you please let me know on this?

time_t startTime = time(0);

string command = "C:\\work\\BinaryPatcher-Tools\\checksum.exe cq C:\\work\\BinaryPatcher-Tools\\checksum.exe";
system(command.c_str());

cout << "time taken : " << (time(0) - startTime) << " \n";

Thanks
Nirmala

captain insano - 03.09.09 3:29 am

checking this out.

cor - 10.09.09 11:15 am

Yo!

Apologies for the somewhat absence; this has been a year of great changes and upheavals, not quite finished yet, either. Okay, working back, sorta..

Nirmala. checksum is reporting the time taken to do the actual job. Your tool is measuring the total time checksum ran, including posting results (where the actual time is posted). You can change these things in your prefs, by the way. If you are looking to improve speeds a little (because let's face it checksum is ridiculously fast as it is), then you can disable the per-hash timer!

Also remember, your debugger will include the time your system took to decompress checksum.exe in the first place (it is a UPX compressed binary, for smallness), so that will vary depending on the speed of the testing system, and is completely outside checksum's control.

LaSenal, I don't lie, it creates too much trouble!

The 4GB Bug. In a word... OUCH! I was on the road when I got this one, and actually had a copy of the checksum.dll's C source with me, took a look, saw nothing obvious. Obviously I'll need to get in and fix this at some point; my plan is; "when I get ten licenses". Almost there!

Another thing that is slightly hindering forward motion in this, is that, these days, I rarely use Windows! (Windows 7 was the final straw, sorree!) However, I do plan to setup an XP box to put out a few "almost finished" Windows programs I have kicking around, as well as updates, maintenance and fixes for existing programs, including fixing this nasty checksum.dll bug.

I can't make any promises about timescale, however - other things must come first for now. I will say this though; the Checksum for Linux alpha will be with you shortly!

Sam.did you actually attempt to verify some .md5 or .sha1 files? checksum handles them by default! No editing required! And I mean ANY .md5 file! The juicy generic .hash file handling is on top of that basic stuff.

Anti-Virus warning. In a word... pffff. I make no apologies for using AutoIt to stitch together useful Windows programs. Hey, if there was something even more high level, I'd use THAT, instead! But if AV "vendors" insist on using brain-dead catch-all algorithms at back of their Amazing New Products, then I have no sympathy for them. Nor for those who rely upon them to fool themselves into feeling secure. AutoIt is too darned useful to be blacklisted simply for existing.

And on the subject of vendors, I have contacted some of them, and had reports from checksum users who have done the same. The success of these endeavors is mixed. Some have removed checksum from their brain-dead blacklist (essentially adding it to their brain-dead "whitelist", instead), others have replied that they have acknowledged checksum is V-Free and will update their lists, but haven't; and other still have simply ignored us. Even if I got paid for all this, I'd have no more motivation left to correct their incompetence.

There are good reasons that people like Vorlon don't suffer the ills these vendors (cl)aim to protect us from. Firstly, they understand security, and apply the principles to their entire computer system ("installing a firewall and AV does not, by itself, infer "Good Security" - for the record, I run neither), and secondly, they research the tools they use on their systems *very* carefully. It's no mistake that Vorlon could mention three of the best windows AV off the top of his head. I'm assuming he is a he! If not, Sorry Vorlon! And for using you as an example; but hey, at least it's a good example!

Janna. yeah, Qriist's solution is good. After all, that's exactly what checksum is for. Of course, you will want to keep the actual .hash file somewhere else, perhaps on your hard drive.

[later.. Janna, I missed your second post the first time around.. ]

That's an interesting technical challenge. But you didn't mention what kind of log files they were, what kind of computer they were being created on, or even the Operating System. The only thing I know for sure is that it's a computer system with some sort of SD capability, and there's a program running on it that creates log files.

Obviously, offering an actual solution isn't possible with so little information, but you might consider something along these lines.. Run a daemon, or a scheduled script that watches the log folder for new logs (the criteria for what constitutes a "new log", depends on the system creating them, and how). When one arrives, it is automatically hashed, and that hash piped or copied immediately to a remote server (via WiFI/etc.) or even simply to a secure local folder on the same machine, somewhere only the root user (presumably you) can access them. However, as this machine is logging to an SD card, it's likely Plan A would be preferable, as it surely doesn't have a hard drive at all!

You might even want to make that script copy the actual logs!

Keep on hashing!

;o) Cor

DrBunsen - 16.09.09 2:52 pm

Cor!

W00t! After 4 emails from me over the course of 4 months (each email more more harsh than the previous one), I finally got an email today from McAfee saying that the false positive should be fixed with the next DAT file! Progress is being made one anti-virus vendor at a time!

Also, I would've sent this next part via email, but had deleted the old emails that you and and I traded, but the private release of Checksum that you sent me (to fix the bug where foreign characters in file names will mess up the .hash file) has been working perfectly for me over the past 9 months, with the exception of the AutoIT error that sometimes comes up at times when I exit the program by right-clicking on the notification bar and tell it to stop (which I already reported).

Thanks for your work! I expect to have some funds freed up in October, so hopefully I can FINALLY send a token of thanks for your generosity to the community.

Bunsen

cor - 18.09.09 7:36 am

Thanks for your effort, DrBunsen! If everyone takes on one AV vendor each, we can lick it!

You know, always, at back of my AutoIt coding is the idea that by making useful, even "professional" tools with it, and making them available, I might firstly in some way help AutoIt out of its own bad reputation (which let's face it, it has because it's so darned useful), and also, help lesser AV vendors towards more intelligent detection methods. After all, if your current AV complains every time you use perfectly good software, wouldn' t you consider switching AVs? I hope so.

Checksum on Linux will consist of no more than a bash script (utilizing KDE & Gnome's built-in ad-hoc gui programs) coupled with some service (right-click) menus. I'd wager there isn't an AV vendor in the world that would flag it as "bad", which is good, but not good, because they wouldn't flag it because it's just a bash script, which is bad, really, because a bash script can be the most powerful, devastating kind of program there is..

#!/bin/bash
rm -rf /

A Killer one-liner!

Of course, I could be completely wrong about that, and every vendor might flag it as bad, simply because it's a bash script. But what about..

#!/bin/bash
echo "Someone loves you"

Wait, that can't be right! Someone DOES love me! How dare the vendors deny me this simple truth! Thing is, any half-decent coder could write a virus that could outsmart most AV simply because they aren't very smart, and that's not right. The only reason people don't, is that most people genuinely don't want to wreak havoc on the world. AutoIt has proved this - just because you can build a virus in half the time, doesn't mean that people will.

If I want to do a task, I use whatever tools are available, DOS, BASIC, C++, AutoIt, Assembly, bash, whatever - if you can understand one manual, you can probably understand any of them. Virus coders are the same; a language's utility is what makes it popular. What matters is what the code DOES.

In the future, as well as run the usual heuristic and semantic checks, AV software will actually RUN the software, in an automatic virtual environment, watching everything the software DOES in there. The more advanced vendors will run whole swathes of "virtual user experience" tests, simulating actual user activity over the course of days and weeks, moving the date forward super-fast, collecting virtual emails, the works. Yup, virtual machines downloading porn, just to see if LatestMediaPlayer has some special chocolate chips in its cookies!

Of course, they likely haven't thought of this, and bang goes yet another idea I should be selling! Point is, a .bat can be your friend, and so can bash. But a .bat can also bite you, and bash can, well, bash. A program that does no more than post a dialog box saying "Your system is now secure" would be better than most current AV, because at least you'd get a laugh.1

for now..

;o)
Cor

references:
Oh what a funny story it would be, how someone makes a program that does basically that. And if you ever experience any kind of security issue, and lo! actually contact the author about it, he replies eversoquickly with a thank you (for reporting this bug) and promises to fix the issue in the next release. Rather, it would be funny, if it weren't true.

DrBunsen - 18.09.09 7:39 pm

Great thoughts, Cor. It'd be nice if the AV vendors would grasp some of those truths, but alas, they're locked in all sorts of unwinnable battles. Not just against the virus makers, but against each other for market share, against their own errors (false positives that do WAY worse than just delete the Checksum installer), as well as the battle with end users which I'm sure contact them for all sorts of issues, many of which aren't the vendors' fault.

Fortunately, none of those things are MY fault so I have a clear conscience when dealing with them. As an IT Manager I did my best to rattle my meager saber (future spending dollars) with McAfee. Unfortunately, it still hasn't produced any true results. My earlier report that things would be fixed was because I was contacted by someone from McAfee (as opposed to a generic support email address) who had said that they had identified it as not infected and that the false positive would be fixed with the next DAT file. But then 3 different DAT files later hasn't made much of a difference. The only change seems to be that it's now recognized as a different virus - "Artemis!33E0F7E127BA". So I wrote another email expressing my disappointment.

It took 4 emails over several months before I even got a reply. And their attempt to fix it: FAIL. Yep, brain-dead. I'm not impressed at all. I'm going to vote with my budget dollars and switch to another vendor and recommend against McAfee to my dying day. (I would usually give a vendor a pass for a screw-up, but this has been going on for at least a half-year, not to mention that I was bitten by them back in the mid-90's as well for a different reason.)

I'll let you know if I find out that they do accidentally fix it, but until then anyone can check their level of competence by uploading Checksum's setup program to VirusTotal.com.

Bunsen

Vorlon - 25.09.09 11:46 pm

Checksum has saved me yet again a load of time and ironically on something I mentioned to you before Cor.

Recently I decided to try (as it was on offer) O&O DriveImage 4 Pro, when I normally use Acronis True Image and have trouble free use.
So to give this new software a go I created an image of two of my main partitions on an internal hard drive which resulted in the creation of a 115GB compressed image file. Anyway the target for the creation of this image file was on a 1TB external hard drive and according to DriveImage 4 the operation completed successfully. However when I used the programs own Image validation function the image file failed.
Remembering that some years ago a few external drive enclosure chipsets were causing corruption on large files I thought the only way to prove a point to see if this modern chipset was doing something similiar, would be to use checksum.

So I created a few "Root option" hash's with checksum on some some folders that totalled around 120GB, "zipped" them with 7-zip using a solid block compression and copied the file to the external drive.
For a quick check I can of course use the CRC of 7-zip to check that the contents are intact, but to prove the point accurately a decompression of the folders and a verify using checksum is a really good confidence check for your setup, especially when using any form of removable/portable media/storage.

I'm fairly confident that I will be returning to my trusty acronis products, as my external drives chipset seems to be handling data correctly. Also after validating an Acronis True Image file *.tib I create a hash file for it via checksum. This method seems to be quicker (for future checks) using the windows explorer checksum verify function and checking via MD5, rather than starting Acronis true image and verifying the file via their method.

Vorlon - 26.09.09 12:12 am

Re: Viruses and false positives.

I only ever use a virus scanner "on demand" and only have one "machine" my laptop with a full array of protection.

Firstly my main AntiVirus product KAV2010 sees all the checksum versions I have (ie one installed, older vesrions archived) as clean.
Secondly in a view to removing a particularly nasty fake AV from a friends laptop, I downloaded and have now installed for my own testing the following anti-malware programs and have since checked checksum (various builds) with them.

1)SuperAntispyware
2)Malwarebytes (excellent product)
3)SpyBot Search & destroy

All find NO problems with checksum.

The good thing is with the Virus Total site is that you can often find an innocent file will be flagged as containing malware by at least one of the AV scanners on the list. Because that does happen, I think it's reasonable for one to decide on what he/she thinks what percentage out of the various av scanners if they find a problem is acceptable. I'm quite happy if a file is deemed at least clean by 60% of the scanners, especially if they are the respectable scanners.

cor - 26.09.09 5:25 pm

Thanks for your excellent input, Vorlon.

As for speed, I would imagine that to be correct. Checksum is ridiculously fast. For example, in all my tests, on the exact same hardware, the standard UNIX md5sum tool will take 2-3 times longer to hash a file than checksum. This is why I never did quite get around to documenting the hash.dll api, because I'm greedy like that and didn't want other folk's apps to get these improved routines!

I must get around to that soon, as well as a full source package for the dll + API documentation. Once I fix the code in the SHA1 routines, that is! :/

Back on topic..

Yeah V, Checksum has saved me, many times, too! Just the other day, checksum (or rather my using checksum) discovered that my new USB >> HD converter, while flawless on Linux, randomly corrupts files when attached to XP! Over 30% (THIRTY PERCENT!) of the files (1TB total) apparently copied perfectly, but in fact, were messed up. The unit also crapped out completely more than once on vanilla XP. Very nasty, and without this (27MB!) .hash file, I wouldn't have known about the corruption until I went to actually use one of the affected files, long after the original volume has been reformatted. Ouch!

This is great software!

Seriously though, it is. I realise it has a few wee foibles, and there's still some things I'd like to add yet (left click tray menu to show/hide progress, for one), but I literally couldn't live without it. Or at least, I couldn't live without checksums, and before I had a drop-dead simple way to create and verify them, I tended not to use them, much to my agonizing detriment. This is why getting checksum for Linux working was so important to me. A computer feels lost without it!

On the platform subject, I now have an XP box setup again (and I remember how bloody fast XP Explorer is as a file manager) and have started nosing around in my AutoIt dev folder, refreshing those parts of the brain involved in verbose, high-level coding. First off the block will be LoopDropZ, and a few other wee apps I need to get the hell outta here, and then into the checksum update. At least, that's the plan. Of course, it's intertwined with a dozen other plans, so...

Anyways, I love to hear about checksum user's experiences; good or bad, it's always good. I like them HERE, too. Mails are great, but often I get comments and questions that I have the urge to repeat here, in case someone else asks. The flowers I can keep to myself.

One good question I got recently: "Will Checksum for Linux be available for Windows?" (see! someone does read my dev blog, or at least the headlines!)

Now, you may laugh, but that's actually a way better question than it first appears to be. The answer is, "I WISH!".

After working some with the Bash+GUI system, I realize that it would be a beautiful common code base, but alas, Windows lacks the back-end tools and a the shell just isn't capable enough. It's a nice idea, though. Who knows, I may bite the bullet one day and start from scratch in Python, or something!

L*rz folks!

;o) Cor

ps. Keep at it, DrBunsen! Elsewhere on site, proof of how effectively pestering large corporations (in this instance British Telecom) CAN make a difference! But your dollars talk loudest of all! Good work!

pps. I got my Ten! So now, I have no excuse, eh!

Vorlon - 28.09.09 5:29 pm

Hi Cor,

Checksum has recently brought something to my attention over the last few days whilst I've been trying out HD Imaging programs and USB HD chipset data integrity.

Anyway I've reverted back to my trusty Acronis True Image 2009 (in this case, had most the preceeding versions) and wondered why Checksum was showing an MD5 difference on a file saved to my Internal HD and "the same" saved on my external hard drive. Thinking I had a USB chipset issue here I decided to conduct an experiment, first with two image files being saved to a seperate internal drive partition and two to the external drive, but this time with No compression (so no forms of random truncation could occur).

I didn't have to do too much before I got some odd results. I used the Acronis boot/Rescue disk as i mostly do, so there is nothing else going on and it's just a basic linux enviroment. So i fully imaged just one 3GB partition (for speed) and saved the image file (say image1.tib) with no compression & with validation to a seperate internal drive. Then immediately that image was completed and whilst still in that enviroment, i did exactly the same thing calling the new full backup image file say image2.tib.
Both files validated perfectly and are interanl to the PC drives.

so, once in windows I checked both their sizes and they are exactly the same as you would expect. But using Checksum to create MD5's and checking the results, showed that the files were in some way constructed differently as the MD5 values were different. I tried windows FC.exe too and the files have been constructed differently but the original data is in fact intact in both files.
Any ideas why the same source is constructed differently in the resultant image file? I've tried it a few times with other partitions and although the resultant file/s are the same size their construction isn't.

At first i thought i had data corruption which doesn't appear to be the case, but simply Checksum highlighting that these "exact files" are in fact different.

Thanks,
Steve

makeitup - 28.09.09 7:53 pm

SMALL size...

Even smaller "functionality"...

No GUI? What the .... you're thinking? Who cares if it's the best or the fastest since it forces user to "waste" time by non-existent user interface. Similarly "Assembler" (fast like yours) beats ".NET" yet not chosen by most...

cor - 29.09.09 9:55 am

Vorlon, that is quite odd! After scratching my head for a bit, I have no answer, and dug around the web some. The only similar situation I could find was, interestingly, also about Acronis TrueImage files. It it was suggested that perhaps TrueImage adds some kind of time stamp (perhaps encoded in some way) to the images, and this causes the discrepancy. It does sound plausible. Original details here.

I've given up attaching my USB > HD converter to my windows box, there seems to be some kind of weird bottleneck causing it to crap out and corrupt files randomly. It works great attached to my Kubuntu laptop and shared up via samba, even fast enough to check hashes over the wire. Of course, I can do that easy enough on Linux now, too.

makeitup, stay clear of strong liquor! If you want a GUI, hold down the Shift key whilst launching checksum. Tada! Oh, and remember to release it again before posting here!

As for the rest, no comment required.

for now..

;o) Cor

ps. I dropped a slightly updated hash.dll
into the files/ directory. No, the 4GB thing isn't fixed. This is the dll I've been using myself for some time. As well as some minor improvements I forget (see itstory), it importantly enables you to abort the hashing process altogether. This can also be usefully employed as a pause control, if you temporarily need all your cpu cycles during a large hashing operation. Simply hit the Break key.

Vorlon - 29.09.09 5:59 pm

Hi Cor,

Thanks for the reply and the link. In fact i did get a response on the new Acronis forums from one of the regulars who did suggest something similiar. I suppose as the time stamp is the only variable(in this case)and maybe is relied upon in more respects than intially come to mind then perhaps it's that, that alters much of the file structure.

At first i thought it was a compression thing as i've found in the past that some compression programs for whatever reason decide to compress identical files in a different way (ie at different times/seperately), even when the settings are the same. So in the above instance i disabled compression and went for plain "store" only.

In fact I set True Image to "Validate" the images after creation and they all passed. I'm not sure what method they use for validation comprises of, as although the fresultant image file is built differently every time, the validation for it's contents remains ok.

Steve

inhahe - 30.09.09 2:49 pm

Your program is confusing and seems to do everything backwards just to be different. It's not an app within a zip file, and it's not an executable installer - it's a zip file with an executable installer in it. And it tries to install in c:\program files instead of c:\program files (x86) like (almost) all of my other 32-bit apps do.
The window that comes up to show all the command-line options is so tall that the buttons at the bottom are almost all the way off the bottom of my screen. The first time I ran it I clicked cancel without knowing what I was doing.
Then there is the option to use sha1 or md5, and other options (i needed sha1), but now when i run the program those options don't come up. i remember some window coming up and saying it would only come up once, with some weird exception like if you hit the shift key, so i'm assuming i have to remember that and run it with shift pressed to get those options again. (would be too hard just to provide a button in the main interface that brings up those options?)
it said i'm not using context menus, i need to provide command-line options.. but this isn't true. i ran it and performed a checksum without having to read the darn command-line list. so maybe instead of making the options window only pop up once except when you press shift, how about making that command-line listing only pop up once except when you press shift (or better, press some button).
then, instead of just acting like a normal program and showing status somewhere within the program window, it takes the liberty of making a little white banner on the top of the desktop showing what's going on. i mean it's neat that you can do that with windows, but imo it just makes things more complicated than necessary when there's no reason whatsoever for it.

finally, it spent about 4 minutes computing the SHA1 of a large iso file, and then when it was done it gave me a little pop-up window saying exactly how long it took, but nothing useful like, say, the sha1 result. i checked the desktop for the banner at top hoping it would say it there -- the banner was gone. there was no other window anywhere saying the result. considering i had to deal with the cpu usage being at 100% for 4 minutes, it was a little frustrating that your "unorthodox" style of user interface failed to provide me with an actual result.

basically i won't use this software unless i have to.

Vorlon - 30.09.09 4:07 pm

Hi inhahe,

I find it confusing that you are having problems with Checksum and with your last comment about no shown hash value after creating an SHA sum for an ISO file, i tend to think you've missed the overall idea of Checksum and the way it has been designed to work.

You will find a text/hash file residing in either the root or with the file you checked (depending on the options you set) with the MD5/SHA1 value written in it. The idea being that if you were (like most of us) to want to create the MD5 values of drive volumes or dozens of folders/sub folders that you can invoke checksum, leave it to do it's thing and it will generate a text/hash file for you which you can read, or Checksum will use to verify the file structures if you ask it to. It would be pointless to have a steady stream of MD5/SHA1's values "running" up the screen as it created values for hundreds of files, it would just be a blur - hence the results are in a .hash file that you just open with notepad.

I use Checksum all the time and can genuinely say it's the most useful piece of software I have purchased since 1993

cor - 01.10.09 1:23 am

Vorlon, I too, have seen compressors choose algorithms seemingly on a whim, and had identical files compressed in different manners. I suspect other parameters; like perhaps system load; could be factors in its decision, but that sounds far-fetched.

So long as you have hash files *inside* the volume you are creating an image of, they can, at least, always be relied upon to remain accurate.

inhahe, I firstly must echo what Vorlon said.. i tend to think you've missed the overall idea of Checksum and the way it has been designed to work. But you took the time to detail your issues, so I'll try my best to address each of them..

Your program is confusing and seems to do everything backwards just to be different. It's not an app within a zip file, and it's not an executable installer - it's a zip file with an executable installer in it. And it tries to install in c:\program files instead of c:\program files (x86) like (almost) all of my other 32-bit apps do.

There is a zip, for efficient transport over the net. You unzip it somewhere, and you get a folder. Inside that folder is a program called setup.exe, which you can click. I hadn't considered this to be complex, but I'm certainly willing to hear any specific issues anyone might have. Note, though, future versions of checksum may not have an installer at all - everything I've written since checksum has been completely self-contained (can setup its own file types, menus and such), and checksum will likely end up the same way.

As for the install location, checksum will only try and install where you tell it to! A path is suggested, but that is all. Simply click the "choose" button right next to the path, to choose another.

The window that comes up to show all the command-line options is so tall that the buttons at the bottom are almost all the way off the bottom of my screen. The first time I ran it I clicked cancel without knowing what I was doing.

Indeed, there a lot of options now! But that window will still fit on an 800x600 screen (and netbook users all have my KDE-Mover-Sizer installed, so I'm told, so they can just alt-click to drag it around!). Rather than click cancel without knowing what you are doing, it might be an idea to read some of the text in the dialog, even just the wee paragraph after the options list; it explains exactly what's going on, and precisely why you might want to click each of the buttons. I bet you could read it in less time than it took me to write it!

Then there is the option to use sha1 or md5, and other options (i needed sha1), but now when i run the program those options don't come up. i remember some window coming up and saying it would only come up once, with some weird exception like if you hit the shift key, so i'm assuming i have to remember that and run it with shift pressed to get those options again.

So you DID remember that if you hold the shift key, you can get back the one-shot options at any time. Good! Intuitive, isn't it! I use the one-shot options a fair bit myself, and find the shift modifier behaviour highly convenient. Otherwise, I expect checksum to just get on with it, immediately, using my default settings.

(would be too hard just to provide a button in the main interface that brings up those options?)

No, it would be completely impossible. By that time, checksum is already getting on with the job. It's probably finished. That dialog provides a way to alter checksum's behaviour for a particular task. During that task, is too late.

it said i'm not using context menus, i need to provide command-line options.. but this isn't true. i ran it and performed a checksum without having to read the darn command-line list.

Well, technically, you are providing a command-line. That's exactly what dragging something onto a program does. But you are right, I could add that to the error dialog, too (except, isn't it tall enough!). It does state all over here that you can drag and drop stuff directly onto checksum, though. I guess I thought most people would want to get the most out of it, and read the faq, tricks & tips and stuff, but no matter how much I slave over them, this will never be the case. Och well.

I would expect, though, that someone who considers themselves savvy enough to NOT go with the default install, would be savvy enough to figure out how else they were going to run checksum! Of course they would probably want to thoroughly digest the contents of checksum.ini.

so maybe instead of making the options window only pop up once except when you press shift, how about making that command-line listing only pop up once except when you press shift (or better, press some button).

The dialog you are referring to is basically an error message, meaning "you clicked checksum directly, and that's not how it was designed to be run + lots of info". That dialog even offers you the option to launch simple checksum, just in case you really do need a GUI program that you can throw things at, set the algorithm, see the hash itself, and so on. Click "Yes" next time, and you'll see what I mean. The idea is, during normal use, you will not see that dialog, ever.

then, instead of just acting like a normal program and showing status somewhere within the program window, it takes the liberty of making a little white banner on the top of the desktop showing what's going on. i mean it's neat that you can do that with windows, but imo it just makes things more complicated than necessary when there's no reason whatsoever for it.

I agree, no progress information is required during hashing operation, no nothing whatsoever! Just the .hash files! But some people like that, and so I added the progress windoid we all love so much. I mostly use it myself these days, too. You can click it and drag it to another place, by the way, if the top placement bothers you. Another by the way; it might look cool and high-tech, but it's just a regular window like any other. Also note, you can disable it altogether, if you wish.

And hey, if there's "no reason whatsoever" for even a minute progress window, how much less reason is there for a full-blown hashing GUI? Which is why checksum doesn't have one.

finally, it spent about 4 minutes computing the SHA1 of a large iso file, and then when it was done it gave me a little pop-up window saying exactly how long it took, but nothing useful like, say, the sha1 result. i checked the desktop for the banner at top hoping it would say it there -- the banner was gone. there was no other window anywhere saying the result. considering i had to deal with the cpu usage being at 100% for 4 minutes, it was a little frustrating that your "unorthodox" style of user interface failed to provide me with an actual result.

Of course, you later realized that there was a hash file sitting right next to whatever you were hashing. That's what checksum does. Even if you were hashing in some read-only space, checksum will leave a .hash file, except in some other place, of course. In fact, checksum will go to extraordinary lengths to ensure that for no reason, ever, do you "get nothing".

basically i won't use this software unless i have to.

Absolutely! And that's a maxim I apply to ALL software!

for now..

;o) Cor

marcinw - 05.10.09 10:47 pm

I routinely hash 4 or 5 large files (3GB each, several minutes of hashing per file) currently using other application that does not support selecting files via Windows Explorer's context menu. I'd like to do this with checksum, which offers such possibility (I've enabled the 'allow_multiple' option in the ini file, of course).

The question is -> Any chance for implementing a semaphore (e.g. using temporary files) that will prevent multiple instances of checksum from reading the disk simultaneously (after user selects multiple files in Windows Explorer for hashing)?

For me, checksum without semaphore - , checksum with semaphore - all I need .

Rgds,
marcinw (Poland)

marcinw - 06.10.09 2:38 am

OK, I can always move the files to a temporary folder (within same disk (partition) this doesn't physically move data, so it's fast) then I can use checksum (by right-clicking) on the temporary folder and move the files back.

So, I guess my proposal from previous post is not as much needed as I thought.

cor - 06.10.09 7:37 am

marcinw, take a look at the Batch Processing section.

;o) Cor

marcinw - 06.10.09 10:33 pm

Yes, you are right -> I can use hashDROP.

However, it is a bit frustrating (at least for me), when for hashing a couple of small files I can use multiselect and right-click menu, but when huge files come into play I need to use, in a completely analogous situation, some other methods (hashDROP or *.bat file).

As I can see, such inconsistency is not a problem for you. What can I say? OK, you're in charge here, you decide.
marcinw

cor - 07.10.09 8:49 am

marcinw, you are creating problems where they don't exist. There is nothing at all to stop you using checksum in this manner on any number of files, of any size. It simply wasn't designed to be used in this way, that's all. Why not hash the entire folder? Or use a file mask? Even doing it your way, it will work just fine; your drives will thrash a bit for the duration, that's all. No big deal.

I suggested a batch processor, as you seem to want to perform some series of unusual hashing commands (that is, not hashing a file or a folder, or a volume, but a specific set of named files). If that's the case, simply setup a batch, and it's done.

And yes, I am in charge, and I do decide. And I decided, a long time ago, to listen carefully to all intelligent suggestions, and implement any that made checksum better. I'm not so keen on dismissiveness and wild assumptions, though.

One thing I have considered, which might be useful in your case, is to have checksum accept drag and drop of multiple files onto its file mask input in the one-shot options dialog, so it might read, "file1.jpg,file3.txt,file2.ocd", and thereby produce a hash for only those three files.

If it's always the same or similar files, it would be easy enough to setup a shortcut somewhere. For example, I like to give all my latest torrent downloads an individual hash file, so I keep a shortcut in my favourites menu (which I don't use for internet stuff, it's too handy there in Explorer to waste on that stuff). Its command-line is..

"C:\Program Files\corz\checksum\checksum.exe" crtbim(movies) "D:\Torrents\Completed"

At any rate, there's usually an easy way to achieve what you want with checksum, if you are willing to explore its many options. And if not, suggest one!

;o) Cor

Bill - 10.10.09 3:53 am

Just wanted to say Checksum is a great program and keep up the good work!

JohnnyQ - 15.10.09 5:11 am

Recently I decided to try (as it was on offer) O&O DriveImage 4 Pro, when I normally use Acronis True Image and have trouble free use.
So to give this new software a go I created an image of two of my main partitions on an internal hard drive which resulted in the creation of a 115GB compressed image file. Anyway the target for the creation of this image file was on a 1TB external hard drive and according to DriveImage 4 the operation completed successfully. However when I used the programs own Image validation function the image file failed.
Remembering that some years ago a few external drive enclosure chipsets were causing corruption on large files I thought the only way to prove a point to see if this modern chipset was doing something similiar, would be to use checksum.

odalet - 16.10.09 10:48 am

Features suggestions:
- Support SHA2 hash family
- Support RSA signing?

slorp - 16.10.09 4:51 pm

Generic.AOUJ

Person - 17.10.09 11:59 am

My AV software reports a trojan in this software.

Vorlon - 17.10.09 4:14 pm

@ Slorp & Person

What your Virus Scanner is doing is reporting a "False Positive", when in reality there is NO virus. Basically some Virus scanners (with their current definitions) are identifying code or bits of code wrongly in Checksum that may loosely resemble that of code that has been known to be used in a negative way. Rather than taking a more accurate approach, some scanners will Tar some types of code with a very big brush, inadvertently flagging legitimate code too.
Virus scanners are like anything else when it comes to quality, ie some are very good, fast and accurate and others let themselves down by missing malicious files and flagging those that are innocent, ie False Positives.

Because most people don't have or can afford to purchase 40 or so Anti-Virus scanners including the "Bank" strength type scanners from companies such as Sophos, i suggest you go here to www.virustotal.com and check any files you are concerned about.

Also i highly recommend three malware scanners; MalwareBytes, Spybot Search & Destroy, SuperAntispyware.

So for peace of mind try:-

www.virustotal.com
http://www.malwarebytes.org/
http://www.safer-networking.org/
http://www.superantispyware.com/

EDIT

I've just checked the Current Checksum version at virustotal.com and out of 41 AV Scanners only 6 suggest that there may be something and out of those, 2 (maybe more) appear to use the same AV engine.

Those that find NOTHING (ie the file is clean) are:-
(As you can see the most highly respected AV scanner Vendors find the file ie, the complete Zip and ALL it's contents to be clean)

a-squared
AhnLab-V3
AntiVir
Antiy-AVL
Authentium
Avast
BitDefender
CAT-QuickHeal
ClamAV
Comodo
DrWeb
eTrust-Vet
F-Prot
F-Secure
Fortinet
GData
Jiangmin
Kaspersky
McAfee
McAfee-GW-Edition
Microsoft
NOD32
Norman
nProtect
Panda
PCTools
Prevx
Rising
Sophos
Sunbelt
Symantec
TheHacker
TrendMicro
ViRobot
VirusBuster

All the AV Vendor product versions/virus definitions release dates can be found on VirusTotal along with all the results, but as you will see the vast majority, including some of the most respected scanners find Checksum to be clean.

Qriist - 18.10.09 12:55 am

Thought you would like to know that your md5 hashing is accurate for files 45gb+.

Good stuff!

cor - 19.10.09 5:32 pm

Thanks for that, Vorlon; and a useful list. In future I'll probably just delete all those sorts of comments on my next pass through; I might even post your list in the page proper, save us have to repeat it!

You see, slorp , to qualify, it needs to be a real worm. As I know checksum has none, my Million Pounds is quite safe - for you to get paid, two miracles would have to happen!

Qriist, I didn't suspect for a moment that it wouldn't be!
It's good to know, though. But I gotta ask, what the HELL sorta file is 45GB?

;o) Cor

Qriist - 21.10.09 10:49 pm

I dumped 2 Blu-ray movies to ISO format to test checksum. Resultant test files were quite large.

shoguntom - 22.10.09 2:00 pm

I just installed checksum, and this program is awesome. I really like the approach, it's contrary to most windows developers out there.

I am having a problem though, I can't seem to get the options dialog to pop up when I hold down shift. I'm using win7 32bit, so I'm assuming ms might have done something in explorer to break this functionality? Command line options work as expected so I'm still happy. I was just wondering if anyone else had that problem.

shoguntom - 22.10.09 2:15 pm

A quick workaround for anyone else with this problem - modify setup.ini to always show options and then reinstall. The file is heavily commented so it should be pretty self explanatory.

cor - 22.10.09 3:54 pm

Ahh Qriist, you are technologically more advanced than me, I'm not in the Blu-ray loop yet. That's some BIG files! I guess folk are gonna want to sha1sum them at some point.

Thanks for the heads-up, shoguntom, and the kind words. There's a high probability that they will make their way into my front page auto-quote feature! Oh, wait a minute, I knew there was something I forgot to put back in, last time I updated the front page. Doh! Maybe this is just the kick I need; you basically hit the nail on the head, shoguntom; it's all about the approach. In this case mainly, "Get the job done, now!".

I'll keep my eyes open for other's posting about context menus on W7/32 (through the power of web voodoo, I keep a vague and distant eye on some of the places out there where checksum is discussed; to make it better, you understand). If this issue starts getting airplay, I'll definitely look into it, I mean, context menu use is another thing checksum is "all about". Can a thing be "all about" more than one thing?

NOTE: You don't have to reinstall checksum to get this functionality. If you check out the tips page, there's a section on how to create a context menu especially for music (albums). There's even a sample registry file you could use/edit. Simply insert whatever switches you want, and merge into your registry. And it's easy enough to add a command, instead, so you have one regular launch, and one with-options. Or whetever else you need.

There's a lot of reading around here, I know, but if you are a frequent checksum user, most of it is fairly rewarding stuff.

Thanks guys!

;o) Cor

Michael - 31.10.09 10:52 pm

Awesome tool - truly awesome! The only key thing it's missing IMO is ability to specify desination folder for your hash. Say I have a RW share that I'm mirroring. I want to hash it and then verify the copy using the hash. I wish I could just specify where the hash will get generated rather than having to polute source and then move from it.

cor - 02.11.09 4:58 am

I can see how that might be useful, Michael. I'll add it to my 2do list.

In the meantime, if you set the read-only bit (temporarily) on the root directory, you will force checksum into fall-back mode, and from there, you have a multitude of options about the format and location of the final .hash file.

Thanks for the flowers!

;o) Cor

SKeG - 03.11.09 9:00 am

see checkum gotten itself onto the latest Reanimator Extreme Edition. http://dcp.sovserv.ru/program/48738/2009/09/02/reanimator_ee/

Michael - 04.11.09 5:33 pm

You don't always have permissions to change ACL on the folder that you have RW access to, so your workaround won't unfortunately work in my case.

Michael - 04.11.09 7:54 pm

Btw, another feature request I have is to allow filtering of sub-trees on a reg exp basis. Say I want to checksum all the files in the tree except for the sub-tree that is called "abc*x" and "yz*df" (there can be multiple instances of each hit). If the tree is several TBs in size and these are sprinkled throughout it manually selecting what to hash is not feasible. What I want is a single hash file that holds the entire tree except for a few subtrees that match by a specific name pattern, basically.

Thanks!

bert0123 - 07.11.09 11:51 pm

Nice program, almost perfect!

1) I would like to exclude files from getting checksummed based on file patterns.
In my directories there are files named "compositepage-01.jpg", compostiepage-02.jpg etc.
If i put in "compositeimage-" as textstring under ignore.. named files.. it does not work. Please let us exclude files based on patterns.

2) On the website I think a full description of all the options would be nice, and easier to read than the description in the ini file.

3) I like to be able to use multiple 'profiles' in windows (more versions of checksum.ini?) for different scenarios.

4) Maybe a windows frontend with more (all available) options.

Very nice program!

polbel - 19.11.09 9:17 am

hi cor,

i'm planning to use it on my 6.5 TB raid5 (Win 2008 R2 Standard 64-bit on Phenom 9650 2.3 GHz 8 GB RAM) home-made video server to check if files are staying the same over time because i discovered a few vob files that wouldn't play in my music video shows directory. do you code for 64-bit full 4 cores (or all available processors) to maximize speed?

count me in to beta test if it doesn't already and you need proof on a version that does.
the data stream on my raid5 sub-array is between 50 and 100 MB/s depending on file size and if it reads or writes. data size is 6 TB already, only 500 GB free and i still have another 6 TB of video data to move dvd > online. i also have a 4 TB music server (80% full) and a 2 TB E-book and software server (75% full) on win server 2003 32-bit to verify beta versions but these a dual-core. i also fluently speak and write french if you need to translate and get more market share. i also have a hosting site with ~ 100 GB available if you need some web space.

pol :-)

polbel - 19.11.09 9:03 pm

tested it with 154 GB of national geographics videos from my torrent server (win xp sp3 on a dell ws530 dual 1.5 GHz Xeons 1 GB ECC RAM 500 GB Sata-2 for torrents). creating md5 job finished after 5600 seconds. then it finished verifying in 2400 seconds on my 6.5 TB raid5 (Win 2008 R2 Standard 64-bit on Phenom 9650 2.3 GHz 8 GB RAM) video server where i had sent a copy of the videos. Pretty impressive!

one suggestion: add a browse button to choose logs directory.

pol :-)

Batchking - 02.12.09 2:22 pm

I'd like to point the "commandline geeks" here also to the free microsoft's "fciv.exe" commandline program.
It calculates MD5 and/or sha1, can recurse directories and stores the values for all files in an XML file.
E.g.:
fciv.exe -add %systemroot% -r -XML c:\MyDir\windowshashes.XML
will store all files below your Windows directory in c:\MyDir\windowshashes.XML,
while
fciv -v -XML c:\MyDir\windowshashes.XML
will verify all current file versions against the versions stored in the XML file.
You can also use "fciv.exe -list -XML {xmlfile} to display all file hashed in plain text.

It returns "0" if nothing has changed, and "1" if modified files have been found.
This is especially nice for batch operation using %errorlevel%.

Not as powerful as the "checksum.exe" here, but good enough for most simple tasks.

ibsteve2u - 11.12.09 10:41 pm

This is "sort of" out of the context of your program, but of great interest to me. What did you use to create the setup program?

I use InstallShield's Premier line, but they've bitten me in the sitter-downer before. To whit, if you fail to predict a system crash and uninstall Macrovision/Accresso/Flexera's product in advance, you can't reinstall on your repaired/new system because their licensing server assumes you pirated a copy.

That eventually leads you into a tangle with their support - who only work banker's hours and make no real effort to conceal their suspicion that you are ripping them off.

<b>Which ticks me off.</b>

Your install is...sweet, neat, complete. So how do you do it/what product do you use?

Qriist - 17.12.09 1:24 pm

I may be mistaken, but I think cor created his own installer from the same language used in checksum itself - AutoIt.

For a ready made installer I have had success with WinRAR in the past. You can make a self-extracting archive that can be made to remove any references to WinRAR itself, making it more or less your own.

Peter B - 27.12.09 7:49 pm

Great looking app and it almost do what I want, but I am really looking for a small easy to use (easy to download and do not need install) app for checking files I downloaded from Internet. I use it a lot on computers that are not my own (Costumers).

I use your app today but I have to make a hash file from a checksum on a web page, It would be great if when I use simple checksum and I have dropped a file on it and get a checksum. I could just paste a checksum to the application and it will compare it to the checksum that it just created and tell me if it is a match.
Or a button or a shortcut key to make simple checksum read the clipboard and compare it to the checksum it has just made.

Would save me a bunch of irritating steps to do a checksum comparison. And then I will for sure nag my coworkers to try it too and that they also would donate.

Keep up the good work.

shodan - 06.02.10 9:30 pm

Hi,

I'd like to know if there is a way to slow down checksum ?

I run it in a virtual machine that is also running another process (producing files that I then run through checksum before they are sent over sftp and then rechecked with checksum on the destination computer, I find an error rate or at least 1 bit per 100 GB)

the problem is that I run checksum about once every 3 days , but when I do it so intensely hogs the hard drive that the producing application is affected, lowering output

Í don't make if it takes 4 times longer but I have to make sure I'm not slowing down production

is there a way to do that ?

thanks !

-shodan

Stephan - 07.02.10 11:43 am

I have this nice big hash file sitting in the root folder but since its creation
I have deleted/moved several folder/files which are now "missing files" during checksum verification.
I had hoped verify would ask me to delete those entries in the hash file
or that the synchronise feature would take care of it.
Do I have to hash the whole drive again and replace the current hash file?

Of course I could edit the hash file manually but...
what about teaching "checksum" a new trick to deal with this situation?

PeterPaulW - 20.02.10 8:37 pm

Your app works well with most MD5 file formats, but the following format from a Mac could not be verified with checksum (note the additional dash):

;Created with MD5 by Eternal Storms Software
01805fe7528f0d98c595ba97b798717a - 20100205_0001.dng
01805fe7528f0d98c595ba97b798717b - 20100205_0002.dng
01805fe7528f0d98c595ba97b798717c - 20100205_0003.dng

The app is called 'MD5' from here: http://www.eternalstorms.at/md5/

Would you add a parser for this?

andi - 25.02.10 10:36 pm

hi, just wanted to let you know "checksum" saved me a lot of troubles today ... have to renew a file/database server and copy all the stuff on a temp. filesver: approx. 12 MILLION files (in several folders) with a couple of TBs in total. Some user had "locked"/inaccesible files etc. (dont even ask me how this is possible) - so in the end I wanted to make sure I realy got every file before cleaning up the old server and right now the machine is checking the directories over night (I just copied the root *.hash file to the other backup server) - till now it looks like your tool works flawless even for millions of files - Thanks a lot!

andi

PS.: McAffee indeed showed up a trojan-message but eset Nod32 says the prog. is fine ...

pop - 04.03.10 1:40 pm

Hi, just come across to this site. real present to read. the colors and design are good. your site is versatile. don't even know which category to add in my bookmark!

do have a question about checksum. is it possible to hash a drive by sector? since your program runs under windows, the feature will only be practical if we can run it under dos or linux where the drive will not be altered when mounted. but i guess it's out of the goal of this program? (too bad...)

cor - 04.03.10 6:44 pm

Thanks for the continued suggestions and comments; all are considered carefully. And for the test cases, too pol and andi (it's always great to see the words "MILLIONS" and "TB" and "impressive" and "checksum" in the same sentence!), and flowers, ta.

Michael, bert0123, I remember writing (quite extensive) code for this sort of thing in mangleezee (a renamer). It's quite possible that it may work its way into a future version of checksum for both inclusion and exclusion of files and directories.

bert0123, you can create ad-hoc "profiles" right now by simply making copies of the checksum program (aye, so they each have their own ini). For a front-end, hold down SHIFT when you launch checksum!

ibsteve2u, if you (or anyone) want to play with the installer, mail me for a copy+documentation. It's being deprecated in favour of self-contained apps, but does work rather well.

Peter B, I do like the idea of simple checksum comparing its most recently calculated hash to "whatever" string is in the clipboard (either a hash, or a chunk of text/html/etc. containing a hash), and if they match, posting that information somewhere. This is definitely on the cards.

Stephan, perhaps you need a different tool.

shodan, no, there is no easy way to slow down checksum, yet. I advise creating more checksum files (i.e. per-directory) as opposed to one big root hash file. This will by itself create more "breaks" in checksum's operation, so that other processes can get stuff done. Also, you can verify smaller areas at once, if applicable. Another method is to verify hashes over a network connexion to the local machine. As crazy as it sounds; under certain configurations, it can free up I/O and keep everything running more smoothly (at the expense of a little CPU).

PeterPaulW, checksum already supports more hash formats over more platforms than any other hashing program I am aware of. However, it's unlikely I'm going to add support for every new non-standard hash format that comes along - it really is up to them to work the other way around. At any rate, this hash format looks pretty dumb to me; though I am ready and willing to be enlightened further on the subject!

Interestingly, it states that it uses the OSX built-in hashing tools. But they are based on BSD, right?, which checksum has always supported. Who or what is adding the dash? Please find out, and mail them to ask why!

pop, not sectors, no, just file; though you could always make an image of the disk and hash that. As for your bookmarks; yeah, it's a marketing nightmare! Maybe file under "Folk Art".

for now..

;o) Cor

Davep - 24.03.10 6:38 pm

I am not sure if there is something wrong on my end or yours but when I download the Checksum.zip file, I can't seem to open it. It tells me that it is an invalid zip file. I would love to give this a try, but I can't seem to open it. I have downloaded it twice, I have tried different programs to try to open it and nothing seems to work.

Qriist - 25.03.10 3:42 am

Are you running an anti-virus? I have this problem as well when my is running (you know, always) and I think it stems from the fact that AutoIT is often flagged as bad if the file is incomplete (hell if i know why)

Good luck!
---Qriist

cor - 25.03.10 1:32 pm

I dunno about Anti-Virus (cheers Qriist!), but I do know that download managers and suchlike will get you no result. There should be no problems with a regular browser.

If anyone has real difficulties obtaining checksum, feel free to mail me at the usual address, I'll mail you a copy.

;o) Cor

ps. I have found that invalid downloaded zips are sometimes not zips at all, but regular web pages, sometimes explaining what happened, except with a .zip extension! A decent text editor reveals all.

Vorlon - 01.04.10 7:25 pm

Hi Cor,

Yes, occasionally I have problems with the checksum download where the resultant download amounts to around 100-200KB rather than around 1MB (if I remember rightly)

I'm still using Checksum often and "religiously" ,It's one of those must have programs and along with 7-Zip gets installed immediately after a windows clean install. Glad too I purchased two Checksum licences as the optional registration costs were an absolute steal (hence the two!)

Best Regards,
Steve

Sadly, most folk looking for an absolute steal, just steal. ;o) Cor

justmakedup - 02.04.10 3:12 pm

Hiho,

i just dl'ed you tool and started to make a check on a folder.
While it is still running, you show a "tool-tip"-like Message on the top of the desktop.
"creating checksum: ...."
status message^^

well for people who have their windows taskbar on top, its not a good placement for it
+ when you use the windows taskbar, you status message will go behind it, so you can't see it anymore.

I use win7, so i still can see a bit of it behind the bar, because of aero transparency - so its still there^^

when i move the taskbar, its back.

Well you may consider to place it somewhere else.
For example a few pixel under the top of the desktop, so there would be enough space for a possible taskbar.

but overall its a nice tool.
ty

Vorlon - 02.04.10 4:12 pm

"justmakedup"

You can drag the Checksum Status bar around the screen to wherever you like, by clicking on it, holding and moving it.

Tom Hafemann - 09.04.10 3:23 pm

Hey there,

Love it, but I am having a brain fart issue.

All I want to do is take a single hash of a folder. I want 1 hash created OUTSIDE of that folder to verify the entire folder.

How do I do that?

Right now, the hash runs on the entire CONTENTS of the folder, even if I select the root option. It creates a hash INSIDE of the folder which would negate any hash created ON the folder.

Tom

No, the hash would not be negated, as you cannot hash folders, only the files inside them. ;o) Cor

cj02139 - 10.04.10 3:31 pm

create a folder "X"
create a sub-folder "Y"
put all the files and folders you want checksummed into "Y"
right click on "X" and do checksum, using the single-checksum option.
you get X.hash which is the single checksum for "Y"
You could also just do checksum of "Y" and get Y.hash which would also probably work, depending upon what you want to do with the files and checksum

Russell - 27.04.10 7:35 pm

Hi,
I'm currently working with large amounts of files that I need to create checksums for but I want to be able to set the directory that the checksums end up in. I am doing this because of the need to capture data and transfer it without writing to the drive from which it is being captured. If you have any ideas on how this can be accomplished it would be appreciated.

Thanks,
Russell

It's on the 2do list - see above. ;o) Cor

Kym - 03.05.10 7:42 am

Hi

There seems to be a bug in checksum.exe, where it ignores some files. Eg

create a file on the desktop called "NCOM-20091119-060303-000.log" and then put some data into it (with a text editor or so). Right clicking and 'create checksum' on the file results in 'Completed in 0S, Nothing was done".

somehow I don't think that that behaviour is correct.

Cheers
Kym
btw, I'm using Windows Vista business 64 bit.

No, that is the expected behaviour - "log" is one of checksum's default ignored extensions. If you really do want hashes of log files (!?!), feel free to alter checksum's preferences to include them. ;o) Cor

BRANCASAi CAN; - 30.05.10 7:03 am

I can't install!
Autolt Error
Line-1:
Error:Unknown function name
I'm running XP with SP3.

The installer has no bugs that I know of. It could be a corrupted download. Grab it again and see. ;o) Cor

Robots - 13.06.10 6:18 pm

Thanks, brosoph

horace - 28.06.10 4:21 pm

thanks

Garf - 13.07.10 12:07 pm

Cor,

Today (13/7/2010) Kaspersky AV is reporting the Win32.Sality.aa virus in the http://hashdrop.50webs.com/hashDROP_v1.03.zip for hashDROP

I suspect it *may* be a false positive, as other download sites produce the same malware detection. Worth checking with your pristine copy?

FYI

I can confirm that today (2010-7-19) the zip and published hashes available at the HashDrop web page are identical to my original archived copies (MD5: 89dc09f3649154c9e874a7cd8f3f014d).

As expected, it's a false-positive. ;o) Cor

Peter - 30.07.10 12:45 am

"checksum's little bother; simple checksum,"

I am wondering what that little annoyance is.
Perhaps a typo?

Well spotted! Ta. ;o) Cor

Shaun - 01.08.10 12:18 pm

This failed to uninstall correctly under windows 7 (64bit). The installer ran, removed the uninstall program, however it left the software installed, the icons in the startmenu and the right click context menu hook in place.

polbel - 06.08.10 8:22 am

greetings,

this is a maddeningly true self-buttkicking story.

before transferring 2 TB of tv series from one of my servers
to another one to free the 6 WD green 2 TB drives to create a
ZFS array under solaris, i corzchecksummed them. as it would
turn out later, this was the best move in a shameful series
of drive configuration missteps.

the transfer to the other server went well, i turned the
source and destination servers off and went north 600 km to
fish for 5 days with my 85-year-old dad. that was from july
2nd to 7th. we had a lot of fun jigging and threw 1/3 of our
catches back in the lake as they were too small or too large.

the evening i came back i turned the destination server
on and 2 hours later the sil3124 controller that the
2 WD 1-TB green drives were plugged on started giving error
messages because of these cheap chinese-made sata cable
connectors that warp and loosen contacts as they warm-up.
mark my words, sata connectors made of thermoplastics

i spent a couple hours replacing the sata cables until the
boot sequence indicated the drives were seen by the controller
and then after getting back in windows, the silicon image
array i created out of an impulse to get higher write speed
and things done before going fishing (worst move in a 31
year IT career) was gone bringing in the tomb with it
2,000,000,000,000 precious bytes of complete series of 24,
2 and a half men, 30 rock, alias, baywatch (11 seasons of
its delicious syndication), and 5500 episodes of other
mouth-watering etc.

so i spent the month of july testing all these wonderful
raid recovery softwares proclaiming to be the best available.

i ended up using the latest trial diskinternals raid recovery
to figure out the raid 0 parameters to access the drives
which it did superbly automatically, but couldn't afford
the 250 bucks they wanted from me to register and do the job.
so i set up a 2007 file scavenger version 3.2 to the task
and after 48 hours of recovery on 2 1-TB external drives i
tested the recovery process with none other than corz' best.

of course corz helped me figure out right from the start
that scavenger's quick mode didn't know didley and files
presumed recovered with it were unplayable. but it also
proved that the long mode was dead on and did the deed.

indeed, just a few seconds of right-clicking and selecting
the "verify checksums" option on each drive roots started
an automated day-long process validating the quality of
5500 video files. mind you this was done on a quad-core
amd 9650 with 8 GB ram running 64-bit win 7. congratulations
to corz for software that works in win 7 and you will
sell me an XXL t-shirt and my son a M-one since you affordably
contributed in a major real-life recovery from a bad choice
of raid setups.

xoxoxo

paul

Keni C - 10.08.10 11:15 am

Just got to know that there is such a good software

Keni C - 10.08.10 11:19 am

anticiptaing~!

When I downloaded the files and tried to unzip and then execute... McAfee identified your download twice as having a virus attached. The following is what it identified:

Detected: Artemis!33E0F7E127BA (Virus)
Quarantined from: c\Users\<user>\AppData\Local\Temp\Temp1_checksum[1].zip\checksum\setup.exe

You might want to check it out... I saw earlier that it caught in other virus scanners... is this the same problem seen before?

Vorlon - 26.08.10 2:53 pm

I would say that if you downloaded checksum from this site then Mcafee is detecting a "False Positive".

For peace of mind you could check the whole zip over at www.virustotal.com against 40 odd AV scanners which often shows up the worst AntiVirus Scanners when it comes to false reporting.

Of course the MD5 for the checksum zip is displayed on this site so that could be checked retrospectively or by another MD5 checker.

I have used checksum for ages now and whilst I did get the odd false positive in the past, I think with Kaspersky - that was fixed by them. Since then I've not had any false positives with any of the anti-malware/virus products I use. VirusTotal though will give you peace of mind as you'll find just a few scanners (not the top ones) show false positives and often if you see more it'll be antivirus products that licence the same "Engine" from an AV Vendor.

EDIT: Just Checked Checksum.zip MD5 = f396abec141a50321caa995665db2986 at Virustotal and out of 40 virus checkers 10 suggest the file is infected. However the real figure is 8 as 2 products have obvious variants.
So out of those 8, the infections are based on "AutoIT" which is a Legitimate scripting language. Unfortunately the scanners which are displaying "false positives" are likely doing so as they are "tarring" every piece of software using AutoIT with the "same brush"
No doubt larger software vendors have the ability to "shout" at these Anti-Malware companies if their software products are seen falsely as infected, because they have real clout and no doubt legal departments at their disposal! It's much more difficult for a lone software vendor to contact the right people in every anti virus/malware house out there so that their definitions remain checksum aware.

If anyone wants info on what AutoIt is see the website here: http://www.autoitscript.com/autoit3/index.shtml

whatever - 06.09.10 10:26 pm

HashDROP is likely malware. virustotal shows 22 out of 40 scanners flag it as malware: http://www.virustotal.com/file-scan/report.html?id=18412e30aeaa2693538aa8e4f29f0af14d7180cd3ece0022b5a67783f558b65e-1283806520

I uploaded to Avira Antivir's submission system as a suspected false positive, but they confirm it as malware. It was downloaded directly from the HashDROP website: http://hashdrop.50webs.com/ and the MD5 for the hashDROP_v1.03.zip file shown on the website is correct as: 89dc09f3649154c9e874a7cd8f3f014d

I don't know how to read this info, but if you want to look for yourself, here's an analysis of the file's activity:

http://www.sunbeltsecurity.com/cwsandboxreport.aspx?id=9032335&cs=4D5F19B607163C34A66B2CCB216C8350

whatever - 06.09.10 10:53 pm

Is there any MD5 software out there that can verify the files generated by corz checksum?

whatever - 06.09.10 11:04 pm

Is there a way to use corz checksum to verify files on several different drives at once? So far, it refuses to run more than one instance, even though I've got a multi-processor PC and several different drives that are fully capable of doing this simultaneously, instead of waiting a couple of days for each verify job to finish before starting the next one.

I tried using HashDROP to at least automate a serialized operation, if it's impossible to do it the right way, but the virus risk nixed that idea.

gp - 07.09.10 8:51 pm

Thank You

Crabgrass - 09.09.10 4:37 am

repeat poster - 10.09.10 9:23 pm

http://alternativeto.net/software/corz-checksum/

checksum could use a few extra features that support updating a hash file after moving, renaming, deleting, changing, or adding a file, without the need to create an entirely new file. This wouldn't be too demanding if checksum could do this in a continuous process, where it constantly locates changes and updates the hash file. It would need to keep a history though, so unexpected changes could be located and corrected.

For actually correcting files, MultiPar (and its alternatives) has done a great job:

http://alternativeto.net/software/multipar/

It doesn't support updating minor changes yet, without completely redoing all of it's work for the entire file set. It isn't quite as fast as checksum for verification.

Petrus4 - 16.09.10 12:14 pm

Hi There,

Love your utility. Can you or will you be adding support for sha256 hashes?
Thanks,
Petrus4

zcat - 21.09.10 4:24 pm

Great util. Especially love the portable mode with the .ini.

Only thing it needs is sha256 support, such as for Fedora ISOs.

greg - 28.09.10 5:11 am

Was looking for that kind of things on Windows and happy I found your app.
I have some things to ask.
-Speed: the speed you described 100MB/s sounds like it is in fact limited by your Hard Drive speed. Have you ever tried, or anyone else, on a very fast array for example? How fast would it be on a 300-500MB/s media?
-logging capabilities: there are different ways to log changes in files. I think to get the maximum information about what could have happened if a verify of a file comes negative, it would be helpful to have logged along with the hash when creating it the modification date of the file as well as its exact size in bytes. So when verifying a file if it comes negative, date and size can be checked also. If modification date have not changed but size has then there is suspicion of unwanted modification (virus...). if both have not changed it can be an unwanted change or data corruption...
That would be nice to have a report that can give that kind of information.
-last thing about creating the hashes and managing them. looking for these options:
--clean a given directory of all the .hash files
--update all: recreate all hashes for all files
--update new: only create hashes for new files, files that were not hashed previously
--update: create hashes for all new and recreate hashes for changed files without touching hashes for files whose modification date and size have not changed and were previously hashed (hence the good thing of storing these infos alongside hashes in the .hash file)
--verify: would have to read all files and check their hashes against the stored one, flagging modification dates, size changes and negative hashes, also flagging non hashed files, all in the log.
--status: do a quick check of the status of files without checking the hashes but only modification dates and sizes.

Emilio - 04.10.10 10:41 am

I think Artemis false positive is known and, according to the following post, a definitive solution should be possible.

fairy - 05.10.10 5:04 pm

Hmm

DrBunsen - 12.10.10 7:43 am

I noticed that you are still showing on the itstory page that the version is up to 1.1.6b, but the version that is available for download is v1.1.4.0. I've been using the v1.1.5.6 that you generated for me 2 years ago with only a few cosmetic glitches (that I reported to you). Is v1.1.6b going to become available any time soon?

Thanks!

Faon - 20.10.10 2:58 pm

Yes, it very useful and powerful software easy configurable and customizable, ready to be used in very different ways in the almost all imaginable purposes.

I make customized setup, customized bat files, customized context items (verify, synchronization, build all - without user input), customized ini file and almost achieved all necessary functionalities

but

have some things still not working as expected or rather not working in optimal way.

Some of them are mentioned in other posts, but let me put them again.

What I have and what I want to make?

Let's say I want to make archive of my files and have control if it is intact.
I make a folder on external HDD, there are hundreds of GBs and dozens thousands of files.

To make it simple and not to add even more files which only I use, I chose to use one file checksum.

Because it is archive, I sometimes add, move, or delete files inside the folder.

What I got this way are some files not hashed and some errors because of missing files.

The first problem I can fix by using "synchronization" (which is not synchronization for me, but rather building incremental checksum by the way it is working), but with missing files there is no easy way.

Yes, I can create checksum from scratch (after checking that everything else is correct), but with cheap 2TB HDD (sloow) it takes lot of time, even if I've just moved few little files.

First thing I tried to do was looking inside the hash file and manually delete bad entries. And there is first strange thing: the files are in illogical order for me; not by name, not by hashes, not by size I think, not by folders/filenames (my preferred expected way), so it would be very hard to manually delete data about some folders or files.
Yes I see "synchronization" is adding entries on the end of file, and it is probably the easiest way to do in such operation, but I just think that some switch to sort out output could be useful sometimes.
Anyway it is easy and can be done manually by other tools also, so not big deal, but also not hard to add (?).

So almost done, but not in the situation that lot of things happened and lot of different files in different subfolders changed place.
Sorting and manually removing "missing errors" will not save time, and the mistake is easy to perform (it is not big deal to delete more file entries, but it increased time to "synchronize" all again).

So the solution for these could be some feature to "synchronize more accurate". One thing is do it at once, and second there could be a switch to "remove missing errors" by deleting the entries relevant to not existing files: this way making the checksum to be actual would take much less time that other described manual workarounds:
1. verify existing content (and there is easy to find by log that there are only missing files errors thanks by different colors, but it can be also covered in status message: "only missing files errors found: [correct][synchronize][log]?)"),
2. delete missing errors
3. make "synchronization"

When I see how long synchronization takes if there are dozens thousands of files in the folder and only few small files to add I think that making (2) and (3) (or (1) and (2) because information about missing files is already known after making (1)) in one pass could save hours, not mentioning it will increase the HDD lifespan.

But it is still great piece of software: diamond (small only in size) I was lucky to find!

Thanks

In places where lots of files and folders are moving, makes more sense to use per-folder or individual hashing. ;o) Cor

fred - 17.11.10 3:24 pm

freddy was here and took your create software.

Geoff - 23.11.10 2:27 pm

thankyou for the software, im hoping it will be as you say, for that is exactly what it is needed, geoff.

cylentstorm - 24.11.10 8:17 pm

nice tool, odd site--thanks for both!

andler - 26.11.10 7:57 am

eaters

Rich - 30.11.10 3:35 pm

Bloody good!

angelnjj - 16.12.10 7:02 pm

Great...my only question is how to execute as part of an SSIS package - I need to generate a file and send it AND the checksum.hash to a vendor's FTP site...any ideas?

Also, is there any way to change the resultant extension to .ctrl instead of .hash?

Thanks...

doh - 23.12.10 9:21 am

blah

John - 23.12.10 5:50 pm

###### ** POSSIBLE VIRUS / WORM / TROJAN ***

I downloaded checksum tonight from this website and sent the two EXE files to VirusTotal

VirusTotal shows:
simple_checksum.exe contains a worm. 3/43 hits
checksum.exe contains a worm 4/43 hits

Maybe a false positive, as there were no hits from the "top" virus checkers that I consider
to be the best ones, i.e. none from Avira, Avast, AVG, Norton, Kapersky, NOD32, ClamAV, etc.

I think these are just false positives because of EXE packers used by the auther? Am I right?

Perhaps the author should disable EXE packing when he builds the application, there is no real need
to pack the EXE, and it has the potential to cause heuristic anti-virus to detect a false positive.

Does the author read this forum?
-- Cheers!

Kelly Clowers - 24.12.10 8:49 pm

I third the call for SHA-2 (AKA SHA2 AKA SHA-224, SHA-256, SHA-384, SHA-512).

MD5 is severely broken, and SHA-1 is now partially compromised as well. SHA-2 is not yet broken, but is seen as under threat, thus the development of SHA-3

Thanks!

Vahid - 28.12.10 8:41 pm

Love this one.
Small, Fast, Standalone and it Worked

thanks man

DrBunsen - 06.01.11 9:43 am

@Kelly Clowers: The reality is that the security of MD5/SHA1 doesn't matter for almost anyone using Checksum, so it doesn't matter how "broken" they are. We're not looking for absolute security, we're looking for a fast, convenient way to know if our files changed due to random corruption. Intentional corruption/manipulation can still be a problem even if a hashing algorithm is used that isn't as prone to collisions as MD5.

Take this as an example: Let's say that Checksum decided to support SHA512 to generate hashes with. If some bad guy comes along and changes a file, then couldn't they also change the value of the SHA512 checksum in the hash file? Sure, you could save the .hash file elsewhere to know that it didn't get changed, but anyone who really needs that level of security would almost certainly not be allowed to use a program like Checksum on their file systems. True security means knowing and approving all programs that can touch the data, and unless the programs were intensely tested and vetted, they shouldn't be used in high-risk environments. Checksum is about file integrity for the common man, not file security for high-risk environments.

In fact, I would argue in the other direction. I'd really like for CRC32 or Adler-32 to be an option since they can be calculated WAY faster than MD5. I don't care that my uninteresting files could be intentionally manipulated by bad guys to match CRC32 or Adler-32 checksums, I care about random corruption. The chances of a file being randomly changed such that it would still match CRC32 or Adler-32 is still extremely remote.

thomas5267 - 12.02.11 3:12 pm

Good job, but I don't see the Explorer context menu add on. Is any fix available?

JuJuBi - 13.02.11 10:16 am

Great tool thanks Corz

karman - 15.02.11 4:51 am

thanks is just what im looking for

Amir - 20.02.11 1:32 pm

When I double-click on "checksum.exe" I get a "command-line error" window that is too big to fit my notebook screen, which is only 800 pixels tall. A window with vertical scrollers and sized to 80% of screen height would do.

Hmm.. I thought that window was only 600px high, for that precise reason. I'll look into it.

Also, could there be options to save the file´s size, creation date and write date?

nope!

When you update a hash file, do you add only the newer files, or you recalculate the MD5 of files whose size or date has changed?

checksum adds hashes for files not already in the .hash file. ;o) Cor

Sandy - 21.02.11 6:31 am

Amir, Cor has a solution for that too: http://corz.org/windows/software/accessories/KDE-resizing-moving-for-XP-or-Vista.php

other-alphabetinator - 25.02.11 6:02 pm

First off, thanks for that awesome tool. It's doing all I've been searching for for years..

..except~ it doesn't seem to support unicode/UTF-8. When I try to hash files that are named with non-latin characters (east Asian e.g.) the tool simply skips the file.

If that functionality could be added I'm sure my new hashing-hobby would follow me in my dreams - in a very good way!

Thanks~ :p

hoosier - 26.02.11 11:44 pm

Ok, installed the app after checking the MD5 with my old hash reader but ran into a similar "command line error" window as the other user above when trying to run the full app - all I could use was the widget version. Figured the build might have been bad somehow so I tried to uninstall and the windows thought it was already un-installed. At this point the shortcuts and program files were all deleted. So, although I'm not sure of the reason, this build seems a little sketchy...

It sounds like you didn't complete the install. The "command line error" window is what checksum throws up when you launch it with nothing to do, you get that if you install it properly and do the same thing! That window will likely be renamed in the future, but it will still do exactly the same thing at the smae time! ;o) Cor

BinaryOutlaw - 27.02.11 5:23 am

I also would like the addition of more hash algorithms like sha256-512 and sha3 when it is available.

Cheers

gw - 07.03.11 5:20 pm

looking forward

Joe Blow - 28.03.11 10:09 pm

Any chance a command-line switch could be added to "ignore PE Header"? What I'm trying to find is a simple tool to compare all data in a .dll with another .dll - except data in the PE header (for .Net - the file version info and timestamp info).

dudung - 31.03.11 3:01 am

nice info...and nice site...

Good...I like it..

Thanks

mel - 31.03.11 6:08 pm

Thanks

Al Joker - 03.04.11 10:38 pm

I love it just simple and easy

pedros - 16.04.11 1:08 pm

thanks - just what i needed!

Big Al - 09.05.11 3:12 am

An education to be sure! I wanted to start teaching myself PHP and MySQL. The download sites recommend that you verify the signature before installation. Having never done this before I was at a loss. A web search came up with your tool. Very nice! Thank you and bless you for making this available.

RB - 23.05.11 7:59 am

Hi Cor -

I have been using your checksum utility and, while I like it, I still do not find it completely logical. An option exists for creating a one-file "root" checksum file in the root folder. However, this is not recursive ... if one goes down to a subfolder, the hash file for that subfolder only contains the hashes for the files in that subfolder (and not hashes for any files further down in the folder hierarchy). Currently, it is impossible to obtain that each folder in the hierarchy have a root checksum of its own except creating it manually for each folder. This is, of course, impossible for large hierarchies.

I suggest that a fully logical checksum should do the following:
if A = {B,C,D,{m,n,p,q,r}} where A, B, C, D = folders and m, n, p, q, r = files
then A.hash = Union(B.hash,C.hash,D.hash,m.hash,n.hash,p.hash,q.hash,r.hash)
RECURSIVELY.

So basically a folder's hash file collects all the hashes in the hash files for each of its subfolders and files, recursively.

This should be the base creation operation, or the default. Starting from this, one can add various negative switches to modify behaviour. For instance:

-i = would not produce hash files for individual files but still record the file hashes in the parent folder's hash file;
-f = would not record subfolder hashes in a parent folder's hash file;
-if = the current default behaviour for checksum.

The advantage of my proposal is that it would achieve completeness and full logicality while sacrificing none of the current options.

Best,
-- Ruber

You seem confused. Checksum either creates a "root" checksum with hashes for ALL the files in ALL the folder ALL THE WAY through the ENTIRE tree, OR it creates "folder" hash files for EVERY folder in the ENTIRE tree (containing ALL the files in THAT folder - deeper folders will have their own folder hash, and so on) OR ELSE it creates individual .hash files for EVERY file in the ENTIRE tree. If you want a root hash file AND folder hashes, you will need to do two hashing operations. And recursing is the default behaviour, also. Your "-f" switch is already covered, simply don't use the "r" switch! ;o) Cor

Non-roman characters - 23.05.11 6:29 pm

I also have problems with folders and files containing Asian characters. I have tens of gigs of files that can't be hashed because of this limitation. Are there any plans to fix this?

Grizer - 23.05.11 9:42 pm

I have no problems hashing non-roman characters, maybe it's your system.

Duke - 27.05.11 1:49 am

Vini - 27.05.11 10:28 pm

Simple and powerful tool. Does what i want.

Non-roman characters - 28.05.11 4:16 am

@Grizer

other-alphabetinator has the same issue. I'm running the latest version of Checksum on two different computers with Windows 7 x64 SP1. That's a pretty standard config these days so I doubt it's my system.

Erp - 31.05.11 2:47 pm

Hi,

first I'ld like to mention that I like checksum very much and that I detected some few incorrectly copied files verifying the destination (on more than one hardware).

Nevertheless I'ld like to request a feature (maybe I overlooked that it already exists, but I didn't find something appropriate):

I have several file structures looking like

folder1/binaries/setup.exe
folder2/binaries/setup.exe
.
.
.
folder999/binaries/setup.exe

this will result in 999 binaries.hash files,
all with the same name.

I am looking for some fail-safe feature, so that one can easily identify where each of the hash files belongs to.

(e.g. Anybody out there who accidently moved something with the mouse? ...)

Maybe there is a way to make hash file name creation not only consider the parent folder but one level more?

Or to include the path as a comment within the hash file?

But I'ld prefer not to use absolute paths.

Best, Erp

It's certainly doable, perhaps a new @token; "@parent", then we could have "@parent+1", "@parent+2", etc. I'll add it to my list. In the meantime, if you really can't use absolute paths, using the date and time tokens in the hash file name would at least give you some chronology. ;o) Cor

DrBunsen - 04.06.11 6:45 am

I, for one, truly hope that Cor doesn't follow RB's suggestion about storing the entire folder structure into a single hash file because there's too often when I move around folders. With the folders having their own hash file Checksum works fine in the destination. With RB's way I'd be having to re-checksum and/or manually editing hash files to take into account the moved files and folders. Checksum's handling of one file per folder is EXACTLY the way I want it to work.

However, I do have some enhancement requests, just in case you're feeling industrious...

1) How about storing the file size and data/time stamp in the hash file along with the file name? Then, when doing a verify, alert us to the files that were changed along with the current size/date/time stamps as well as the values stored in the hash files. That would help us speed up troubleshooting why the files are different, as well as help us look for backed up files with the proper size and date.

2) Almost always when Checksum finds a changed or missing file it's because it was intentionally changed or deleted. I appreciate that it found them but it would be nice if there was a nice way to automate updating the hashes in the .hash files after we've had a chance to verify that the new values are correct. How about this: When Checksum goes through and verifies files and finds a hash value that is different from what was stored in the hash file, rather than discarding that new hash information go ahead and save it in some way, like in the reporting HTML file, or maybe in a log file. Then have a special mode of Checksum that would read that information and allow us to replace the old/unwanted hashes with the newer ones that were found, as well as deleting the hashes of files that were intentionally deleted. I'd want to pick and choose the ones to update or delete, with an option to "select all".

3) I'd also like to win the lottery and have ice cream at every meal. And never get old or fat. And live forever. Please work on those requests as well.

Thanks!

Bunsen

Hankthornton - 22.06.11 3:04 am

Thanks

RB - 04.07.11 2:13 am

@DrBunsen

With regret, you did not understand what I was proposing nor what Checksum currently does. Checksum currently has the option of storing every single file hash in a unique "root" hash file. You may or may not be using this option, but it's there. As you correctly point out, this limits your flexibility if you start moving folders around. Checksum of course also has the option of creating a hash file per folder but this is limited to the files in the folder (it is non-recursive). What I was proposing was that Checksum enhances the hash-file-per-folder idea by making every folder's hash file collect all the hashes downstream (e.g. all the hashes of the files in its subfolders also, not only the hashes of its own files). It is a generalisation of the "root" hash file idea to every single folder. This way, your flexibility is enhanced, every folder being ready to become the root folder for a hierarchy of its own if you choose to extract it from the archived hierarchy and make it independent. Moreover, while giving you more options, all the existing options would be preserved as well, just perhaps activated by different switches.

checksum has always done this, it's called "recurse" (the "r" switch), every folder in the tree gets its own .hash file; simple and effective. ;o) Cor

gr - 10.07.11 5:28 pm

Love your product. Been using it a while now. Just sent you some money (sorry it's so trivial).

I have the same issue as Dr Bunsen. I am using Checksum to verify all my older photos. They go back 20 years and there are 53,000 of them in folders by year taken.

Although I do off-site verified backup of these old pictures on a yearly basis, I don't know if a few bits got damaged in one or more pictures so your utility is very helpful to me. If a file or files get damaged or lost your utility will let me know and I can then decide to first get a new hard drive (as I assume lost bits are a sign the drive is going), copy the files to the new drive, verify and restore all damaged/lost files from my backups so that future backups won't be backing up damaged photos.

The problem is that I occasionally edit or rename photos taken even many years ago. I also use your utility on this year's photos which are even more dynamic. I often go in and fix the dark photos, delete duplicates, etc. When I run your utility I get warnings about sporadic photos that I've edited, deleted or renamed. I have to check each one in the log, then rehash the whole folder. Often it's obvious that the file changed due to the date alone but we can't trust that. I guess ideally the utility should stop, pop up the file in a way that I can open it, and then an option to request that the file have its hash updated.

Dr Bunsen's suggestions are reasonable also.

I'm sure you could find another solution that would help this issue.

I'm thinking about this. Much more thought will be required. Popping up dialogs is fine, but what if 1000 files have changed? Ouch! And so on... ;o) Cor

sdfds - 15.07.11 1:57 am

This looks like an interesting tool. A few suggestions:

First, get rid of the mp3 playlist generation feautre, and make it in to a standalone utility. It's obviously completely unrelated feature-creep that has not place in a checksumming utility.

You are wrong; I personally hash all my album rips and create playlists at the exact same time. If you don't like the functionality, don't use it; it's just a switch.

Second, please allow the standalone checksumming utility to simply and directly send the checksum to the clipboard.. bonus points for not producing any other type of output, not even a window.. though perhaps a very brief "onscreen display" indicator that the checksum had been calculated would be nice to have as an option.

See "simple checksum", included with checksum. ;o) Cor

Finally, it would be good if there was an option to send the checksum(s) to VirusTotal and have the results displayed on a web page in the user's default browser.

mnemotronic - 08.08.11 10:27 pm

I would like a way to select 2 or more files in Explorer (using Win 7 64 bit), right-click, and get one of two dialogs:
"compared files and yes, they are all the same"
or
"compared files, and they are different. here are the checksums...."

I agree with previous poster about removing the MP3 player functionality. I like the idea about sending directly to clipboard.

simple checksum (included with checksum) already does ALL this, and more. Check it out. ;o) Cor

Kenneth - 09.08.11 4:46 am

I'm looking for a portable MD5 checker and yours is absolutely great. However it skipped all file names in Unicode. Wish to see a fix to that. Appreciate your work!

It works on all my weird file names. If it doesn't work on yours, PLEASE paste them here! (or better yet, mail me) ;o) Cor

Jinx Dojo - 14.08.11 7:17 pm

This is by far the best candidate to replace the many random checksum generators out there. The unified hash idea is a great one, and checksum's context menu and options dialog makes creating hash files much easier.

However, there are still quite a few issues that will impede checksum from taking over:

1) It is not open source.

1a) While I understand that Corz deserves some contribution for his work, I think that the futures of author-driven development tend to go defunct. Open source ensures the project can continue if the developer loses interest (as is the case with so many such programs).

This isn't going to happen any time soon, sorry. (pretty much everything else I've done has been open-source, enjoy!)

1b) Additionally, open source is the only way to create an open standard for the unified hash file. Currently, there is no indication of the type of hash provided, and it must be chosen based on length. There must be a standard to indicate each type of hash (such as the "urn:sha1:" sequence). Of course, backward compatibility can be maintained by also simultaneously generating regulard md5/sha1/sfv files. The ".hash" file needs an expandable standard.

By length works fine.

1c) Cross-platform capability. Open source could help to create cross-platform versions of the software, which will promote the standards it creates.

I created a Linux beta version some time ago, check my devblog.

2) Not enough hashing algorithms. The unified hash file is a great idea, but without more hashing algorithms, it doesn't serve nearly as much of a purpose. FSumFrontEnd provides plenty of algorithms, but has no context menus and is not being actively developed. Checksum could use Fsum to obtain further algorithms.

This is file hashing, not file encryption. SHA256, maybe SHA512 will find there way into checksum, but I'm not going to get silly; there's simply no need.

3) Context menu customization. Cascading context menus are a must. In addition, this would allow the user to select the hash algorithm (or group thereof) from the menu itself (a la hkSFV). My personal dream is to be able to setup a custom group of hashes so that I can right click, select checksum for a cascade, and select "Create SFV/MD5/SHA1/HASH" to create everything necessary as defined by the group (i.e. create all of them simultaneously).

We also still need that divider fix.

Surely no one enables the divider!

There are many other suggestions (some in these comments, some I have reserved in my brain), but these are the ones I feel will most affect Checksum's adoption as the premier hashing client. Please consider all of this and feel free to e-mail me.

I really do appreciate your work on Checksum and hope it can be developed into the best hashing client. Thank you.

Thanks. I believe it already is the best! But worry not, there's more to come. ;o) Cor

skippideedoodaa - 17.08.11 1:39 am

This is nice software, but it hasn't been updated since 2009. It needs to be open sourced so development can continue, especially on more than just windows.

menow - 19.08.11 6:18 pm

Just want to try it out

Disappointed - 26.08.11 3:16 am

The uninstaller in Win 7 does not work at all.

Areyal - 28.08.11 9:02 pm

Hi all,

I'm very impressed with this program.
I was looking to check my files before I do backups or copy and this is a ideal tool

If CHECKSUM could alert about which files not only have changed but also which ones have changed and still preserve the same modification DATE they had when hash files were created, this would be the only tool against silent data corruption.

This way we could know which files were corrupted by physical drives failures or virus, and so these files could be repaired from a backup copy.

PS. All was Ok with installer in Windows 7 64 bit

I have been considering ways to incorporate this sort of functionality into checksum; something like adding a comment line along with each individual hash with exactly this information seems to be the best way forward (other hashing programs would ignore it, one hopes). Of course it would add processing time at each end so would definitely be optional. ;o) Cor

Ryobi - 29.08.11 9:25 pm

PLEASE don't remove the playlist feature. I use this every day. Thnx!

Don't worry, it's here to stay. ;o) Cor

Phill - 02.09.11 7:31 am

Jolly good ware. Been using it for a year and a half now, now my downloaded programs only crash if they have bugs.
Also the GUI matches my shirt.

I actualy modelled the GUI on your shirt. ;o) Cor

Jeff - 03.09.11 8:43 pm

09/03/11 - McAfee reports that hashDROP has the Artemis! trojan virus

Rich - 14.09.11 9:34 pm

Do you by chance have an application hash repository of known good hash files/applications? We're looking to add to ours and are interested in finding other sources. We typically prefer the hash generated directly from the publisher for provenance reasons, but we also gen hashes from other sources and simply give those a lower rating, etc. Anyway, if you or if you know someone that has a hash repository, please send them my way. We're happy to compensate accordingly.

I don't, but I'm pretty sure most of those virus checking sites do (i.e. virustotal.com) ;o) Cor

problemreporter - 18.09.11 10:00 am

Don' work on file with this russian name:

Португальский.djvu

but still a very good hash application though. I'm also "forced" to write my own hash application for some of those "small" problems.

Thanks for the heads-up, I'll look into it. ;o) Cor

Jon - 04.10.11 9:12 am

Doesn't work. Windows 7 32-bit. No right-click context menus.

KenK - 24.10.11 2:38 pm

This program is great. I love the unconventional flexibility.
I have a massive collection of files (over 8tb) and needed to keep tabs on it.
- Anything go missing or get corrupted?
- Do my backup copies match original? Easier to transport and compare checksums than compare 8tb over a network.
I wrote a fancy BAT file that looks for errors and adds in new files. It reports overall success via HTML formatted email. I only used this program, sendEmail and the BAT I wrote.
Big question: Do you have a list of the ErrorLevel's you used in checksum??? It's great that you used return codes so we can differentiate conditions so I can decide what is a problem or not. But without the definitions I can only create problems and capture the return code. I'm sure there are MANY more I'm missing.

There is no published list of the codes at this time, so here's the exit codes for the current (1.1.4.0) version (there have been a few added/changed in the next version)..

-9 = cancelled out of sync/options dialog
-5 = nothing to do
-2 = there were verify errors
-1 = checksum.ini is missing or.. read-only media was encountered
(initially, this was the only non-success exit code)
0 = normal exit
1 = attempted to recurse a regular file
2 = nothing to check
3 = asked to verify a non-hash file
4 = checksum launched with no parameters
5 = process already running (and disallowed in checksum.ini)
6 = asked to hash a non-existent path

I realize they are somewhat haphazard, hopefully the next version will see them attain some logical order. Have fun!

;o) Cor

VorLon - 31.10.11 3:27 am

Hi Cor,

Just like to say that I'm still using CheckSum regularly and the small sum I paid for two licences has to be the best software purchase/s I have ever made.

Checked out your blog (last one March 2011, I think). CONGRATULATIONS on the new edition to the family.

Always look out to see if you have come up with any new software gems, but appreciate that you must be mega busy at present. All the best mate.

Vor

P.S. @Jeff (above). If you downloaded CheckSum from this site, you will undoubtedly find your AntiVirus software product is generating a "False Positive". This means it is reading the Checksum code as something malicious when it is Not.
If you want reassurance I suggest yo head over to VirusTotal.com http://www.virustotal.com/ where you can upload the whole checksum disribution zip file (or seperately) and allow 40+ (last time I checked) up-to-date current market AntiVirus Scanners to check it. All the market leaders are there, ie Kaspersky, Norton and so on.
You will find that most of the AV products find the file/s CLEAN and often if there is a query it will be of scanners using the same scanning engine skewing the results.

Thanks for your kind words, VorLon!

And yes, with two extra mouths to feed, my time is somewhat limited! But be assured, checksum is not forgotten! ;o) Cor

bry - 16.11.11 2:44 am

Hi Cor, May I ask if can I exclude a file here lets say for example. I want to Hash Folder1, i have 5 files(a,b,c,d,e files) iniside in it.. but I want to exclude 'c' file in comparing. Is it possible? Thanks..

Firstly, I'll disregard the bit about "comparing"; for that you want two files and "simple checksum" (checksum's wee drag&drop brother, which is installed along with checksum).

For excluding your "c" file from the regular checksum process, there are two ways..

If this is a one time deal, simply hold <SHIFT> when you launch checksum to pop up the one-shot options and use a (standard Windows) file mask that includes everything except the "c", in this case: a,b,d,e

If this "c" file is one you always want to avoid, or want to avoid for a great many checksum tasks, drop it into your ignore_files preference inside checksum.ini..

ignore_files=desktop.ini,folder.jpg,.desktop,.directory,thumbs.db,c

;o) Cor

Pat - 21.11.11 8:09 am

Hi Cor, I would like to know if it's possible to have a log for all the hash values of the files of main folder to hash even files inside the subfolders.? for example Im about to Hash the Main folder that includes 2 subfolders. each folder have 2 files. After i create hash.. there will be a log in Main folder that will list all the hash values of Files inside Main folder and also the files inside the subfolders.. Thanks Cor..

.. and all the subfolders inside that and so on, all the way through the tree. Yes! checksum's default behaviour is to create or verify ALL subfolders. Once installed, you can right-click and go!

You can also choose to have those hashes stored..

• in one big "root" .hash file containing ALL the hashes
(in the root, this behaviour sounds most like what you are after)
• in a single .hash file for each and every folder in the tree.
(containing hashes for all the files in that one folder - this is the default behaviour)
• in individual .hash files, one for every single file

Hold down the <shift> key when you launch checksum (from your explorer context menu) for lots more options.

Have fun!
;o) Cor

ps. the new beta is almost ready

Pat - 23.11.11 6:46 am

Thanks Cor.
Im really enjoying using Checksum.
More power to you..

opera - 27.12.11 3:32 am

Hi -- downloads of the checksum files using the browser Opera 11.60 (32 bit) under Windows 7 (64 bit) are incomplete:

12/27/2011 03:20 AM 3,076 checksum.zip
12/27/2011 03:15 AM 3,094 checksum_1.2b.zip

Version information
Version
11.60
Build
1185
Platform
Win32
System
Windows 7
XHTML+Voice

downloads using the browser Firefox Nightly 12.0a1 (2011-12-26) are complete and functional

12/27/2011 03:22 AM 1,094,829 checksum.zip
12/27/2011 03:22 AM 1,176,397 checksum_1.2b.zip

If you throw the failed "zip" files into a text editor, you will probably find they are, in fact, web pages, most likely explaining what went wrong with Opera. I'd like to know, too. ;o) Cor

MultiPar - 04.02.12 8:20 pm

MultiPar can verify and repair damaged files, and even restore lost files. It's not as fast as corz checksum for some things, so if you just want to do a quick verification, checksum might be better. <snipped>

Puleez! This isn't the place to advertise other software. ;o) Cor

Robby - 04.02.12 8:36 pm

Hi,

I just start using checksum and I have some hints for further improvements:
-when synchronizing the hash file it seems for big hash file that only one CPU is working (25% CPU) for quite some time. Maybe using multiple CPUs e.g. split hash file into parts, would be helpful

I/O is the bottleneck, multi-threading isn't going to help. Splitting the file into parts slows I/O even further (repositioning the drive head takes time).

-when verifying or calculating the hash file only the number of files are displayed. It could helpful to have also the size displayed since for hashing large number of files with different file sizes the number of files does not say much for the time left.

Gathering this information is too costly when hashing many files. I find not watching boring tasks also helps.

-When the process is hashing/verifying a large file the right click on the task icon does not work or has a big delay

Yes, checksum is geared to just getting the job done, returning the control back to the user only between files. Try the break key if you are in a real hurry (v1.2+), or do it when hashing small files, instead.

-I'm missing a pause menu. How to stop hashing and start later? Is the hash file complete when I "exit"?

No, there is no pause item, your installation is fine. The break key will act as a pause if you need it (v1.2+). And yes, when you exit, so long as something was hashed, your .hash file will be closed just fine. Otherwise there is no .hash file.

One other suggestion would be to have a service which automatically hashes in a root hash file when any file is stored or updated on a particular drive. This would be very helpful to have an up to day hash file especially for a drive which stores only data (for sure not a drive for operating system).

That's been on my wish-list almost since checksum was created, some kind of "agent". It would be a lot of work, though. Maybe if someone pops for a 250 user license I could take a week.

Nevertheless this is a very helpful tool and very fast.

Thanks. Note: feature requests are best put on the tricks&tips page. I should probably make that more obvious. But constructive comments are always welcome, wherever they are. ;o) Cor

Robby - 05.02.12 12:00 pm

I/O is the bottleneck, multi-threading isn't going to help.
In my case I have checked the disk access in background while synchronizing and it took some minutes without any reasonable IO access but the CPU was on the limit at that time (25% at quadcore).
Maybe due to caching.

Indeed, caching could be a factor. Reading new data, it's unlikely even the fastest drives could outpace a modest CPU.

On a side note, I noticed (hunting some C++ documentation) that there is a flag one can use to force disk reads to not use caching, always fresh reads. This may appear in the next version of the hashing DLL, at the expense of checksum appearing slower in certain situations. Comments welcome. ;o) Cor

Gathering this information is too costly when hashing many files. I find not watching boring tasks also helps.
Ok but hashing over 6h (in my case) I would like to have an estimate if 6h or some more hours since my PC is not running 24h a day. Nevertheless speed is much more important then this info.
Is it so much costly just to sum up the file size from the file just hashed?

Not for just one file, no. But when lots of files are involved, it's a different story1. You are not the only one to request this, and a few things have been tried. While I haven't found anything satisfactory enough to become the new default, future versions will likely incorporate some optional alternative methods. Hey, at least the current system is accurate!

;o) Cor

references:
1. To give you an idea, open your system drive at its root in explorer, select all and do <ALT>+<Enter> (properties). It's not a quick process - I could write this entire reply a dozen times in as long as it takes!

penguin211 - 08.02.12 10:44 am

For information.

I downloaded checksum to try as it looked ideal for me. Whilst it worked fine on the first two files I tried, it failed miserably on a file size of 5,197,092,864 bytes. I ran it twice on the same file and got two different results (!), both of which were not the same as the published checksum for the file. When I searched for and found another utility, it gave the correct checksum (consistently). I downloaded another copy of the same big file and the results were the same.
So checksum is not for large files, it seems.
This was using fully updated Windows 7 (64-bit), by the way, running with full administrator's rights.

This was a known bug, fixed in v1.2.

For more of this sort of information, check out checksum's version.nfo, link at the top of this page.

;o) Cor

user - 04.03.12 9:10 pm

great prog buddy! it is possible for it not the change/update the "last modified" date for the folders?

Yeah, don't use per-folder hashing. In other words, create a "root" hash somewhere above the folder in question. ;o) Cor

Loco - 12.03.12 3:48 pm

Do you have a ETA on the release of version 1.3?

Hopefully this month (March) ;o) Cor

ps. please note, you do not need to enter an email address to post here, especially a fake one.

Nope - 18.03.12 7:11 pm

When you charge for something, that should be UPFRONT.

I'll use the similar FREEWARE, thanks very much.

Licensing link at the top of this very page.

Also, you can use it for free for as long as you like. Quit bitchin.

;o) Cor

RGM - 23.03.12 6:46 pm

G'Day,

*LOVE* Checksum for Windows... good & brilliant work - Many thanks. Any hope of a version for OS X? The world needs it.

PS: I appreciate you sense of humor, and applaud your restraint.

Cheers,
RGM

My Mac died years ago, so an OSX version of checksum, at least by me, is unlikely. However..

You may have noticed the modern checksum release contains (in the extras/ folder) a Linux version. This wouldn't be too difficult port across, the underlying tools are the same and it's pure bash. The optional GUI bits should easily find Mac equivalents. Most of the main checksum goodies are there, and it's GPL licensed, have fun!

;o) Cor

Thomas Li - 28.03.12 2:40 pm

Hello corz,
A year ago, I post with the name thomas5267, look for me!

I'll believe you!

Firstly, if you are still loving JKDefrag, you should try out MyDefrag, it is great!

OK

Secondly, the right click menus is still not working, I cannot find any registry entry about checksum in both HKCR\Directory\shell\ and HKCR\*\shell\, fix needed.

No fix required at this end. When you say "Not working", you will need to be more
specific. Or else try reinstalling.

Thirdly, can I be a beta tester?

Lastly, do your website send a email to the replier (reply-er) to notify that the comment has been replied, if no, add it!

My dev copy does, but it's not 100% yet. Sadly paid-for work takes precedence these days, so who knows when that might appear onsite.

My System Spec:
Windows 7 SP1 64 bit
No registry protection AFAIK
Drivers not up to date, but not crashing

Probably not relevant:
GIGABYTE GTX560
Philips 244E2
Gigabyte P55A-UD3
Acbel 380W Power Supply
Epson CX5900 LOL!
WD Harddisk
2x 2GB Kingston KVR1333D3N9/2G

Correct, it's not relvant. ;o)

Thomas Li - 28.03.12 2:47 pm

Sorry for consecutive posting as this issue has to be emphasized. Your website is saying that I am hammering your server because you have set the auto-redirection time too fast.

No, that's not the reason. The redirect is 5 seconds, the anti-hammer, 0.5 seconds. Maybe your browser is incorrectly handling the refresh.

That said, I'm woking on an AJAX version which doesn't need refreshing (see previous post for timescale on that)

Yes, I am using Google Chrome.

PS: I decided to revenge so I post this instead of editing my previous post.

Fair enough. ;o) Cor

Thomas Li - 29.03.12 3:15 pm

Hello corz,

It's cor. This is cor's org, geddit?

Answer this question first, what do you do for living?

corz.org

OK, now I will elaborate on the right-click menu issue.
It doesn't not appear in the menu. Neither when the mouse is pointing to a directory or a .exe. Yet double click on .hash files still verify files.
Run with elevated privilege alone or together with XP compatibility mode doesn't help either.

You don't need special privileges or compatibility modes to install checksum. If you haven't already, uninstall and then reinstall checksum. Or just reinstall.

Alternatively, see here for some registry files you can merge yourself.

Then answer this, how can I donate and have a beta version? I would like to have a shirt but shipping to HK is too expensive.

Check the licensing page (link at the top), you can also get a license the old-fashioned way, and for only £5.

EDIT: NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!! The redirect thingy is being misjudge as DoS...

Huh?

;o) Cor

Thomas Li - 30.03.12 6:21 am

Hi corz cor, (Haha not funny)

Cor, where do you live in and whats with those mung-beans, Tahini and Lea & Perrins.
A embarrassing question, are you a gentleman or a lady?
I have donated and gimme the beta checksum! Consideradding the soon to be announced SHA-3.

This isn't the place for chit-chat.

Mail me!

;o) Cor

M L van Wyk - 10.04.12 12:31 pm

We downloaded the software but after all the people on Helpdesk and even our system people tried to install it we couldn't get past the error:

there was an error registering the zipper dll. We then followed the instructions to give everone access to the zip fil and registering it manually. But it still didn't work. It then proceeds to give the error message that the
ATL dll can't be found.

Please can you help. It seems the installer doesn't work correctly.

Firstly, "ATL dll cannot be found" is nothing to do with checksum. It seems your organization has a software problem. It's outside the scope of this response to go into it. Google "ATL dll cannot be found" for solutions.

As for checksum.. Someone once mailed me about this error, then they mailed back a few minutes later saying they had uninstalled and reinstalled again, and it everything worked. I did not get any more information on the error, no OS details, nothing; much like your report. Anyway...

Then ensure you don't already have the corz installer files installed in the shared user folder, and being used. And ensure the checksum installer isn't already running on the system.

Then try running the installer as an administrator, if you haven't already.

After all that, you don't need to use the installer's unzipping mechanism, you can unzip the files yourself, right where they are and edit the setup.ini to use a raw install, change..

archive=files.zip

to..

archive=files

(FYI: checksum.exe et al will now be inside checksum/files/files/)

Then run the installer as usual.

Alternatively, simply unzip the files and drop them somewhere, for a completely portable install. The installer was always optional, and most likely soon to be deprecated.

En-Joy!

;o) Cor

Stilez - 10.04.12 1:35 pm

Hi,

I'm looking for a replacement for my current folder hashing proggy. I'm running win7 x64 on a LAN and the old proggy seems to have issues somewhere. Could be with large files (30 - 70 GB), or handling long filenames (all those files whose backups end up in \\servername\Andy's files\backups\2012.todays.date\original path+file name) whether checksummed across a network via a share or checksummed locally. Folder sizes are up to about 300k - 800k files. Sadly the end result was the number of files per hash output and number of files per "folder properties" were never the same with old proggy. I couldn't work out if it was because of large files, long path/filenames, network v. local use, or large numbers of files, or some combination. Great when you're trying to verify backup integrity and want it to "just work" ;-)

So here I am looking for new proggy!

Seeing you have a friendly FAQ and blog thread and Checksum looks actively developed, I thought I'd ask how Checksum handles these things. Also anything else you reckon's worth knowing

checksum should handle everything fine. I'd advise you use "root" hashing, though (one .hash file in the root of your backup) to avoid PATH length issues. ;o) Cor

Holger Ohmacht Biebergemuend - 11.04.12 12:39 am

Hello!

You want(ed) to write the best hashing programm? So it would be great to implement the Tiger Algorithm (the latest algorithm) and the other algorithms ;-) (BTW md5 is already cracked - by super computers and distributed computing)

Nevertheless good programm and great motivation!

Thanks, but none of this is news (see the algorithms page), but we're talking about FILE VERIFICATION. Even MD5 is overkill for 99% of situations. I'm more likely to add CRC32 than the latest-greatest-most-secure-alogithm. ;o) Cor

Stilez - 11.04.12 3:03 pm

No go, Cor, can you recheck things.

I used checksum on a local folder and it missed out all files with path+filename length > 257 which DIR /S listed.

More detail:

Windows 7 file server has a folder "X:\F" with ~358k of files. Folder properties and DIR "\\?\X:\F /S" both agree the folder contains 358291 files. Hidden and system files as you can imagine are always visible (and entire drive was ATTRIB -H -S to make sure). Checksum used with a single .hash file and absolute paths selected in checksum.ini (can email you the ini file if you like). Checksum started locally on the file server, using right click of folder in Windows explorer. Status popup built the file list then stated it was on file N of 358291 (as expected!) so we know it's reading the number of files correctly. When I opened the .hash file it only had 357720 files listed in it though. No errors or log file, checksum reported successful completion. The culprit turned out to be that the 571 files with full path+filename length > 257 were nmissing in the .hash file (I can't tell if they actually got hashed or not).

Hope this helps you to figure what's up, it seems reproducible (same effect on 2 other disks on file servers here).

If the PATH is so long that windows can't read the files, neither can checksum, which relies on the windows API. Most programs will have problems with them, in fact, including Windows Explorer (the main reason not to do this). It would be a good idea to alter your backup strategy. I'll look into the error reporting. ;o) Cor

Stilez - 11.04.12 6:00 pm

Didn't seem to be a problem with Windows - then again I used \\?\X:\.... rather than X:\.... for the DIR reports which apparently causes Windows to use the long filename API. I didn't check whether checksum would have worked if it was given a folder in that format as well - I should have checked.

What was curious was that checksum got a full correct folder count when building its file list, it just didn't create a line for the hash of each. So it obviously did use a Windows API that got the filenames even on long paths first time, then didn't use it second time. I gather there's a proper API for long filename access that guarantees file reads will be done using the API that handles 32k path length - maybe make Checksum use that API when it's hashing? That seemed to be all that it wasn't doing.

I did spend some time, a while back, playing with these sorts of hacks, but the results were unpredictable (the prependment actually causes windows to miss some files). Very few programs can fully access files beyond the (admittedly stupid) windows PATH limit, so hashing these same files seems almost as daft as creating them in the first place.

It would be great to not have to think about it, but we'll need to wait for a better version of Windows to appear. I can't afford the time involved in creating a workable solution for current Windows versions, assuming it's even possible, and you guys aren't paying for it, are you? ;o) Cor

Stilez - 11.04.12 6:04 pm

One functionality request :-) the dialog that pops up first time or when "shift" is held down .... can we have a button on it for advanced options so that location to put the hash or other options can when needed be set case by case? Just asking!

Quite a few new features have been added to checksum since the last time I was messing around with the options dialogs. A few of these features will need to be added, including output location, when I can get to it. In other words, it's already on my 2do list. ;o) Cor

Stilez - 12.04.12 1:29 am

up & coming newness? Yay!

One simple "sort of fix" for the long path thingy would be if checksum could somehow detect if long filenames were likely to have affected the checksum output, and notify the user if that's likely, so at least the user has some heads-up.

Also the eventual replacement for NTFS (ReFS) is said to handle paths and filenames of 32k and as a "ground up" design it would be surprising if it didn't get this well-known issue right. No guarantees though... it's the Windows team ;-)

Technically, NTFS can handle long paths just fine, it's Windows that chokes on them. As for newness, always that, see here. I'd hoped to get the latest beta out a couple of weeks ago but have been too busy, and the site has eaten up all my spare coding time. Soon though. ;o) Cor

Steve - 14.04.12 10:09 pm

I googled the md5 hash for this zip file (7024ccb56480d868b82127e53bdb7a6e) and it was flagged by 4 antivirus programs.

https://www.virustotal.com/file/1471876c79d7b4ef0ca1b9ff1ce9b2035cd836192046fd99e23fba8fafd7dafa/analysis/1332082386/

Wow! Google, eh! What technical mastery!
Enjoy your delusion, Steve! Try not to be like those four A/V.. Brain-Dead.
;o) Cor

Foyo - 22.04.12 5:37 am

Do I need a license if I am only using Simple Checksum?

No. simple checksum is and always was free. It won't ever ask for a license, either. ;o) Cor

Jay - 21.05.12 4:30 pm

Some feature requests:

add a option to remove file hashes for missing files from the *.hash file. These show up as errors but are mostly noise. The report makes no differentiation between missing and damage and i have to look one by one. As i rename and move files around constantly, this situation is very annoying.

PLEASE read the version.nfo before requesting features. You may (will) find that the next version already contains them!

Add expand all nodes to the report file.

Add word wrap to the tooltip. They are divided in logical parts, this is how would it show up in three lines:

And be three times bigger. This isn't going to happen, though, as mentioned elsewhere, I aim to eventually have that window toggle to a full-size scrolling list for people who simply must have this information (and can read at lightning speed).

creating checksums: [folder: n of m] [file: x of y]
drive:\path\
hash filename: hash value

Right now they are too long and as i use the taskbar on top everything is covered and some of it isn't even legible because it goes beyond the screen limits. I known that i can move the tooltip around but i want it on the top of the screen.

Maybe use a smaller font?

Thank you, this program is a very useful and well thought out application. I wish all applications like this. Doing one and doing it well.

Thanks! If only everyone who thought that got a license!

Note, feature requests go here. ;o) Cor

Jay - 22.05.12 3:32 pm

Thank you for your answer. Even if it was only to show condescension.

That was not the intention. I'm sorry if I offended you, it was at the end of a long day.

add a option to remove file hashes for missing files from the *.hash file. These show up as errors but are mostly noise. The report makes no differentiation between missing and damage and i have to look one by one. As i rename and move files around constantly, this situation is very annoying.

PLEASE read the version.nfo before requesting features. You may (will) find that the next version already contains them!

This is what the "version.nfo" says: You can also now choose whether or not to report (and log) missing, changed, or corrupted files.

Which is not the same thing. In cosmetic terms might be, but not in practical terms. The hashes of the missing files would still be in the *.hash file. The more "moves" and "renames" the worse it would get. Removing them is the only logical solution, not hiding them.

You stated you were concerned about noise. Problem solved. Deeper solutions are in my 2do list, including your request (see comments, above).

Add expand all nodes to the report file.

Again you didn't read. My suggestion was to expand all nodes. Right now clicking on the title only expands the first level.

The only explanation is, the Javascript engine in your browser is broken. Or perhaps your logs don't have multiple entries on one date, or something. I can assure you, all levels are expanded, and you can see the individual file errors. There are no more nodes! See the example here. Full instructions are also included in the pop-up tooltips (hover your mouse over things). If you mean something else, let me know.

Add word wrap to the tooltip. They are divided in logical parts, this is how would it show up in three lines:

creating checksums: [folder: n of m] [file: x of y]
drive:\path\
hash filename: hash value

Three times bigger, but would cover less than 5% of the screen and would only be there for a small amount of time. This would be a option, if users wanted to cover their screens completely with the tooltip what would it matter to you?

But your objections makes no sense. My suggestion would make the tooltip more readable with very little side effects. Semantically and logically separated information. Three lines. 2 more than now.

I may have been hasty, it's not such a bad idea (considering the rest of your comment). I'll probably even add it to the 2do list (which I don't publish here, because of space limitations)

Your "solution": scrolling text is, even according to you, a bad "solution"!

As for using a smaller font is not a option. Neither for long text since the font is already small as can be, nor for organizing the text.

Your eyesight must be quite poor, and I do apologize for ignoring this possibility. No one has mentioned it, in fact usually the opposite. With a maximum path length of around 256 characters, even a "normal" sized (for me) font wouldn't fill my screen. I'll certainly consider the three-line thing if you think it would help in your situation.

I should perhaps add, if you are a new checksum user, it can sometimes take a while to get over the wow factor in the way it works, and the tooltip only compounds this. After a time, you may just disable it altogether, happy in the knowledge that things are getting done. In the upcoming version, a left click on checksum's tray icon will momentarily display a hidden tooltip, which is a nice compromise.

I provided useful feedback after careful reflection. I'm sorry that you think that the users of your programs are all morons.

Wow, that's an incredible leap which I will not (con)descend to comment upon! Thanks for the feedback, though.

;o) Cor

ps. you know you shot yourself in the foot, posting "Some feature requests: …" on totally the wrong page. How am I supposed to take whatever comes next? You clearly didn't read my lovingly crafted text output, but expect me to read yours. Many of the checksum users that I've communicated with are a lot smarter than me, but with a start like that, I didn't count you among them.

bry - 28.05.12 9:16 am

Hi Cor,

May I ask if it's possible to not include a specific folder and all it subfolder and files in hashing? Thank you.

Yes, check out the ignore_folders preference in checksum.ini. ;o) Cor

MP1 - 21.06.12 3:21 pm

Hey Cor,

I just installed your program for the first time - looks exactly like the thing I need for my external backup HDD. Only I have problems using it with big font settings in windows xp (220% dpi setting - connected to a tv) - the gui is messed up (does not adapt). Using the screenshots from the website I can deduce the functions and hotkeys so that I'm able to use it - nontheless it would be great if you could make the gui high+low dpi ready.

Thank you for the program,

MP1

I'm gonna have to start an accessibility section in my 2do list! Thanks. ;o) Cor

Eric - 29.07.12 3:45 am

Very simple question that I can't seem to figure out. How do I use checksum to verify the SHA1 of a disc in it's entirety, ie, one checksum for an entire physical CD/DVD. Right clicking on a drive D:, for example, produces a hash for every file on the disc, which is not what I'm looking for. I just want one number to compare to the ISO file's hash.

See here. ;o) Cor

Phil - 02.08.12 11:47 am

Is it possible to amend the comment block that appears at the top of each hash file? If possible we'd like to include a link to our own organisation and some extra text.

I know it's possible to manually edit the file after it's generated but I wondered if it can be done automatically when the file is created.

It currently is not possibly, though it's already on my 2do list for the next version (from an email request) ;o) Cor

Yubs - 14.09.12 9:07 pm

Hi There,

First off, I love checksum (and simple checksum), excellent work.

I was wondering if you could comment on the reliability of interrupted checksum operations.

I've been using checksum to verify copies of backups I am making. In total, I'm running checksum on 1.3TB of data located on a server which I'm connected to by gigabit LAN. As you can imagine, this takes awhile, which is understandable, but unfortunately the new system I'm running checksum on (not the server) seems to be crashing and I have to restart the checksum procedure. This (finally) brings me to 2 questions:

(Q1) I've been using the "synchronize" option as a sort of 'resume' feature. Am I correct in thinking this mode will not re-process checksums for files that were processed before the system crashed?

That is correct. Using synchronize as a "resume" is smart thinking.

(Q2) If checksum is interrupted during the processing of a file, would it have recorded an intermediate result to the .hash file that is incorrect? If I was correct about Q1, that would mess up my use of 'synchronize' as a 'resume' method because checksum would think the file had been processed when really it hadn't completed. So are the checksums only written to the .hash file AFTER the target is 100% processed?

Absolutely. Only when file hashing is complete (in memory) is the result appended to an existing .hash file.

Any other tips on how to recover from an interrupted checksum job?

If it's from a system crash, just the usual stuff, always check your disks before continuing being the most important. And prefer file systems with the ability to rewind, like NTFS or most common Linux file systems.

If it's only checksum that's interrupted, there's nothing special to note; aside from choosing synchronize, which you got.

Thanks again for making such a great tool!

;o) Cor

Matt - 01.10.12 7:01 pm

Any news regarding CRC32-implementation?

Thanks!

It's not expected any time soon, but is on the 2do list somewhere.

;o) Cor

checkercab - 16.10.12 3:20 pm

Windows XP SP3 portable mode checksum 1.2.3.9 and simplechecksum ignore the following checksum.ini parameters:

Most of the ini parameters only apply to checksum,. not simple checksum, like these...

unified_extension=false
Should produce .md5 output file extension instead of .hash with checksum.ini parameter algorithm=md5, but does not. Other hash file checkers are incompatible with the unconventional .hash extension.

That would be a first! Are you sure you are editing the correct ini file?

checksum's <Shift> dialog still defaults to true.

That preference is to disable the beeping on hash errors, nothing else.

The output hash file #(pound sign) comment prefix is incompatible with other hash checkers which expect the conventional md5sum format ;(semi-colon) comment prefix, notably FileVerifier++ 0.6.3.5830, hkSFV 2.0.1.84, and ilSFV 1.10, likely many others, though not MD5 Checker 3.3.0.12. My Windows' system language is English-US, Windows' other language tabs are their original defaults.

The next version of checksum will give you the option to disable the comment altogether. I'll add a semicolon option to checksum's future preferences. Most applications that handle ini files can accept either format.

Checksum's dialogs are microscopic on 1280 x 800 laptop screens even at 120 dpi scaling -- you so obviously have a gargantuan monitor, maybe two!

Nope, just the one. And my laptop's resolution is smaller than yours, I haven't noticed any problem. I do plan to add some options for visually impaired (see above). Note, 72 DPI is normal for screens. Try that.

The file drag and drop paradigm is unwieldy, as it requires either two Windows Explorer instances or a third-party dual pane file browser in portable mode, or a lot of unwelcome gymnastics in conventionally installed mode.

checksum is not designed to operate with drag and drop, though it is quite doable I almost never do. The context menu is the best place to access checksum's features, or if you prefer, the command-line.

Thanks for the feedback.

;o) Cor

Juan - 23.11.12 7:26 pm

Great program.
Thank You

Richard H - 15.01.13 1:04 am

I like this program so far. I'm a beginner at using checksum to verify my stored data.
Whenever I would burn data to cd or dvd I would at least check that the "properties" could read the
data "size" and "size on disk". But from now on I'll store checksum values on the disks along with the data.

puzzled user - 27.02.13 7:12 am

I have some foreign language (korean) folder and file names. Checksum doesn't work for these files. It simply ignores the files or folders and can't find anything to checksum.

yet you mentioned it can handle foreign languages as well, so quite puzzled if it's just my computer...

Well, it depends on the languages. The upcoming beta handles foreign languages better. If you are a licensed user, you can play with the new beta, just mail me. ;o) Cor

indigital - 28.02.13 11:44 pm

Hello.

I recently run into the following critical error (dialog field):

"Hashing Library Error!

I couldn't open the hashing library..
c:\bat\hash.dll

Perhaps it could not be saved in its specified location"

It appears and no hasing is done. I noticed however, that the hash.dll under c:\bat is created and is left there even after the program termination.

I should add that I run Windows 8, but I'm damn sure checksum has worked here before.

Any thoughts? Thank you!

indigital

Damn that abomination of an OS! Yes, it should work on Windows 8, though you will probably want to install it as an Administrator. It sounds like you have permissions issues in checksum's (portable) location. ;o) Cor

Dario - 01.03.13 3:27 pm

Is the function "Find a file with specific hash" supported ?

No, nor is it being considered. However, it would be trivial to use checksum for such a purpose (create a root hash then search the .hash file). ;o) Cor

alden - 02.03.13 6:32 am

First, many thanks for the program. It's great!

It seems that the checksum is computed across NTFS file streams. I assume that this is a consequence of it is so fast - bypassing the file system. Still, it would be nice to have the option to include the streams or not (perhaps as a command-line switch), as the same file or not. For example, I have

foo.txt
foo.txt:bar

foo.txt has two streams, the default, (often called "", ":", "$DATA"). I would like to be able to create checksums as follows. Option 1: abcd foo.txt (includes both the default and bar streams) Option 2: dcba foo.txt (the default stream only) Option 3: dcba foo.txt (just the default stream) aaaa foo.txt:bar (just the bar stream) I'm not sure how much slower this would be, but it would be worth it for some of my applications. It's not something I've ever considered supporting because frankly, aside from a few ubergeeks (and Mark Russinovich, of course) no one uses or even knows about NTFS alternate data streams. Maybe some big potential corporate user will come along and sponsor that change. That's unlikely though, as support for streams on Windows is shaky and inconsistent. If anything, the idea that I could attach data to a file and not change its hash is much more useful. ;o) Cor rogw - 03.03.13 11:43 am Hi. Installing checksum I get "Autolt Error Line -1: Error:Unknown function name". I notice that someone previously reported this and was advised to re-download. Done this - but still the same. Thanks. rogw - 03.03.13 1:06 pm Please ignore last message - a reboot fixed it. Glad to hear it! The installer isn't perfect, but it does work. Thanks for posting a follow-up, few do. ;o) Cor Marapi - 05.03.13 7:16 am Hi, one HUGE feature I rely very heavily on with RapidCRC is sadly (and very, very strangely) not available in checksum. It's the ability to select multiple folders or files to be hashed. What I normally do is select multiple non-adjacent folders or files (ctrl+click) and then right-click send-to > RapidCRC. RapidCRC launches and then proceeds to hash all the files I selected. It's dead simple and very intuitive. Now when I do the same with checksum, there's a pop-up warning me about multiple instances of checksum thrashing my hard drive! After that checksum only works on a single entry I selected and ignores the rest! I have to manually select each item to hash and wait for it to finish before selecting another one. ONE AT A TIME. The only other option is to move all the things I want to hash into one folder, then right-click that folder > create checksums. After that I have manually move back everything to where it was along with their new hashes, which is even more tedious than hashing individual items one at a time. RapidCRC doesn't launch multiple instances. It simply launches ONE instance with all the files and/or folders I selected and just checksums them one at a time inside a queue. It seems so natural and logical I don't understand how checksum doesn't have this function. By the time you have finished selecting all your folders, the checksum user has hashed the entire drive and gone for a coffee. ;o) Cor Marapi - 05.03.13 4:29 pm I can't fathom why you would assume it takes me so long to select multiple folders. I wouldn't waste my time manually selecting tens or hundreds of folders if that's what you're imagining I'm doing. Think 15 items MAX. Usually it's just 2. TWO folders. That's it. The problem is, if I decide to hash those TWO folders with checksum, I end up wasting a lot of time. This is because the folders I work with aren't usually very small. Think 20-60 GB EACH. It may be only two folders but already they can total more than 40-100 GB. Normally I would just select those two folders, right-click, send to RapidCRC, then walk away. When I come back, it's done. Simple. But with checksum I can't just walk away. I have to wait for it to hash ALL 60 GB in one folder, then have it start on the OTHER 60 GB folder, and THEN I can walk away. BTW, those TWO folders reside on a 2TB drive almost completely filled with lots of large files mixed with thousands of tiny files, and it's one of many drives I manage. You're telling me the only other options I have are: a: Just hash the entire drive. ALL 2000 GB instead of just the two 60 GB folders. BTW I have in fact hashed 2TB worth of data before, and it takes HOURS. Checksum (or any program) can't magically hash faster than a hard drive can read. b: Put the two folders I want to hash into another folder, and then hash that folder. Then move the two folders back to where they were and delete the temporary folder. Like I said before, this gets old very quickly especially when you have to do this multiple times a week. I can avoid having to move folders and files back and forth by using an extremely nifty program called "Virtual Disk" (virtualdisk.net) which is unlike anything I've ever seen before or since. Basically, it allows me to add folders or files from anywhere and they'll appear inside the virtual disk as if they were physically there, but the folders haven't actually moved. It's essentially NTFS junction points on steroids. This allows me to select multiple folders and files even from different physical drives, and have checksum hash them all in one go. While this is a neat workaround for checksum's limitation of only being able to hash one partition at a time, it is far from ideal for smaller tasks that need to be done on a regular basis. This also applies to verifying hashes. Sometimes I just want to verify TWO large files or folders, not the entire drive, which again, takes a lot of time. All I'm asking for is essentially an "enqueue" function, and I can finally drop RapidCRC for all my non-CRC32 hashing tasks. If you're telling me it is infeasible to implement such a simple function in checksum, then I ALMOST regret donating those$7 for a checksum license.

I hear what you are saying, and I have heard it before once or twice. I guess not enough people have asked for this for me to consider it seriously. checksum has so many ways to synchronize and ignore folders and be scripted that I expect many users wishing to do such things on a regular basis have a shortcut for that.

I do understand the convenience of selecting multiple folders for hashing though it's been years since I considered doing it myself, stuff that gets hashed tends to live together these days.

I didn't say it was infeasible, in fact, I told you nothing! But I can also assure you it is no "simple function". You are spawning multiple processes with Explorer - checksum (the first instance) must track all those processes and queue their command lines into a batch of some sort before killing them all for the task itself, and that's assuming Explorer has indeed launched them all, yet. Or else have them all running feeding their commands into a central queue. I could certainly look into it, in fact I've thought of a couple of unusual approaches as I've been typing this, but there's currently a freeze on new functions so that I can get the current beta released before Summer!

In the meantime, if it's something you do a lot, with the same folders, it's simple enough to whip up a wee batch file to handle the job, or else check out this.

If you need a hand with any of this, get in touch!

;o) Cor

Marapi - 06.03.13 2:31 am

Thank you for pointing out hashDROP. It solved my problem perfectly, and it uses the same ini as checksum which is very convenient.

I mistakenly assumed queuing multiple files was simple since it seemed that way with programs like RapidCRC and foobar2000. There's even a method in basic javascript for opening multiple entries in web browsers so it seemed trivial to implement a similar function to handle local directory paths. I was thinking something along the lines of recording the file and folder paths to an internal list and then just going through it one at a time. But it seems hashDROP already does exactly this, so I understand how there's no need to do work that's already been done. I'm only curious as to what hashDROP does that can't be easily done within checksum. Is it doing what you described and just opening and closing instances of checksum automatically?

It's to do with how explorer handles things. If you drag and drop or send a file to a program by some other means (context menu, SendTo, etc.) the command line looks like this..

c:\path\to\program.exe "d:\path\to\some.file"

This is trivial to deal with, internally. Things get decidedly trickier when you send multiple files. If you did that via drag and drop, the command line might look like this..

c:\path\to\program.exe "d:\path\to\some.file" "d:\path\to\some.file2" "d:\path\to\some.file3"

Which is also fairly easy to deal with, internally. However, if you did the same thing via a context (right-click) Explorer menu. The command line looks like this..

c:\path\to\program.exe "d:\path\to\some.file"

and this..

c:\path\to\program.exe "d:\path\to\some.file2"

and this..

c:\path\to\program.exe "d:\path\to\some.file3"

In other words, Explorer launches three separate processes, one for each file.

So now we need some kind of built-in mechanism to track completely separate instances of the same program running on the system (checksum already has this capability) and then some way of passing the data (file name and command-line switches) from the other instances back to the first instance of the running program, queue those commands, and then kill the other instances so only the first remains to; once it it certain no more data is coming; complete all the tasks.

While not trivial, it's certainly doable. I've just never had a burning need to do it. I did quickly play around with an idea after your last post, which worked quite well, so it may appear in checksum sooner than expected!

By the way, afaik, foobar2000 was unable to do this until fairly recently, much to the annoyance of its users - in a media player, this sort of capability is definitely expected.

;o) Cor

Richard - 12.04.13 3:45 pm

Is there a console application nestled in your program?

It seems your program is too good for my needs. I'm comparing files on different computers. And running hash tools over the network is ugly in the extreme. So I've written a clever perl script to write a customized batch file, copy the hash utility over to that remote directory, and run it locally. The concept is great, except I haven't found a utility that doesn't need installing, is console based, won't crash, and in fciv's case won't try to remember past work.

Although not a "console app", checksum is in large part designed to be run from a console, or batch script, task scheduler, etc., with a vast selection of command-line switches at your disposal..

http://corz.org/windows/software/checksum/checksum-tricks.php#custom-command-line-switches

checksum can run in a completely portable state too, so long as there is a checksum.ini locally, checksum will use it. No installation required.

And if you are running checksum from a command prompt or some remote launching mechanism, checksum even has a special switch ("q") to suppress all dialogs on the local machine. Add to that fully customizable local logging and it looks like you are good to go.

Need anything else?

;o) Cor

Shane Saunders - 20.04.13 12:14 pm

I have been sent to hash SH1 but I have know idea hoe to open them ,,reply to them or even read them,, I would love some help on what to do please.. I know how to save keys to GPA 0.9.1 svn1024 and encrypt a message and send i but that's about as far as my knowledge goes.. Here is what iv been sent and hopefully you can help me open them and teach me to do it myself..

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBsJRPSJMAAoJENSgSmxCqWM3/DQIAKFO2oesfQZxinoxrQ7WS+xb
qiV0I5I2xcCJEFPC+33n072KYcUS4vrrXQSTlTNhvxnAxA0cNlWJdxqGtbw//hsZ
gRwuJ1/D7pf67aHnxY4iKo/NHm3DxIxnNggsAyhlke6ux/33n5xXL+qGPLRRJyMi
cq2dv36yRVWteq3n7Wn/THxWm++PJnncsrB5yzUe6nZpgT3Co/a00vlnZoLQVYFB
nNrxL3aButWpp+EqUnjz+fNyJ9epIfNzgCX61Z7uUuBleXyfHrZRcN3AcRtkeces
19sdys7mlPSzvoKNfkQTpoZjcVkMy27MUXtttnKPpMrXMbdSr7ohLi+2ciCr9cU=
=RcAm
-----END PGP SIGNATURE-----

This isn't a checksum file. This is a SHA1 "Signature". It enables you to verify; much like checksum does with files; the identity of the sender.

You don't have to do anything with this SHA1 hash. If you like, you can install gnupg, maybe the Thunderbird OpenPGP plugin and, once this individual's key has been verified and added to your keyring, use the above hash to verify a sender is who they say they are. I'm assuming by "sent", you mean email.

You can also use these signatures to import a person's public key from a public key server (there are many) and, assuming that information is okay, download, install and use their published public key to send them encrypted messages which only they can read. There may be other things you can do with them!

But again, nothing to do with checksum.

;o) Cor

Marapi - 25.04.13 11:41 am

Hi, checksum seems to ignore files and folders with certain characters like: ★
(There are others but I can't remember them right now.)

You must have missed this when reading the recent changes!

Also, checksum errors out when trying to checksum folders with names longer than 100 characters? 101 or more characters results in an error and unhelpful fallback behavior.

If file name length is the problem I wish checksum would've just said so, though 100 characters is a bit low for a limit. Even the old win32 api has a limit of 255 characters, or 249 or whatever, but way higher than 100.

Nope, it's whatever MAX_PATH is on your system, usually 260 characters, even on the newest Windows systems. Your issue must be something else.

;o) Cor

Marapi - 25.04.13 3:14 pm

At the time of this writing, there's nothing there.

Only registered users have access to unreleased betas. At the time of writing, it should be out within a couple of weeks. ;o) Cor

Alexy - 02.05.13 5:39 pm

Hi, thanks for making this very useful tool. After donating, how does one get a license number?

Click the "Licensing" link at the top of this page. You can't miss the PayPal button. Once the PayPal process completes, your license code is sent to you automatically. You don't have to do anything.

;o) Cor

Enter the 5-digit code this text sounds like : lower-case jay, Upper-Case Oh, nein, lower-case zed, Upper-Case Bee`