checksum faq..
Questions people frequently ask about checksum, answered..

I want to upgrade!
But don't want to lose my settings!

Simply run the checksum installer and choose "Upgrade". When the upgraded checksum runs, your ini file will be automatically updated to include any new preferences and your current settings will remain intact.

Because it's checksum (and not the installer) that updates your ini file, it doesn't matter if you are running installed or portable, even if you simply grabbed the new version out of the zip; everything is completely automatic.

I've got no logs! What's up?

By default, checksum will only log failures, so if you don't have any failures, you won't get a log!

If you want to log everything, either a) pop-up the options dialog (hold down the <SHIFT> key when you launch checksum for the verification job) and check the log everything box, b) pass the "l" switch with the command, or c) set that permanently, in your prefs..

My logs are empty! What's that about?

If you do have a log, and when you load it in your web browser, it looks empty; that's because you need to expand the section, by clicking on the headers..

The main <h1> header toggles the entire log. If any sections are collapsed, they ALL get expanded; otherwise, they all collapse..

Clicking the log name <h2> header expands or collapses all the checksum files for that log (remember, you can append logs, so there may be a lot of these headers)..

Clicking the <h4> header that is the name of the checksum file, expands/collapses its hashes.

NOW you can see you logs!

Between the three toggles you can get your logs into pretty much any display state with one or two clicks. Hover your mouse over the header for some ToolTip-style help.

Note: If JavaScript is disabled in your browser (WHY OH WHY!?!?) then your logs will load in a fully expanded state, and you won't be able to collapse them out of view.

You can test all this with the sample logs, here.

Why don't the logs load with all the sections expanded?

When you have lots of logs appended to a single log file, loading with the sections expanded can slow down your browser, at least, if you have HTMLTidy and the SGML parser (part of the Web developer extension for Firefox) automatically checking all the tags on the page, it can. As they say, your mileage may vary.

Also, if you had more than a few log entries, and wanted to see anything but one of the first few, you would have to collapse them anyway, to get to the other entries. So instead, we start that way.

By default, checksum appends new logs onto old logs (so long as the log name matches), so it's possible to have HUGE logs with hundreds, even thousands of sections in them. These toggles enable you to quickly get to a particular entry.

Once you've played around with it for a minute, you begin to see the beauty of the system. Note: if you really must have your logs load with all sections expanded, simply use your own HTML template.

How do I use my own HTML template?

Simply put, if there's a file called template.html next to checksum, it will use it to create the logs. It's easy enough to create your own template..

• Open any HTML checksum log file in a decent text editor

• Delete everything after..

  <!-- end header template - checksum will take over from here. -->

• Save the document next to checksum.exe, name it template.html. Edit it to your heart's content.

From now on, any logs checksum creates will use this template. As well as the usual reasons, this is handy for folk using non-windows line breaks, you can create your template to match, though in reality, browsers won't care either way.

As to the earlier question of how to get the logs to load with all sections expanded; inside template.html, you'll see this..

Existing logs could be altered in exactly the same way, if you wish.

How do I use the Olive styles?

Inside the checksum distribution you will see an "extras" folder, and in there; extras/logging/styles/olive.css. Simply copy olive.css to your main checksum folder and rename it to checksum.css, replacing the existing file. That's it! From now on your logs will be Olive. There's also a copy of that css file here.

When I verify a DVD I burned, I get errors, but if I wait a few minutes and try again, I get success. What gives?

I believe this is a quirk of certain optical media/burners, and one reason why burning software's built-in verification is inferior (the other reason being the poor CRC32 algorithm used). Often it takes a few minutes for the dye layer to settle down properly after a burn (at least, this is my, and other's theory). Also, because of the way optical media works, you can get errors long after the burn, and if you try again right after, you get success..

Remember, checksum is extremely accurate, and even one single 'bit' of difference will throw up an error, so burn it right to begin with; when burning (and probably verifying) an optical disc, it is always best to do nothing else during the operation, to ensure your optical drive won't be interrupted in any way, particularly if your peecee is slightly older. If the files are very large (like movies), it's also a good idea to use individual checksum files. That way, if you only need to re-check one file, you don't have to check the whole disk to do it.

I should add; I used to see this quite a bit myself, but since I upgraded my burner, not at all. In fact, it's been months since I've seen a verification error at all, and I have a habit of throwing Nero into the background to do other stuff while I burn (I also upgraded my peecee since I originally wrote this page). Maybe it's time you spent fifteen quid on a new burner (hint: go to svp. now!).

My checksums are being created/verified rather slowly. What's up?

checksum is fast. If your hashes are being created slowly, something is wrong. A couple of important factors can affect the speed of checksum's operation. In my experience, aside from the obvious influence of disk and processor speed, the biggest slow-down is caused by file fragmentation..

If checksum can grab the whole file in one chunk, hashing is lightening fast. If it has to grab it from many pieces, scattered all over the disk, this can slow things down considerably. If the file was downloaded by some sort of p2p software; bittorent, eDonkey, etc., chances are it will be extremely fragmented, sometimes into thousands of parts, scattered all over the disk. Obviously this produces some I/O overhead, even waiting for the disk head to reposition.

If speed is most important to you, defragment the drive. The best way to defragment a (non-system) drive, is to move ALL the files off it to a blank drive, and then copy them back again. There are also many disk defragmentation utilities available; Windows has one built in. Although not so good as a copy-wipe-copy, a defrag will improve your disk access times greatly (you can also use defraggers to order your files in interesting and useful ways). Either that or just accept slower operation.

To give you an idea of the impact fragmentation can have, a 250MB movie file hashed on a clean part of my fastest hard drive takes just over a second and a half. In its original location it takes almost a full ten seconds to perform the exact same operation.

The moral of the story is; keep your disks checked and defragmented. It's a Good Idea to defrag at fairly regular intervals, perhaps on a schedule, set to activate while you sleep. This will speed up your whole system, not just checksum. For this task, I have recently become rather fond of JkDefrag.

If you want to defragment only a single file or directory (or more), contig is most useful - stick it in your Explorer context menu!..

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\contig]
@="Defrag Folder (with contig)"

[HKEY_CLASSES_ROOT\Directory\shell\contig\command]
@="cmd.exe /c contig.exe \"%L\\*.*\" -v -s"

Can checksum handle Unicode checksum files?

Yes. checksum can create and verify both Unicode (UTF-8) and ANSI checksum files. UTF-8 creation is the default, in fact; but if you prefer to create ANSI checksum files for some reason (perhaps to share with a user of an old MD5 utility), you can disable UTF-8 in the preferences.

Note: even if you disable UTF-8 hash creation, checksum still recognizes and checks either encoding, automatically. Music playlists and log files are also utf-8 encoded; the names of your Eastern European art films won't get mangled!

So, I've got a bad checksum.. my file is corrupted. What now?

It all depends on what and where the file is. If it's on a CD or DVD, you might try cleaning the disk, and copying the file over again. If lots of files on the disk are starting to show errors, it could mean a bad disk, or bad batch of disks, and certainly means it's time to get your data off there, and onto something more secure. Check the other disks in the batch - it could be time for a refund, or possibly a new burner.

If it's on a hard drive, you may have a chance to retrieve an earlier version from a backup (if it's your work, you have a recent backup, right?), or get the file again from the original source. This also means it's time to scan your hard drive for errors. If files are becoming corrupted, it could mean impending doom for your hard drive, and it would be prudent to backup all its data right now, run a low-level scan, before it packs-in completely. Marking out bad blocks is a fine temporary measure for a movie archive, but it would be wise to no longer entrust important data to the device.

If you got the file from somewhere on the net, chances are it's still out there; grab it again. If it's a multimedia (image/audio/video) file, it's possible that some of the meta-tag information has been changed (tags were updated since it was hashed) and the media itself is still perfectly fine. In that case, simply create a new checksum for the file.

Why is there a "cancel" button on the info dialog?

You mean the one you get when you launch checksum manually with no switches? Simply, it enables you to hit "Escape", and kill the dialog immeidately. Without it, you would have to click either "Yes", or "No". For most, that's just plain handy, but as the dialog has gotten so big these days, for users of screens smaller than 600 pixels, it could be essential!

Note, you can also click and drag that window around from any point in the window.

If I rename file, will that change its checksum?

No; a change in file name in no way affects the file's MD5 or SHA-1 checksum. However, if you have already created a hash of the file, it will no longer verify unless the file name inside the .hash file is also changed.