CHK - integrity / hash checker

[encode]

Check out my new file integrity checker/hash calculator:
http://encode.narod.ru

Direct download link:
http://encode.narod.ru/chk103.zip

Key Features

• Optimized computation of CRC32, CRC64, MD4, MD5, SHA1, SHA256 and SHA512
• 100% portable - no installation or DLLs needed!
• 100% FREE!

[Midas]

Does what it says on the label. Simple and sweet.

Since the 'about' dialog says it's Beta software, maybe the designation should reflect this. Two further suggestions: you might want to add/document a command line interface for easier automation; those column headers could be made hide-able/drag-able for fast interface customization...

[webfork]

Very cool. Thanks for posting.

Few questions:

* You mention speed, but have you done any speed tests in comparison to other hashing tools.
* Any chance it'll do recursive checksums and verification?
* License? Is it OSS?

[guinness]

Tested: Portable

Saves no settings, slightly strange when it provides options such as toggling the view, could you explain as to why encode? Thanks.

[encode]

Tested: Portable

Saves no settings, slightly strange when it provides options such as toggling the view, could you explain as to why encode? Thanks.

To not modify the Windows Registry and not create config files. Probably, in future releases I should add the config file, but still CHK must be able to run from non-writable media.

Very cool. Thanks for posting.

Few questions:

* You mention speed, but have you done any speed tests in comparison to other hashing tools.
* Any chance it'll do recursive checksums and verification?
* License? Is it OSS?

1. I did many comparisons during development - CHK is much faster (up to a few times) compared to a number of GUI-based hashing tools. The speed is the number one priority to me. Although my compiler (C++ Builder) is far from fastest, I've done lots of hand tuned optimizations. Even OpenSSL code is slower than mine on this compiler (since some OpenSSL "optimizations" simply degrade speed with BCB compiler). So, CHK is bloody fast, but some command-line hashing tools compiled with Intel C++ can be faster... Check it for yourself! And yeah, it's probably a good idea to add some speed comparison on CHK's homepage.

2. For recursive processing just drag a folder from Explorer to CHK's window! "Drag item(s) here" means not just files, but folders and even drives as well! Multiple file verifying not added yet. But it can be done using other hashing tools such as RHASH. Using CHK, save hash list as a text file and run "rhash -c NewFile.txt", as example. You can even use any hash type (except CRC64, RHASH has no such hash yet), RHASH will automatically determine hash type and test the files!

3. It's a Freeware and a closed-source thing. No exact license type - kind of Public Domain - just use it and share it (in unmodified form!) as you want with no restrictions. At a moment I see no reason to make it open-source.

[guinness]

To not modify the Windows Registry and not create config files. Probably, in future releases I should add the config file, but still CHK must be able to run from non-writable media.

To check if a folder is writeable then look at DeviceIoControl.

[webfork]

Check it for yourself!

Tested this program against a few other hash tools on the site with SHA-1. My unscientific test was done with a 5 yr old dual-core intel processor. Did a very basic test under WinXP SP3.

Results: FileVerifier++ appears to be the winner. Results on newer architectures could be dramatically different.


TEST 1: A 45 meg system file:

• Hash: 1 second
  FileVerifier++: 1 second
  CHK: 3 seconds
  Fsum frontend: 5 seconds

TEST 2: 3 different 180 meg files from an external flash device.

• FileVerifier++: 1:15 seconds
  CHK: 1:30 - also ran into a problem -- seems to flinch during the process (no progress bar and the window is unresponsive)
  Fsum Frontend: 1:24
  Hash: 1:34

[encode]

A quick note. On modern/adequate hardware the main bottleneck is the disk read time. As example, on my machine (Core i7-2600K @ 4.6GHz, Corsair GT 240 GB SSD) the CRC32 computation of 1 GB file takes 2 seconds, computation of MD4 for the same file takes same 2 seconds! (I/O bounded) So, be aware of testing speed from slow USB flash drives and such...

[webfork]

A quick note. On modern/adequate hardware the main bottleneck is the disk read time.

Easily possible -- test was very basic.

[webfork]

A quick note. On modern/adequate hardware the main bottleneck is the disk read time.

Easily possible -- test was very basic.

Anyone have any suggestions on how to run a test like this effectively?