Thanks for the bug report, Cornucopiae.  Please retest with the latest version and let me know how it goes.  I also added the ability to specify a custom listview font.

Website | Download
v1.2.0 - 2014-03-13
   + Added ability to specify the listview font in the Options menu.
   ! Zero-byte files weren't handled correctly for MD5, SHA-1, and
     SHA-256 hash types.  (Thanks, Cornucopiae)

This is a very good program. Thank you.
it would be nice to implement the ability to select multiple rows together.
It is very difficult to select hundreds of lines separately

This is exactly what I meant. Thank you.
I found a little error.
The first row is not possible to be checked when you first time (after program start) use "check selected items"  feature.
[attach]

Hi, enone, and welcome to the DonationCoder site. 

Thanks For That Nice Tool
...I'll Ask If It's Possible To Add .ZIP File CRC Check

Thank you for your kind words.  Unfortunately, I'm not familiar with the Zip File CRC check as you're describing it.  Can you provide me with more detail (or an example)?

I've been using this again recently and I've discovered 2 (possibly related) bugs:

• If you clear the list while it is verifying files, it will keep verifying files. Or at least the one it was working on.
• If you delete a file from the list while it is still verifying files, it will not update the correct rows.

On that last one, what I mean is this:

Say I have 10 files I'm verifying. And it gets through the first 5 and is working on #6. But I realize I don't care about #4, so I click on it and press Delete. Well, now #6 is #5 and #5 is #4, etc. But when it finishes verifying the file, it will write the data in the 6th row.

@Deo:

Website | Download
v1.2.5 - 2014-12-10
    + Disabled most GUI elements when a scan is in progress.  (Thanks, Deozaan)
    + While a scan is in progress, the menu bar will reduce to a single Cancel
      menu with a Cancel option.

I found another bug:

If I click Load directory for md5 checksums, then click Load Directory for files to check, it will add an extra \ to the path if I load from the root of a drive, and will therefore consider the file to be "new" instead of matching it to previously saved checksums.

[attachimg=#]

And now that the GUI is disabled while verifications are in progress, this includes the scrollbar, which means if you are scrolled down (or up?) then you can't see the results of scans as they're happening, other than the status bar at the bottom of the application. It would be nice if the application would keep the most recent results on screen by scrolling the list automatically as checksums are verified.

I have a few feature requests... Apologies if they've already been asked for.

1. Do not remember "full screen" as the last used resolution. It's a bit annoying when the program starts up un-maximized but still takes up the entire screen.

2. Faster skips for files with saved checksums. It takes over 10 mins to go through 10k or so files that already have saved checksums when using "verify new files only" (Win 7 x64, Core i5, 8GB RAM, 7200RPM Seagate drive). I'm not sure why that is---if this is all in memory, it should very fast. If GUI is the issue, update it less frequently?

If this is not possible, then it'd be nice to enable saving an SFV without reverifying or skipping files that already have saved checksums. That is, the SFV is generated using "checksum" where possible and "saved checksum" otherwise, throwing a warning only when neither "checksum" nor "saved checksum" exist. So for example, if I load an SFV, I can immediately save it with no warnings. (Right now, it warns when "checksum" fields are empty, even when "saved checksum" is present.)

My use case is CRC'ing an entire drive and occasionally appending/adding CRCs of new files by first loading an existing SFV and drag-n-dropping the drive (or its folders). Ideally, files already with checksums can be skipped very quickly. If not, I'd (want to) sort by saved checksum, calculate it for the new files, sort by filepath, and save a new SFV without reverifying/skipping the existing ones.

3. Allow the comment to display "This file has been modified" when a file's modified timestamp is later than the SFV's creation timestamp. If the timestamp metadata is pulled together with file size when scanning files, there should be no performance penalty. Though, I'd understand if you think this bloats the program in a negative way.

Thanks for all your hard work.

Both these items should be addressed in the latest version I just uploaded.  Please test and let me know.  Links at bottom.

Thanks, they both work great. It's much faster now!

The timestamp data is not currently pulled for each file so I'm not certain how much cumulative time this would add.  So, how important is this feature to you?

It's nice-to-have but not critical: the drives I'm CRC'ing are largely append/read-only, so it's not too hard to sift through the bad CRCs and figure out if it was because the file changed. I guess if most of your files are always changing, stale CRCs will be pretty useless.

I haven't ever developed in Windows, so my guess was that if it were anything like Unix, where stat-ing a file will give you a struct with both file size and timestamps, it wouldn't add any disk overheads (since you're already scanning for file sizes). If that's not the case, it'd probably take twice as long in the worst case (an additional scan, no caching).

I just noticed that the "Total" bar is broken. It either doesn't update at all or, when verifying newly added files, gets stuck in a partial state (bar never goes to the end). It was working fine in 1.2.6.

Sorry about that.   

Website | Download
v1.2.8 - 2014-12-27
    ! Total progress bar was broken in the last build.  (Thanks, xviruz)