checksum preferences
get checksum working YOUR way.. (in-progress)

Mostly, these are explained inside checksum.ini itself, but a few of the settings perhaps require further comment. This page aims to more fully explain some of checksum's less obvious settings..

Introduction

All checksum's permanent settings are stored inside checksum.ini.

Settings are usually either an integer (number), a boolean (aka. "bool") which is true or false, or a string of some kind (i.e. a name). For the bools, as well as true and false, you can use 1/0, yes/no, y/n, and quite a few other variations on that theme, basically, use whatever you feel comfortable with.

Later settings override earlier settings, where applicable.

Command-line switches override everything.

Finding checksum.ini..

Because checksum can run in a number of configurations, checksum.ini isn't always in the same place. The easiest way to get to checksum.ini, is from inside checksum.

During any checksum operation, you can get to checksum's ini file via the ToolTip's context (right-click) menu as well as from checksum's system tray menu (right-click the checksum icon) selecting the Edit Prefs (checksum.ini) option.

Note: If checksum is hashing a very large file, it can become unresponsive to normal user input, which keeps hashing speeds nice and fast. If you want to get to the tray or windoid context menu, it's usually best to wait until it's finished.

If you want to get to it from Explorer, see here for instructions - a page all about checksum.ini

If you prefer to read text in your web browser, you can view the current checksum.ini file here online..

checksum.ini.. live

Overriding checksum.ini settings..

Some of the permanent settings also have a switch, which is a simple character, usually a letter, that you can pass to checksum by adding it to the command-line (via a Run dialog, script, front-end, etc.).

Those settings can also be disabled temporarily by prepending the switch with a - (minus) character. For example, by default, the progress tooltip is enabled inside checksum.ini..

progress_tip=true

but you could add -t to your switches to disable it temporarily.

If it was disabled inside checksum.ini..

progress_tip=false

you could enable it temporarily, by passing t in your switches. And so on.

For a full list of checksum's available command-line switches, see here.

Mail-On-Fail Preferences..

checksum can mail you about hash failures.

The Mail-On-Fail preferences are available from checksum's System Tray menu while the verification one-shot options window is open. Everything can be set from the prefs dialog.

About The CSS (aka. 'style sheets')..

Even without any styles, your logs will still be formatted, and have all the groovy expand/collapse action; they'll just look rather dull. To keep everything as funky as checksum is, takes CSS, aka. 'Cascading Style Sheets", so called, because styles cascade, later style sheets overriding earlier style sheets..

By default, the checksum log files will import three style sheets, in order; starting with a live sheet from corz.org (fall-back styles - should always be available, even if yours aren't), followed by your master style sheet (checksum.css, next to checksum.exe), and finally, any local style sheet, if you have one (in the log folder).

Exactly which style sheets load for your logs is completely configurable in your preferences, and only one sheet needs to exist for everything to look great. Logs can also be configured to have all their style information embedded inside them, if you prefer.

When you first run checksum, a default style sheet (checksum.css) should have been automatically placed next to checksum.exe. This is your master style sheet.

As the location of the master style sheet needs to be hard-coded into the logs, it's actually most future-proof to use checksum's program location, as opposed to any user folder (if you upgrade to Vista, you will no longer have C:\Documents and Settings, for a start). This also helps in portable mode, where checksum will intentionally forget what a user folder even is.

So, the master style sheet is next to checksum.exe. You can edit styles there if you want, and those changes will apply to all your logs (even logs already created on your system). Alternatively, you can copy checksum.css into your logs folder, and make changes there, and those styles will apply only to logs inside that folder. Or any combination of these things.

The style sheet preferences..

fallback_styles=true

Import 1 of 3. This loads the fall-back styles from corz.org. You can also enter the full URL or path to a fall-back style sheet, if you wish. For example, if you wanted to import the olive styles from corz.org, use..

fallback_styles=https://corz.org/windows/software/checksum/files/olive.css
master_styles=true

Import 2 of 3. This loads styles from your master style sheet. Again, as well as the boolean value, you can override the location by entering a full path, in this example a file system path..

master_styles=file:///C:/Path/to my/styles/checksum.css

Finally, comes local styles. These can either be in a file called checksum.css in the log folder, or else embedded inside the log file itself. The setting which controls this is..

embed_styles=false

Import 3 of 3. If you set embed_styles to true, checksum won't import local styles, but will insert the styles directly into the log, using your master style sheet as the template. Though you lose the many advantages of css @import, and your logs are larger, you do get completely self-contained, totally portable logs.

If you set fallback_styles to false, master_styles to false, and embed_styles to true, your log files will contain only embedded styles from your master template, which may be what you want.

With such fine-grained control over the importing of styles in your logs, it's possible to setup for all kinds of different scenarios, bare logs for on-the-road, different coloured logs for work and business, or whatever, as well as format and style them to your own personal requirements. Don't don't like the log's cool background image? Edit your CSS!

Read-only fall-back settings

When checksum is asked to hash files on read-only media, it obviously can't write the checksums to the volume, so reverts to a fallback strategy, and leaves them on your desktop, instead (or designated fallback folder - set in your preferences). There are different levels of fallback. Which level you choose depends on what you plan to eventually do with your checksums.

fallback_level=0

Level 0 fall-back simply carries on with whatever switches you are using, except inside the fall-back location. e.g. if you are creating folder hashes, you will find the read-only structures re-created inside the fall-back location, with a checksum file in each folder (otherwise empty), containing regular relative hashes. If/when the read-only volume becomes writeable, you can simply copy the folders over in one drag-and-drop, to merge everything into the correct folders. However, the default is..

fallback_level=1

Level 1 fall-back forces the creation of a single-file "root" type checksum file, with relative hashes for the entire volume (or whatever you are checking). This is fairly portable, and will enable you to use the checksums in a variety of ways, later; perhaps by dropping the file into a copy of the original volume, or if it becomes writeable, dropping it directly into the volume itself. If the location will never become writable, i.e. a DVDR or CD, you may want..

fallback_level=2

Level 2 fall-back forces the creation of a root checksum with absolute paths.

If you are hashing a DVD, or similar, and you are CERTAIN that the contents will always be at D:\ (or whatever drive letter you use), then you could enable Level 2, and the entire path, including the drive letter, will be inside the hash file, very much like using the absolute_paths preference (or k switch), except this will only kick-in in the event of a fallback situation.

With level 2, just like absolute_paths, you can store this checksum file anywhere, and it will always point to that same drive location.
NOTE: The fallback_level setting only applies to fall-back invoked by read-only conditions in the ROOT of whatever folder structure to are creating hashes for. If checksum discovers a read-only area while recursively creating hashes inside a normally writeable volume, it will recreate the inner directory structure inside the fall-back folder, using whatever method you originally specified on the command-line (basically, fallback_level=0).

In situations like these, you may prefer to create a root hash anyway, in the original root, then the inner (read-only) files could be checked in-situ, without the need for fallback.
If you think of other levels/strategies you'd like to see, let me know.