# 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 (currently MD5 and SHA1), 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.

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 is 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: If you drop a file onto the create options, the path is inserted into the path: input, and though the file mask remains *.*, the file name is also automatically added to the file mask drop-down, just in case you really do wish to only hash a single file.

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

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

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 synchronise 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 the funky progress tip, dialogs 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 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 synchronisation, 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 folder/disk, then copy the .hash file over to the second and click it.

That's it!

## 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 fallback 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 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
Individual hash files (one per file).
s
Create SHA1 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)
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 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)
b
Beeps. Enable audio alerts (if disabled in your prefs - override it).
t
ToolTip. Enable the progress ToolTip windoid (if it is disabled in your prefs - override it).
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).
a
Only verify these checksum files.
(followed by algorithm letter: am for MD5, as for SHA1 - see example below).

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

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

In other words..

global switches = b, n, o, q, r, t.
creation switches = 1, 3, c, e, h, i, k, m, p, s, u, y.
verify switches = a, f, g, l, v.

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: ]

### 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), and the a switch must  be the first letter of a two letter combination, e.g. am
• You don't need to specify the m(music) 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 know how; feel free to demand an answer, below..

## Welcome to the comments facility!

Ricard - 24.05.12 5:23 pm

Hi Cor,

About a month ago, I told you that the soft was not working with Shift or Ctrl keys before launching. Still the same :-( I am using an HP Pavilion with 8 Gb Ram, Windos 7 and no success. What I want is to generate hash files for a number of files in a folder to compare with another one. What I mean is that if I have 100 files in folder A and 120 files in folder B, I want to generate a hash file for each one of the files in each folder to compare them later. How can I achieve this (with command line I mean) provided I can't launch the program eny other way?

Ricard - 24.05.12 5:45 pm

Hi Cor,

Just tested in Windows XP and it works normally. Any suggestion?

There's no reason it shouldn't work perfectly on Windows 7, as well. No one else has reported any problems with this and my first instinct is to say, "Are you SURE?". You are holding the modifier keys down until you see checksum, right?

As for the folder compare, checksum isn't really designed for this task, but creating a standard checksum file for the folders (standard right-click on folder, choose "Create checksums") is all you need. To compare with another folder simply copy over the .hash file and click it.

;o) Cor

Alex - 24.05.12 8:47 pm

I have been using checksum to verify files i archive to my LG NAS N1A1. When i run verify on a local file on my computer, checksum works very fast like it is supposed to. But when i run verify on a copy of the file over the local network which resides on my NAS box, it takes forever. Why is this and is there anything that i can do about it?

The limiting factor in checksum's speed is invariably file i/o. Even on a local file system, it's unlikely you will max out your CPU doing checksums, the disk read/write speed will slow things down. On a network, this is even more pronounced.

Basically, anything you can do to speed up your network (and there is usually a lot you can do), will speed up checksum. It's waiting for data from your NAS. Check your network settings thoroughly, and consider gigabit ethernet (compared to a modern hard disk read, even a super fast LAN is DEAD SLOW). checksum won't be the only program that will benefit from improved network speeds.

;o) Cor

Ricard - 25.05.12 11:15 am

Hi Cor,

Everything working fine now! Just that I did not press the key until the interface appears. You should emphasize that the the user must press the key until checksum appears. Otherwise, dummies like me will be doing the idiot around for a while

Thanks a lot. I will purchase a shirt, sure!

Noted. I will make the instructions more clear. Thanks! ;o) Cor

Ricard - 25.05.12 11:39 am

Hi Cor,

I have done several copies of DVDs to hard disc. Now, I want to compare each DVD with the correspondent folder. How should I proceed to compare both? For each folder I can generate a hash file but how do I proceed with the DVD as it is read-only. And, once generated the hash file for both, how do I compare them?

You can simply run a normal Create checksums.. Explorer context menu command on the folders on the DVD drive. Because it's read-only, checksum will create a folder on your desktop (or other chosen location) and create any .hash files in there.

The entire structure will be recreated, so you can simply drag and drop the whole thing over to the copy, if need be. Verify normally with the Verify checksums.. command.

Remember, if you have already hashed the copy, you will need to rename one of the (sets of) .hash files or else copying over the directory structure will overwrite the copy's .hash files!

So it's best to simply begin with hashing the DVD. If all goes to plan and there are no errors when you copy the .hash files over, your DVD .hash files can become your copy's .hash files! Job done!

checksum has a number of configurable methods of dealing with read-only fallback conditions, as well as a myriad of configurations for .hash file naming, so if this is something you do a lot, you will probably want to drop checksum.ini into a decent text editor (one with syntax highlighting) and have a scroll.

By the way, nice shirt!

;o) Cor

Ricard - 25.05.12 3:43 pm

Hi Cor,

Thanks for your answer. By the way, I can't find the file checksum.ini. I have registered with the program itself but I have been looking in the corresponding folder but there is no checksum.ini (and I have done a search in all the PC of course). Your advice would be great.

Thanks and regards.

See here (recently updated).

As well as the absolute best way to get to checkusm.ini, there's also a link there ( and right here! -> ) to the brief checksum.ini page.

Have fun with those prefs!

;o) Cor

Ricard - 31.05.12 6:32 pm

Hi,

I have copied several DVDs to corresponding folders in hard disc. Now I want to compare DVDs to folders. What I would like is to have a unique file hash for all the DVD or folder (not a hash file with a list of file hashes in it). This is because each DVD has about 17.000 files. Is there any way to do so?

And another thing. Is there any way to make the process faster because to generate the hashes for a DVD it takes about an hour and a half. I have 78 DVDs, so it will take me about 14 days working 8 hours a day :-(

Thanks in advance. Congratulations for the software and best regards.

It would have been smart to hash the folders before they were burned to the DVD.

As it is, simply hash the disk as normal, perhaps with a root hash file, and then copy that to the hard drive folder for verification.

And what's wrong with having a .hash file with all the files in it? 17,000 files is no problem for checksum. I've got .hash files with hundreds of thousands, maybe millions of entries (I know for a fact my local archive drive .hash has over 750,000 entries).

File hashing is a superior system fo disk (image) hashing -- if one single file is damaged, with a disk hash, you have total checksum failure and no way of knowing which file is damaged. Ouch! It's a lot easier to locate and renew one single file than 17,000 of them!

As for making it faster, checksum will hash the disk as fast as your operating system can read it. My workstation is ancient and I can hash a DVD in a few minutes - it sounds like you need to upgrade your DVD reader - it will only cost a couple of man-hours or less for a decent fast model. Think of the savings!

By the way, I recommend Pioneer for DVD drives.

;o) Cor

FredMora - 31.05.12 7:16 pm

I second Ricard's request.

The "tip and tricks" page describe how to checksum a burnt CD or DVD by first dumping the media contents in an ISO file with ImgBurn, then using the corz checksum utility on the ISO file.

One really cool feature would be to bypass the need for ImgBurn, and directly create or verify the checksum of the bytes on the burnt volume.

Thoughts, Cor?

Check out my response to the comment directly above this one. It's not a practice I would encourage - just hash the files!

For those that really need this sort of functionality, ImgBurn is an excellent program, beautifully simple and intuitive to operate, but with all the advanced features a geek could need. If you have a DVD drive or ever handle disk images, it's an essential tool for your kit-bag.

;o) Cor

FredMora - 06.06.12 8:28 pm

Hi Cor,

Check out my response to the comment directly above this one. It's not a practice I would encourage - just hash the files!

Actually, I sometimes use a Windows machine to handle ISOs that are not meant to be mounted on Windows, such a Linux-created ISOs. These ISOs often contain file paths that are too long to be read by the Win32 API, and thus, the file hashing is not reliable. However, the checksum of the full ISO is still possible and meaningful. Hence my request.

Thank you,

--Fred

In that scenario, hashing the ISO makes sense. I have many ISO .hash files myself. And of course, if you have access to a Linux system, you can mount the volume and use checksum for Linux. But wherever possible, hash files, not disk images. ;o) Cor

Hi Cor,
Great App!. So far I have been able to do nearly everything I want with it, only one thing is missing. The ability to make a single file hash with absolute path. Maybe I missed a switch or a combo of switches, I just cant make a single file hash with absolute path. I hope this is a "lack of reading on my end" type of post, if not then I guess it's a request type

Absolute paths is only available when creating a "root" hash file, i.e. a single .hash file for an entire directory structure. It doesn't seem sensible to do this in any other context, though I'm open to suggestions to the contrary. ;o) Cor

Hi Cor,

Here is my scenario.
I hash files on my PC's internal hard-drive with a copy of the 4 level directory structure of my two archive drives (one is redundancy). Some hashes are complete directories, others are single files. I then transfer to the archive drives. I check the hashes to verify good transfer. All my hashes are put in the root of my archive drives for easy referencing of the files. I put a copy of the hashes in a backup folder for peace of mind (I use a little app that adds the drive letter to the hashes in just a few clicks). I also append all new hashes to a master hash file for the whole drive (I am aware of Checksum's synchronization feature, but that means rehashing the new files and that is extra work/time I can easily do without). I can thus check the whole drive, if I need to transfer the whole drive (or to verify drive health) or just check one single hash when I need to pull just that file from the archive, all the while having a functional backup of the hashes.

Presently, I am adding the paths manually, until I find a better solution, quite tedious work.

I fully understand that this doesn't seem sensible (my wife is always telling me that I am not sensible enough, go figure!). Adding paths to single file hashes is only good if you don't want your hash files in the directory your file is in. I am guessing most people are content with the hash file right next to the hashed file. Unfortunately, that is not my case. I hope this is enough to convince you, if not, the search goes on. I would really appreciate an all-in-one hash tool for my needs.

Thanks for listening!

Have a great day!
Cheers,

Take a look at checksum's "Root" hashing. You can hash the entire drive and have the checksums in one single file in the root - that's how I hash my own archive drives. If you also use absolute paths, you can keep the .hash file wherever you like.

I guarantee you will save time compared to your current method, because you don't have to *do* anything, at least not manually. Let checksum do the leg-work!

Also note, during synchronization, there is no "rehashing", only files that do not already exist inside the .hash file will be hashed. Existing hashes are ignored.

I can certainly look into adding absolute paths for all contexts, but I think if you try letting checksum take care of this you will save yourself a lot of hassle.

;o) Cor

### (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 dbl-u, Upper-Case Zed, thuree, lower-case you, Upper-Case Bee

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!