checksum tricks and tips
hints, 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.

 
an imagean imagean imagean image
 


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.

Image of a <SHIFT> Key, checksum's main modifier key

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

an image of checksum's one-shot hash creation dialog


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

checksum creation options dialog, file types group drop-down, regular Windows masks apply
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.
 
Image of a <Ctrl> Key, checksum's second modifier key

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.
 


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


Custom Explorer Context Menu Commands made easy..
custom Windows explorer context menu command

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.
 


checksum in your SendTo menu..

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

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.ini
working 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.
 
image of checksum icon/logo, in super-large 256 pixel size PNG!


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..
 
 
 
cbparser powered comments..

wraithdu - 19.02.09 5:14 pm

Hi there again. I have a request for your next version. Allow checksums to be verified against another directory. Scenario: I copied a large amount of files from a network share, I've hashed my local files, now I want to compare the hashes to the network share to verify my download. Currently a user has to copy the HASH file to the network location, or hash the network files and copy the HASH file to the local directory. Keep up the great work!


Tuwase - 25.02.09 6:37 pm

This is a Beautiful Site.


cor - 26.02.09 11:13 pm

Hi again, wraithdu. I'm looking at your post wondering what might be easier than simply copying the hash file over to the new location. It's a single-click and drag operation! If you can think of something easier, let me know, and I'll definitely consider it.

Cheers, Tuwase. People keep telling me this, but no one ever says, "Gee, Cor, your site design is so pleasing to my eyes, I'd like to donate you a hundred bucks!", sadly. smiley for :lol:

I think I'll put up a "comment thing" just for general stuff. Maybe right on the front page. That would be novel. Hmm..

;o)
(or


tessellated - 26.03.09 5:24 am

I would like to congratulate you on a very fine tool. Unfortunately for me, I seem to have hit a snag when using it with my NAS device. My OS is Vista x64 and I am using wifi (usually) to connect to my storage device. For very large files (say 10+GB but the threshold could be lower) checksum will run to completion and claim that hashing has completed at which point I lose all network connectivity on my PC (to the internet, the NAS device, and presumably anything else on the network).

Any idea what might be going on here?


cor - 26.03.09 8:50 am

Very strange. It sounds similar to troubles I used to have on my own network, transferring large files. If I remember correctly, a driver update on my network card fixed it.

It doesn't sound like a checksum error, as such, more to do with your network throughput. I'd wager that any application that tries to pull that same file over the network in one go would invoke a similar situation (mine used to crap out pulling Apache log files into my text editor, amongst other things). Though without more information, that could just be wishful thinking on my part. Have you tried another hashing application on the file(s)? Try something similarly fast, like fastsum; see what happens.

I'd like to have a lot more information about the errors you are receiving, before I consider it further. Does your system, or any other applications give some specific error messages? Can I see those? If there are none, try and do some ftp over the link and see what your ftp client says (often ftp clients give rather good network error messages). I'm assuming your NAS has an ftp server on-board. At any rate, more information is always better than less.

Also, has the hashing actually completed? In other words, is there a hash file at the end of the process? Or did that also fail?

Thanks for the compliment, though. smiley for :lol:

;o)
(or


tessellated - 27.03.09 1:53 am

I dug in to this a little more today and was able to resolve my problem. It was, indeed, a driver issue with my wireless card. I use an Intel wireless/PRO 5100 AGN. A simple driver update via device manager has made all my issues go away.

I did run an ftp test and it failed in a similar fashion (prior to my fix). Additionally, checksum was able to create a hash file, but it was of zero length. Fastsum, strangely enough, didn't suffer from this problem. It worked before I applied the driver update. I'm not entirely sure why that is. I suspect that it is a function of faster run time. Fastsum is limited to md5 and I prefer using sha1. I'm not sure if that incurs a runtime penalty with your program or not but my statistically insignificant tests indicate that Fastsum completed its md5 hashing ~10 minutes faster than checksum could complete sha1 hashing. That leaves about a 10 minute difference. That doesn't exactly leap out at me hugely significant (82 minutes vs. 73 minutes...) but it's hard to say. Anyhow, it's a moot issue now.

While I have your attention, though, might I suggest one possible change? I really like your "status bar" windoid. It is both functional and lightweight. Two properties I really appreciate. I think there is an opportunity to make it even more informative, however. During these especially long runtimes I must admit that I really appreciate a visual indicator of progress. Rather than making a clunky little progress bar window, how about instead make the windoid itself a progress bar with text overlay? I think this adds a little more information relayed by checksum without doing violence to the spirit of your design.


cor - 30.03.09 4:50 pm

Aha! Yes, it looked like a driver issue. I'm glad you got it sorted, you will probably find lots of network things work better.

As for the hashing speeds, considering that SHA1 hashing speeds are very much slower than MD5 hashing speeds, that's actually a great result for checksum! Think about it. Actually, if you really think about it, it's clear the bottle-neck isn't the so much the speed of the hash calculation, as the network link. I'm curious how long checksum would take to do an MD5 of that same folder.

As for your suggestion, do you mean long operations with many files, or long operations on a single file. If it's the former, then this might be doable, though could potentially make it tricky to see all the information (though I know some thought on that would fix it). If it's the latter, it would require completely re-coding my hashing engine, which is designed to just "get on with the job", without interruption, not handing back control until the task is complete. This kind of change is unlikely to be considered at this time.

I'm thinking about it, though. It's a nice idea.

;o)
(or


tessellated - 31.03.09 7:28 am

Ok, just for fun I ran checksum using md5. I'm afraid the result was less than illuminating: 87.9 minutes. These are very crude measurements as they completely disregard network traffic or the I/O load on the NAS device. However, I will say that in all cases I limited held my personal use of the device to zero, but that doesn't rule out background services, daemons, etc. Probably a much better test would be to copy the file to my local disk and run checksum against it multiple times using both algorithms.

Anyhow, I know you are right about the network I/O being the limiting factor because I attained much faster run times when the file was located on an external HD attached via USB.

RE: the suggested windoid change, I really just meant anytime there was very long delay in feedback given by the windoid, I found myself checking task manager for progress information. I think when you have the case of many files of short length, the user gets a fairly reliable indication of progress from the count of files thus-far processed. The shorter then avg. file length and the smaller the standard deviation from the average the more reliable an indicator this count is. If the change would cause a noticeable degradation in performance then I wouldn't want it as I have other means of tracking program performance (task manager's I/O columns work fairly well for this). I suppose if it were me (and I have no idea how you coded your engine) I'd use a separate thread for the windoid and then occasionally pass it progress info from the engine thread.

Even so, forgetting all of that and just turning your processed file counter into a visual color gradient would have utility.

Thanks, again for your helpful advice about the driver. This is a brand-new laptop, and I am still in the break-in phase.


cor - 28.04.09 8:05 pm

Apologies for the delay in replying; it's been crazy here, this must have slipped through.

Well, the times tell us one thing; test results on that system are not reliable! Interestingly, someone on the main page was commenting about checksumming over networks, and I had to admit that it's not something I saw checksum doing a lot, and didn't make any special consideration for over-network use - I was far more interested in being able to work with all the different formats of cross-platform hash files. All my (and my beta tester's) network tests passed without issue, I should add.

checksum is designed to load the data from the file system as fast as possible, and there probably are network setups where this could, if not overwhelm, then at least stress the networking components. Networking is always one of those areas where the mileage variables are stretched to their limits, and while there should theoretically be no issues hashing data over any network link; in practice, networks can contain many weak links, and I'd be more inclined to see checksum's behaviour as an indicator that other issues need attention. In other words, in an ideal network, there's no problem.

At any rate, checksum was designed to work with hashes from any platform, the idea being that file hashes are always created and verified locally, using whatever tools are locally available. Hashing over a network, if you think about it, is kinda backward, because the operating system will, at some point, need to pull that data over the network; to work with it; and it's AFTER that process that its integrity might need checking. The OS on the other box, that is the one best suited to checking its local hashes.

NAS sits squarely in the middle of all this, and perhaps demands special attention. I'll definitely be looking into this, checksum sensing over-network use, and perhaps altering its data reading behaviour slightly. Thanks for the heads-up.

As far as the progress bar goes, yes, I hear exactly what you're saying. My take on it is that verifying hashes is something that the computer does, not something *I* do. That there's a progress windoid at all, is an indicator of how far I'm prepared to compromise my integrity to produce usable software! smiley for :lol: Actually, I've considered this, and still am. It's in the "maybe" list.

Maybe in a future version. Once checksum has a million users and a team of coders!

;o)
(or


3picide - 17.05.09 3:52 pm

I just want to say how much I love your program. I'm a bit paranoid sometimes, so this tool really helps. Also, I've been working on a cryptology project and am proud to include an example in it using your program. If I had the ability to, I would definitely donate (and buy a shirt; I already have plenty for now, sorry).

I love all of the information about the tool on your site. It's pretty simple doing regular things, but it just makes me giddy seeing all of the capabilities that this amazing freewa--ahem, shirtware has to offer. I hope to see more amazing tools. You've done a great job!


cor - 17.05.09 6:36 pm

High praise indeed! Thanks!

Your wish is my command..   Believe it or not, I am, at this very moment, putting the finishing touches to not one but THREE  brand new Windows apps!

Although not released yet, their in-progress pages do exist, if you know where to look. smiley for ;)

And hey! I'm proud to be a part of your cryptology project! smiley for :D

;o)
(or


gheil - 19.07.09 10:17 pm

Lots of capability in this proggy!
Unfortunately it is a little verbose. It took me a half hour just undoing the commenting in the checksums.ini file so my editor could properly line wrap them. Unfortunately just about every especial case was exercised, that is why it took so long - very tedious.
\
When i was done there was no way to do what i wanted;-( To my way of thinking that option is obvious: what is the checksum for the ENTIRE directory?

To work around to it i had to:

1) create a file of all checksums recursively in a directory. (with a single file, don't know why this is not the DEFAULT)
2) rename the file from .hash so checksum would not ignore it
3) create a (sub)directory for each directory to be compared
4) hash the (sub)directories in 3)
5) finally do the comparisons

An option for a simple summary checksum would obviate this convoluted workaround...



Beavis - 20.07.09 9:34 pm

lol! what you wanted to do is built-in!


cor - 21.07.09 7:48 pm

smiley for :lol: I'm not so sure, Beavis!

gheil, It sounds like you are trying to use checksum as a file-compare utility. It isn't a file compare utility. Sure, it has certain applications along these lines, and you can even drag two files into simple checksum for an instant hash-compare, but checksum is strictly for creating and verifying checksums.

Your whole procedure sounds extremely convoluted. If you tell me precisely what you are trying to accomplish, I probably know of a better way for you.

;o)
Cor

ps. You can removed ALL the comments with a single regex replace in any decent text editor.


Wurzel - 22.07.09 9:24 pm

I have zero experience with checksums but here is what I am trying to accomplish.
I will be generating data files each day to a flash card. I need to be sure that the files are not altered.
Is there a way that the software can reside on the flash card and alert me if any file has been tampered with since its original creation?


gheil - 24.07.09 7:33 am

Cor

Yes i ended up using a file compare on two .hash files to see if they were identical. But that requires using another program...

What i need is a single number (eg a MD5) for an entire directory. Not one number for each file in that directory (recursively). For my purposes that file ended up being ~66kb requiring some kind of program to test. If there is a differing ordering of files in a directory a comparison program is confusing.



MrCyberdude - 23.08.09 5:31 am

Nice work on your app, will be better when you sort out the 4Gb SHA1 calculation issue.

What your app does not do that i originally downloaded it for is this.

I have 2 EXISTING folders say
C:\movies
Z:\movies.Backup

and they both have identical (un-verified) files in them.
I want to delete the original c:\movies as i have watched them but want to keep a backup.
How can i do this?

smiley for :idea: I was hoping your app had a right click compare folders/files option that shows differences.

These are measured in the TB so copying is not an option as they took backup jobs near 200hrs to do.
At the moment i am using ztree2.0(binary compare) to do this but,
its not a simple click option and i do not know what the crc/md5 method is.

I was thinking to run your check on both the 2 different folders to create the md5 hash files but then how can i compare both sets.

Your solution or Thoughts would be much appreciated.


cor - 23.09.09 8:23 pm

MrCyberdude, comparing files, just drop them both onto Simple Checksum. Job Done.

As for directories; I do this sort of thing a fair bit myself, like this..

  • Create root hash in folder A
  • Copy .hash file to folder B
  • Click .hash file

gheil, that simple technique will also work fine for you. Understand, you CANNOT checksum directories, per se. Only the files in them. If you really must checksum a directory as a single unit, you will need to tar/zip/archive it, first.

;o)
Cor


John - 30.11.09 7:32 pm

I downloaded the checksum but when i tried to upload it this was the message showed to me
"The Compressed (Zipped) Folder'C:Users\DELL\Downloads\checksum.zip' is invalid"
Though i am Just a beginner and really love to learn Hacking as a whole course of my Life.

I love it Please Help me out. with this as a start and i will be going on to be a STUDENT here. NO SHAME bro


mariannerd - 01.01.10 4:46 pm

my PC has died. It says the checksum files don't match (paraphrasing)and it won't boot. It takes none of my recovery disks and wants the whole Vista installation disk which I don't have.


 

leave a comment, become part of this site!


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

(if you find it difficult to read, refresh the page for a new code)


gd verification image

 
 
[site notice]

Stop-Software-Patents