# checksum tricks and tipshints, secrets, behaviours, assumptions and more..

## Get the most from your hashing!

checksum represents a whole new way of working with hashes. This page aims to help you get the most out of the experience, wherever you're at..

## Absolute beginners..

The basics: checksum creates "hash files". A hash file is a simple, plain text file containing one or more file hashes, aka. "checksums". Hashes are small strings which uniquely represent the data that was hashed. e.g..

cf88430390b98416d1fb415baa494dce *08. Allow Your Mind To Wander.mp3

(Mike Mainieri - Journey Thru An Electric Tube [1968] - I have the vinyl)

If you want to know more about the algorithms that checksum uses to hash files (MD5, SHA1 and BLAKE2), see here.

Once these hashes have been created for a particular file or folder (or disk), you have a snapshot that can be used, at any time in the future, to verify that not one bit of data has changed. And I do mean a "bit"; even the slightest change in the data will, thanks to the avalanche effect, produce a wildly different hash, which is what makes these algorithms so good for data verification.

## The basic checksum tasks..

Most people will simply install checksum, and then use the Explorer context (right-click) menu to create and verify checksums, rarely needing any of the "extra" functionality that lurks beneath checksum's simple exterior. After all, checksum is designed to save you time, as well as aid peace of mind. This is how I mostly use it, too..

### Create checksums..

Right-click a file, the checksum option produces a hash file (aka. 'checksum file') with the same name as the file you clicked, except with a .hash extension (or .md5/.sha1, if you use those, instead). So a checksum of some-movie.avi would be created, named some-movie.hash (if you don't use the unified .hash extension, your file would instead be named some-movie.md5 or some-movie.sha1, depending on the algorithm used).

Right-click a folder, the Create checksums.. option will produce a hash file in that folder, containing checksums for all the files in the folder (and so on, inside any interior folders), named after the folder(s), again, with a .hash extension, e.g. somefolder.hash

### Verify checksums..

Click (left-click) a hash file (or right-click and choose Verify this checksum file..), checksum immediately verifies all the hashes (.hash/.md5/.sha1) contained within.

Right-click a folder, the Verify checksums.. option instructs checksum to scan the directory and immediately verify any hash files contained within.

That's about it, and this simple usage is fine for most situation. But occasionally we need more..

## checksum launch modifiers..

When you launch checksum, you can modify its default behaviour in two important ways.

The first modifier is the <SHIFT> key. Hold it down when checksum launches, and you pop-up the one-shot options dialog, which enables you to change lots of other things about what checksum does next. This works with both create and verify tasks, from explorer menus or drag-and-drop. Here's what the one-shot create dialog looks like..

In there, as you can see, you can set all sorts of things. Hover over any control to get a Help ToolTip (you might need to repeat that to read the entire tip!). You can also drag files and folders directly onto that dialog, if you want to alter the path setting without typing. Same for the verify options.

The file mask: input is, by default, *.*, which means "All files", "*" being a wildcard, which matches any number of any characters. You can have multiple types, too, separated by commas. For example, if you wanted to hash only PNG files, you would use *.png; if you wanted to hash only text files beginning with "2008", you could use 2008*.txt, and so on.

If you click the drop-down button to the right of the input, you can access your pre-defined file groups, ready-for-use (you can easily add to/edit these in your checksum.ini)..

NOTE: Normally one drops folders into checksum's create options (path input). If you drop a file onto the create options, the path is inserted into the path: input, and the file name is added to the mask input - it is also inserted into the drop-down lost in case you need to get back to it.

If you drop multiple files into the create options, checksum will create a custom file mask from your selection. For example, if you dropped these three files; "hasher.jpg", ".txt" and "security.pdf", checksum would create the mask: "*.jpg,*.txt,*.pdf".

Here is what the one-shot verify options dialog looks like..

The second modifier is the <Ctrl> key. Hold it down when checksum launches and you force checksum into verify mode, that is to say, no matter what type of file it was, you instruct checksum to treat it as a hash file, and verify it. This works with drag-and-drop too, onto checksum itself, or a shortcut to checksum. checksum's default drag-and-drop action is to create hashes.

Amongst other things, this is useful for verifying folders in portable mode, simply Ctrl+drag-and-drop the folder directly onto checksum (or a shortcut to it), and all its hashes will be immediately verified.

Hit the modifier key as soon as checksum launches, in other words, hit the <SHIFT>/<Ctrl> key right after you choose the Explorer menu item, or before you let go of a drag & drop, and so on. Hold the key down until checksum appears a moment later.

## batch processing..

### hashDROPA batch-processing front-end for checksum..

Because checksum can be controlled by command-line switches, it's possible to create all sorts of interesting front-ends for it. The first of these to come to my attention, is a neat wee application called "hashDROP", which enables you to run big batches of jobs through checksum, using a single set of customizable command-line switches.

As developer seVen explains on the hashDROP page..

hashDROP is a front-end for checksum which enables you to queue a bunch of jobs (files/folders) and then pass them all through checksum with your own custom switches in one batch process.

On seVen's desktop, at least, it looks something like this..

hashDROP has already earned a place in my SendTo menu. Good work, seVen! For more information, documentation, and downloads, visit the hashDROP page.

### Batch RunnerRun multiple programs in a batch..

I originally designed Batch Runner to run a big batch of tests on checksum before release, but it has since proven useful for other tasks, so I spruced it up a bit, made it available.

If you want to run loads of hashing jobs using the same switches, hashDROP is probably more useful to you. But if you want to run lots of checksum jobs with different switches, or as part of a larger batch of jobs involving other programs, then check out Batch Runner.

Batches can be saved, selected from a drop-down, run from the command-line, even from inside other batches, so it's handy for repetitive scheduled tasks, or application test suites, as well as general batch duties. At least on my desktop, it looks like this..

## Automatic Music playlists..

Perhaps checksum's second most common extra usage is making music playlists. After you have ripped an album, you will most likely want a playlist along with your checksums, so why not do both at once? checksum can.

Right-click a folder and SHIFT-Select the checksum option (which pops up the one-shot options dialog), check either the Winamp playlists (.m3u/.m3u8) or shoutcast playlists (.pls) option, and then do it now! You're done.

By default, checksum will also recurse (dig) into other folders inside the root (top) folder. Now you've got music playlists that you can click to play the whole album in your media player.

Note that checksum will thoughtfully switch your file masks to your current music group when you select a playlists option, reckoning that you'll probably only want to actually hash the music files, not associated images, info files and such, but it's easy enough to switch it back to *.* (hash all files) if you need that. The rationale behind this being that it's what most people want, so the majority get the simpler, two-click task.

If you do this sort of thing a lot, check out the next section, for how to put this functionality directly into your Explorer context menu, and skip the dialog altogether..

## Custom Explorer Context Menu Commands made easy..

On the subject of music files, you may encounter a lot of these, and fancy creating a custom explorer right-click command along the lines of "checksum all music files", or something like that. No problem; you can simply create a new command in the registry, add the "m" switch add your file masks, right?

But what if you change your file masks? Perhaps add a new music file type? Do you have to go and change your registry again? NO! checksum has it covered. Instead of specifying individual file masks, use your group name in the command, e.g. m(music) and checksum applies all the file masks from that group automatically, so your concept command is always up-to-date with your latest preferences.

Here's an example registry command that would do exactly that. Copy and paste into an empty plain text file, save as something.reg, and merge it into your registry. If you installed checksum in a different location, edit the path to checksum before you merge it into the registry (not forgetting to escape all path backslashes - in other words, double them)..

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\01b.checksum music]
@="Checksum &MUSIC files.."

[HKEY_CLASSES_ROOT\Directory\shell\01b.checksum music\command]
@="\"C:\\Program Files\\corz\\checksum\\checksum.exe\" crm(music) \"%1\""


NOTE! If you add a "3" to the switches [i.e. make them c3rm(music)] you'll get a media player album playlist files created automatically along with the checksum files. Groovy! Here's one I prepared earlier.

### Setting new default Explorer context actions..

You can also change checksum's default Explorer commands, as well as add new commands, without going anywhere near the registry. Simply edit the installer's setup.ini file, [keys] section. For example, to always bring up the one-shot options dialog when creating checksums on folders and drives, you would add an "o" to those two commands..

HKCR\Directory\shell\01.|name|\command="|InstalledApp|" cor "%1" HKCR\Drive\shell\01.|name|\command="|InstalledApp|" cor "%1" Then run checksum's installer (setup.exe), and install/reinstall checksum with the new options. From then on, any time you select the "Create checksums.." Explorer context menu item, you will get the one-shot options dialog. If you would prefer to synchronize hashes under all circumstances, add a y, and so on.

## Creating checksums "quietly"..

If you want to script or schedule your hashing tasks, you will probably want checksum to run without any dialogs, notifications and so forth. If so, add the Quiet switch.. q

When the q options is used alone, if checksum encounters existing hash files, it continues as if you had clicked "No to All", in the "checksum file exists!" dialog, so no existing files are altered in any way. This is the safest default.

If you would prefer checksum to act as if you had clicked "Yes to all", instead, use q+, and any existing checksums will be overwritten.

If you want synchronization, add a y switch (it can be anywhere in the switches, so long as it's in there somewhere, but qy is just fine)

Quiet operation also works for verification, failures are logged, as usual. Like most of checksum's command-line switches, these behaviours can be set permanently, in your checksum.ini.

## Working with Cross-Platform hashes..

checksum has a number of features designed to make your cross-platform, inter-networking life a bit easier.

You don't have to do anything special to verify hash files created on Linux, UNIX, Solaris, Mac, or indeed any other major computing platform; checksum can handle these out-of-the-box.

If you need to create hash files for use on other platform, perhaps with some particular system file verification tool, checksum has a few preferences which might help..

You will perhaps appreciate checksum's plain text ini file (checksum.ini) containing all the permanent preferences. Inside there you can set not only which Line Feeds checksum uses in its files (Windows, UNIX, or Mac), but also enable UTF-8 files, single-file "root" hashing, generic hash file naming, UNIX file paths, and more. Lob checksum.ini into your favourite text editor and have a scroll.

There are a number of ways to run checksum. One handy way, especially if you are running checksum in portable mode without Explorer menus, is to keep a shortcut to checksum in the SendTo menu.

Simply put; any regular file or folder sent to checksum will be immediately hashed. Send a checksum file (.hash, .md5, .sha1, plus whatever UNIX hash files you have set), and it will be immediately verified. If you want extra options, hold down the <SHIFT> key, as usual.

If you want to send a non-checksum file, but have checksum treat it as a checksum file, hold down the <Ctrl> key during launch, to force checksum into verify mode (either just after you activate the SendTo item, or perhaps easier; hold down <SHIFT> AND <Ctrl> together while you click, to bring up the one-shot verify options). This is also handy for verifying folder hashes.

## How to accurately compare two folders or disks.

This is an easy one. First, create a "root" hash in the root of the first (source) folder/disk, then copy the .hash file over to the second (target) folder and click it.

That's it!

For situations where you don't need a permanent record of the hashes, you can fully automate the process of comparing two folders with simple checksum.

## How to accurately compare two CDs, DVDs, etc.(even when they don't have hash files on them)..

When hashing read-only media, obviously we cant store the hash files on the disk itself. However, thanks to checksum's range of intelligent read-only fall-back strategies, you can make light work of comparing read-only disks with super-accurate MD5 or SHA1 hashes, even if those disk were burned without  hashes.

All we need to do, is ask checksum to create a "root" hash file of the original disk, using the "Absolute paths" option. This will produce a hash file containing hashes for the entire disk, with full, absolute paths, e.g..

531a3ce6b631bb0048508d872fb1d72f *D:\Sweet.rar 558e40b6996e8a35db668011394cb390 *D:\Backups\Efficient.cab 832e98561d3fe5464b45ce67d4007c11 *D:\Sales Reports\April.zip

There are a few ways to achieve this. For one-off jobs, you can simply add k1 to your usual command-line switches. For example, to create a recursive root hash file of a disk, with absolute paths, you would use crk1.

Another way, is to set (and forget) checksum's fallback_level preference to 2, inside checksum.ini..

fallback_level=2

With fallback_level=2, when checksum is asked to create hashes of a read-only volume, it will fall-back to creating a single "root" hash with absolute paths, inside your fall-back location (also configurable), which is exactly what we need!

Then in the future, to verify the original disk, or copies of the disk; you simply insert it, and click the hash file.

You can store the .hash file anywhere you like; so long as the disk is always at D:\, or whatever drive letter you used to create the .hash file originally, it will continue to function perfectly.

If you want to know more about checksum's read-only fall-back strategies, see here.

## Or accurately compare a burned disk to its original .iso hashes..

If you have a .hash file of the original .iso file, in theory, a future rip of the disk to ISO format, should produce an .iso file with the exact same checksum as the original. My burner is getting old, but I needed to know, and so tested the theory.

I Torrented an .iso file of a DVD (Linux Distro) - the hashes were published onsite, checksum verified these were correct. I burned the disk to a blank DVD-R, and then deleted the original .iso file. Everything is now on the disk only. The .hash file is still on my desktop.

Then I used the ever-wonderful ImgBurn, to read the DVD to a temporary .iso file on my desktop.

Fortunately, the .iso file, and the original .iso file had the same name, so I didn't need to edit the .hash file in any way. Then the moment of truth. I click the .hash file, and checksum spins into action, verifying. A few seconds later... Beep-Beep! No Errors! It's a perfect match!

I can't speak for other software, but with ImgBurn at least, a burned disk can produce an .iso file with a hash bit-perfectly identical to that of the original .iso file used to create the disk, and can be relied upon for data verification. Good to know.

## checksum as an installer watcher..

Because checksum can so accurately inform you of changes in files, it can function as an excellent ad-hoc installer watcher. All you do is create a root checksum for the area you would like to watch. Run the installer. And afterwards, verify the checksum. If anything has changed, checksum will let you know about it, with the option to log the list to funky XHTML or plain text.

Similarly, checksum can be utilized in any situation where you need to know about changed files. You can even use it to compare registry files, one exported before, the other after an install or other process. If the hashes match, there's no need to look further.

## checksum's custom command-line switches..

Click & Go! is the usual way to operate checksum; but checksum also contains a lot of special functionality, accessed by the use of "switches"; meaningful letter combinations which instruct checksum to alter its operation in some way.

If you have some unusual task to accomplish, the one-shot options dialog enables you to manipulate the most common switches with simple checkbox controls. You can see the current switches in a readout, updating dynamically as you check and uncheck each option. But this output is also an input, where you can manipulate the switches directly, if you wish. If that is the case, you will probably find the following reference useful.

You may also find this section useful if you are constructing a full checksum command-line for some reason, maybe a Batch Runner command or batch script, or custom front-end for checksum, or altering your explorer context menu, or creating a scheduled task, or some Übertask for your Run command (Win+R) or something else. In each case, switches are placed before the file/folder path, for example; the full command-line to verify a checksum file might look like this..

C:\Program Files\corz\checksum\checksum.exe v C:\path\to\file.hash

Here are all the currently available switches:

c
Create checksums.
v
Verify checksums.
r
Recurse (only for directories).
y
Synchronize (add any new file hashes to existing checksum files).
i
During creation: create individual hash files (one per file).

During verification: performs hash search for individual file (see examples, below).

s
Create SHA1 checksums (default is to create MD5 checksums).
2
Create BLAKE2 checksums (default is to create MD5 checksums).
u
UPPERECASE hashes (default is lowercase).
m
File masks. Put these in brackets after the m. e.g..  m(*.avi,*.rm)
Note: You can use your file groups here, e.g. m(music)
j
Custom hash name (think: "John"!). Put this in brackets after the j. e.g..  j(my-hashes)
d
Output Directory. Put this in brackets after the d. e.g..  d(C:\hashes)
NOTE: Make this the last bracketed switch on your command-line, i.e. m(..)j(..)d(..).
e
Add file extensions to checksum file name (for individual file hashes)..
1
Create one-file "root" checksums, like Linux CD's often have.
3
Create .m3u/.m3u8 playlists for all music files encountered (only for folder hashing)..
p
Create .pls playlists for all music files encountered (only for folder hashing)..
q
Quiet operation, no dialogs (for scripting checksum - see help for other options)..
h
Hide checksum files (equivalent to 'attrib +h').
o
One-shot Options. Brings up a dialog where you can select extra options for a job.
(to pop up the options at run-time, hold down the <SHIFT> key at launch)
b
Beeps. Enable audio alerts (PC speaker beeps or WAV files).
t
ToolTip. Enable the progress ToolTip windoid.
n
No Pause. Normally checksum pauses on completion so you can see the status. This disables it.
(note: you can also set the length of the pause, in your prefs)
k
Absolute Paths. Record the absolute path inside the (root) checksum file.
Use this only if you are ABSOLUTELY sure the drive letter isn't going to change in the future..
f
Log to a file
(if there are failures, checksum always gives you the option to log them to a file)
g
Go to errors.
If a log was created; e.g. there were errors; open the log folder on task completion.
l
Log everything.
(the default is to only log failures, if any).
w
Update changed hashes. (think: reWrite)
(during verification, hashes and timestamps for "CHANGED" files can be updated in your .hash file).
x
During creation: used to specify ignored directories, using standard file masks.
e.g. checksum.exe cr1x(foo*,*bar,baz*qux) "D:\MyDir"

During verification: delete missing hashes.
(hashes for "MISSING" files are removed from your .hash file).

a
Only verify these checksum files.
(followed by algorithm letter: am for MD5, as for SHA1, a2 for BLAKE2 - see example below).
z
Shutdown when done.
Handy for long operations on desktop systems. A dialog will appear for 60 seconds, enabling you to abort the process, if required

The 'a', 'f', 'g', 'l' and 'w' switches only take effect when verifying hashes.

The '1', '2', '3', 'd', 'e', 'h', 'j', 'k', 'm', 'p', 's', 'u', and 'y' switches only take effect when creating hashes.

The 'i' and 'x' switches have different functions for creation and verification.

In other words..

global switches = b, n, o, q, r, t, z.
creation switches = 1, 2, 3, c, d, e, h, i, j, k, m, p, s, u, x, y.
verify switches = a(m/s/2), f, g, i, l, v, w, x.

Switches can be combined, like this..

… checksum.exe v "C:\my long path\to\files.md5"
[ note 'long' path (with spaces) enclosed in "quotes" ]
… checksum.exe crim(movies) c:\downloads
[ create individual checksums for all my movie files - note use of group name ]
… checksum.exe vas c:\archives
[ check all *.sha1 files in the path, not *.md5 files ]
… checksum.exe c3rm(music) p:\audio
[ recursive music file checksum creation, with automatic playlists ]
… checksum.exe cr1m(*.zip) d:\
[ create a "root" checksum for all zip files on drive D: ]
… checksum.exe vi d:\path\to\some\video file.avi
[ search for matching entry for "d:\path\to\some\video file.avi" and verify that one file ]
… checksum.exe crkq1m(movies)j(video-hashes)d(@desktop) v:\
[ quietly create a "root" checksum (named "video-hashes.hash") for all movie files on drive V: and place it on the desktop ]

note: Although it won't appear in the options dialog, the custom name, "video-hashes", will still be set when you begin the job.

### notes:

• The order of the switches isn't important, though the "m" switch must always be immediately followed by the file masks (in brackets), e.g. m(*.avi) (same with d(dir), j(name) and x(file*mask) switches), and the "a" switch must  be the first letter of a two letter combination, e.g. am

The d() (output directory) switch must be the last (bracketed) switch on your command-line. If you are using custom hash file name and/or custom file groups, put those first, e.g..

"c:\path to\checksum.exe" cr1qnm(movies)j(my-hashes)d("c:\some (dir) here") "D:\My Movies"

..which would quietly create a root hash file for all the movie files in D:\My Movies, and put those hashes in "c:\some (dir) here\my-hashes.hash". Those tricky braces inside the example path are why it goes last.

• You don't need to specify the m(music) group switch to create playlists, only the 3. A command like checksum.exe rc3 "P:\audio" would create checksums recursively for all  files in the path p:\audio, whilst creating playlists for only  the music file types. Nifty, huh?

• Most of these switches also have a preference inside checksum.ini. If that preference is enabled, you can disable it temporarily by prepending the switch with a - (minus) character, e.g. to disable the Progress ToolTip, use -t

• Any of these switches can be easily added permanently to your Explorer right-click (context) menus. For instance, you may like to always use the one-shot options, without having to hold the SHIFT key every time. So simply add an o, and it will be so. See here for details of how to permanently alter checksum's Explorer context menu commands.

And remember, if there's some specific behaviour that you want set permanently, you can do that, and a lot more, inside checksum.ini..

## checksum.iniworking with checksum's UNIX-style preference file..

checksum has a lot of available options. Here is a page that will help you get the most out of them.

## I do requests!

If there's something you would like to accomplish with checksum, but don't think think checksum can; feel free to request a feature, below..

## Request a feature!

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

previous comments (eight pages)   show all comments

Mike - 20.08.14 9:43 pm

Hi! Is there a way I can check only one file from a folder? I have a .hash file with all the file hashes, but when I tell it to verify it checks all the files which takes too much time.
The only solution I see is to open the hash file in notepad, find the hash of the file I want to check, copy it, then use simple checksum to compare them.

If you want to be able to verify individual files, make individual .hash files (there is an option in the one-shot dialog for this, or use the "i" switch on the command-line). ;o) Cor

ps. I do however like the idea of being able to pluck a single hash, or group of hashes out of a big .hash file, and only verify those. Hmmm.. Let me think about this!

jumperalex - 20.08.14 10:04 pm

Sorry to double post, I was too slow to edit:

So I see that I can grab "checksum" out of /usr/local/bin and use that in the command lines of UnRaid Slackware 14.1 64-bit and Arch 64-bit. Unfortunately I cannot seem to get "verify" to work as it tells me it is not executable. "file verify" tells me it is "data". And no command switches seem to work using "checksum" so how would I go about syncronizing?

Am I doing something wrong?
Or do I need to just hope you see it in your heart to create a full command line suite for linux?

I know this now reads like a straight question but it is still of course related to my feature request

For reference Unraid on Slackware 14.1 does NOT have the ability to run 32-bit programs.

The other commands (verify, kverify, etc.) are just symlinks to checksum. In fact, I think something got messed up in the zipping, because they no longer seem to be valid symlinks. It's been a long while since I did any work on the Linux version of checksum. Simply make a symlink to checksum named "verify" (checksum will then recognize that it has been invoked for verification purposes). You can also use the --verify switch with checksum.

At the end of the day, "checksum" is simply a bash script (therefore not 32 or 64 bit) front-end for the tools that are already on your system (md5sum, sha1sum, etc.). There is no checksum "executable" as such, just a script.

You could easily script md5deep or hashdeep to do a similar job.

;o) Cor

hmmm ok so here is what I typed based on your comment above

root@Tower:~# checksum /mnt/disk1/test.txt

Creating hashes in "/mnt/disk1/test.hash" ..
** To abort, press Ctrl-C **

All done with hashing.

All done in 0 seconds.

I then tried to verify using the switch and got this:
root@Tower:~# checksum --verify /mnt/disk1/test.hash
This is a checksum file. You can verify it.
I haven't tried to symlink yet because well ... I need to learn how to do that first and I have to leave for a Dr's appointment

"You could easily script md5deep or hashdeep to do a similar job."

Yeah if that were true I wouldn't be having the problems I've having

Looking inside the checksum script, it looks like, for some reason, that switch isn't implemented yet. Using a symlink does work, though..

cd /usr/local/bin
ln -s checksum verify

;o) Cor

jumperalex - 21.08.14 4:56 am

Success!!! Verify now works. It will tell me what is OK, MISSING, FAILED.

However, it also seems like some of the other switches aren't working. I intentionally renamed a file so that I had a new file and a missing file, and I went inside another file and intentionally changed it. A straight verify operation correctly identified the MISSING and FAILED hashes.

I then tried 'verify x' to delete the missing hash (it did not) and 'w' to reWrite the 'FAILED' hash (it did not).

re: the added file after initial hash generation. Using 'checksum' it adds the new file's hash and skips all the others without using the 's' switch. I tried again with 'checksum s' and got the same result.

I'm guessing that is normal behavior but then I wonder what 's' is for in this context. Since the verify 'w' switch isn't working I'm left to ask how do I refresh hashes besides just deleting the .hash file?

Ssorry I'm bringing this all back from the dead, as you said you haven't touched it in a while.

FWIW, I think you'll get a few more customers from UnRaid if this can all get hashed out. Some of us are in fact using checksum over the network, but I know others aren't because it can be pretty slow and even more would love to have a way to automate this with alerts. To do that means command line.

Thanks,
Alex

Firstly, understand checksum is a Windows application. The Linux version is a VERY basic implementation so that I could perform checksum-like operations on my old KDE desktop.

You really need to read the notes at the top of the script itself. The switches are listed there, namely: --kde, --zenity | --zen, --hybrid, --x, --append, --noappend, --algo, --md5, --sha | --sha1, --sha2, --sha3, --sha5, --mask=file.mask

And that's it!

Any of the notes and information you see around this part of the site relates to the Windows version, so none of the switches you mentioned will work. Only those above.

checksum on Windows is under constant development, but I haven't touched the Linux version for a long time - these days I don't use a Linux desktop at all - my Slackware box is CLI only.

I recently added the Linux version to the regular Windows distro in the hope was that someone might find it as useful as I had (it seemed a shame to not let it out there) and perhaps even expand its functionality. Feel free!

;o) Cor

Oh crickey!!! I'm really sorry about that. Thanks for pointing me in the right direction. And yes indeed my Unraid Slackware and Arch VM are CLI only as well. That's why I'm not pinging you about getting the KDE version running ;-)

Well all I can say is that if you have any inclination on beefing up the linux cli version I'm pretty sure there is a market for any of us running headless NAS / Media centers that worry about long term bit rot and identifying which files have caused a parity failure check..

Hey, no worries! You can head over to this directory, where I did eventually get a checksum on Linux section sort of up. You can grab the Linux checksum distro, as well as a working set of symlinks (the bin directory) in a gzip, to replace the non-functioning set in the distro, and a syntax-highlighted (though your favourite text editor would probably do better) web view of the main checksum script.

You are right, there is still a lot could be done to the Linux cli end of things. The error reporting needs fixed for a start; when there are errors, it's not immediately obvious, which it should be. And more of the Windows functionality needs added, of course.

The documentation at the top of the Linux script is slightly confusing in parts. Och, loads! It's only when people show an interest that I develop things beyond my own basic needs. checksum on Windows has come a long, long way since I got it doing most of what I wanted for myself.

Tell me what's important to you.

If there's interest, I'll start some comments over in linux/ specifically for this stuff, implement what I can in what time I have available.

;o) Cor

Gabriel - 03.09.14 11:38 pm

Hi Cor,

just starting to test your checksum sw and it rocks! Congrats.

Would you consider to develop a QNAP NAS App (linux) so I could check the files that landed into the NAS are still fine? I would definitely pay for it also

Cheers
Gabriel
http://www.qnap.com/i/en/app_center/

Thanks.

checksum is already quite popular in the NAS community, either creating and verifying hashes over the network, or else using the Linux version (included in the Windows distro) to work with hashes locally on the NAS box. The Linux version is pretty basic but quite functional.

I don't have the time right now to develop a QNAP-specific app, but if you let me know what the requirements are (or point me to an SDK or similar), I could certainly look into making the next Linux version more QNAP friendly, if it isn't already.

;o) Cor

Gabriel - 05.09.14 8:33 pm

Thanks Cor, please find here the details about the QNAP packages http://www.qnap.com/dev/en/

Anything I could tease you to develop it?

Otherwise where can I find details on how to use the linux version in console-mode since the QNAP is a linux box but without letting to install GUI afaik (and my linux days are decades behind me)

Cheers
Gabriel

It's quite simple to operate from the command-line. Once you have the binaries and symlinks in place, you simply do..

checksum /some/path

and to verify..

verify /some/path/path.hash

The Linux version produces "root" hashes, which is a single .hash file in the root of the directory checked. It's quite basic, but capable enough to hash/veriry an entire drive in one command.

See: http://corz.org/linux/software/checksum/

;o) Cor

archedraft - 12.09.14 8:45 pm

Cor,

I just wanted to add to Jumperalex's posts that having an updated corz linux cli would be fantastic. I currently use my Windows box with checksum but I am sure it would check much faster if I could perform checksums directly from my NAS box. Either way, keep up the great work! I'll continue to send as many friends your way as I can.

-archedraft

Friends are good, thank you! Customers, too - you can never have too many of those!

checksum on Linux is only sleeping. There will be more ASAP!

;o) Cor

jumperalex - 17.09.14 11:20 am

The Revolution Has Begun!!!

Thanks Cor I appreciate you taking the time to setup the linux section and giving consideration to beefing up linux-checksum. "We" over at unraid recently had a bit of a "thing" with some silent file corruption due to a bad kernel patch. As you can imagine there are a bunch of people suddenly very interested in hash checks. Those of use who took the time to run hashes using windows checksum over the network were feeling very smug and self-satisfied even if running the verifies took a while.

So thanks again for a great product and for any future work to get more capabilities into the linux scripts.

The Linux section was well overdue. Thanks (to the other *nix users, too) for giving me a kick in that direction. I must admit, I use checksum on Windows over my own network, my workstation is on 24/7, so the checksum "way" of click-done , suits me fine. But I realize not everyone works that way and a local checksum operation on Linux box would certainly be faster (on most real-world networks, anyway - in the next few years it will become irrelevant - the choice for where to run checksum from could quickly become academic, basically, wherever the most CPU power resides)

In the meantime, checksum on Linux will pick up features some needed features, and hopefully, as time allows, more of the checksum finesse Windows users have come to know and love!

Suggestions you make NOW, loudly and/or in numbers will most likely find there way in, so let me know what is most important to you and I'll get on that first.

;o) Cor

Nacho - 06.10.14 11:34 pm

Hi. How about adding the ability to specify a relative path when you want to verify a non-absolute path hash located anywhere else instead of the original folder?

e.g.:
1.- I'm creating a one file, non-absolute path, root hash of the entire C:\test1 folder, and placing it into C:\myhashes\test1.hash

checksum crq1d(C:\myhashes) "C:\test1"

2.- If I want to verify that, I must move C:\myhashes\test1.hash to "C:\test1" in order to run:

checksum v "C:\test1\test1.hash"

It would be great to add a switch to specify the verifying path without having to move the .hash file, like this:

checksum p("C:\test1")v "C:\myhashes\test1.hash"

It would mean: verify the relative path hashes found in C:\myhashes\test1.hash against the path C:\test1

PS: I'm using command-line only quiet mode.

I have something very similar in my 2do list, but in my idea, the file name specified the path, e.g. C:\some\path\to\c~test1.hash (the "~" donating path separators)

I think I like your idea better, I will look into adding this.

;o) Cor

ps. I see in my (large) 2do file that I also have an idea for an ini [section] for moved directory mapping. I will consolidate all ideas into a grand solution!

Gerard Lally - 14.10.14 6:21 am

Hi,
nice utility. Couple of issues for me:
1) text in help dialog is quite small on a high-resolution monitor (1920*1080) and towards the bottom of the dialog, where the switches examples are, some of the text is completely missing;
2) it would be nice to have a command-line switch for the help file.
Otherwise, job well done. Will sort you out when I get my next cheque ;-)

I noticed recently that 32 bit installs have the final brace chopped off the longest example command (only the notes, not the actual command) because of the extra install path length (i.e. the " (x86)" part). In longer install paths, even more will get chopped off, because the path is inserted dynamically from checksum's actual path on your system.

At any rate, the real help file is here online - my plan is to reduce the "checksum was given nothing to do" dialog to something much simpler, basically linking to this page.

With the advent of the new startup command facility (v1.5.2.0+), I expect less people will be seeing that dialog (I am toying with the idea of having checksum simply launch a web page instead of a dialog, so that I can keep it better up-to-date/avoid screen resolution issues, etc.).

You can always get here from checksum's about box.

By the way, for users of KDE-Mover-Sizer (which is surely everyone these days!) these sorts of things are never an issue!

;o) Cor

NPSR - 24.10.14 5:06 pm

Hi Cor,

First, thanks a lot for Checksum : very usefull and very fast ;-)

Considering I want to monitor a complete folder, when I want to check and synchronise the hash file, I think I have to make it in three steps :
1/ run the check and check the log file to ensure change/missing detection are right and correct corrupted file.
2/ run again the check with option "delete missing files" and "update changed files"
3/ run a "synchronise" to update hash file with new files

It is probably possible to optimize in CLI by combining 2/ and 3/ but it is still 2 steps (except if I missed something)

My request :
Is it possible to get an interface at the end of check step to ask user to confirm action for each hash :
- if file changed => default action selected : update hash
- if file missing => default action selected : delete hash
- if file corrupted => keep the hash + possibility to check again the file (so I could recover the file from backup and make a check for this file specifically)
- if file is new => default action selected : add hash

Interface could be like "simulation" step in SynckBack for example :

Hoping it is a usefull request ;-)

Kind regards,
Nico

P.S. If there is a way to translate the software, I offer to translate it in French.

I do like the idea of having default actions based on error conditions, e.g. "if file changed => default action = update hash". I will look into adding something like this in the future.

It's unlikely an extra GUI will be involved; more likely it will be a simple ini setting/switch to control the behaviour.

Translation is already on my 2do list. At the moment there is no mechanism for it, but if all goes to plan, it will eventually be possible to add simple translation mapping files for any language.

When this happens, I will be in touch!

Thanks!

;o) Cor

frito - 02.11.14 6:03 am

First: Very NEAT tool! I like the site design too.

Second, I've got a question/feature req.: Is it possible to batch compare Renamed files (with the same content)?
I tried with verify but it is sensitive to the original file name (even if the checksum matches).

cheers
f

Thank you!

Yes, checksum is not only "sensitive" to the file name, it absolutely relies on it, and does a lot of behind-the-scenes voodoo to ensure any file it attempts to hash matches a required file listed in your .hash file, regardless of what path scheme was used, and where we are in the directory tree.

For checksum to predict user renaming would involve hashing irrelevant files (gasp!) to even know if a "hash match" was possible, which takes time. And then it would have to know somehow if that really was a renaming and not simply two identical files.

What is more likely to happen is that I make my renaming tool (MangleeZee) "checksum-aware", switching out the names of affected .hash files. Ideally it will search up the tree for any .hash files potentially containing the renamed file(s) and switch them automatically. I'm still thinking about it.

It's on the 2do list!

In the meantime, you can compare any two files (or folders) with simple checksum, which is installed alongside checksum. I keep a copy in my SendTo menu and often send two files or folders to it for a quick compare job.

;o) Cor

next comments (1 page)

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

Enter the 5-digit code this text sounds like :

lower-case ess, Upper-Case Eff, ate, lower-case en, Upper-Case Aye

Welcome to corz.org!

If something isn't working, I'm probably improving it, try again in a minute. If it's still not working, please mail me!