[code65536]

You can get "unreadable" in other ways, too, though they are probably not as common as "missing". Try verifying a big file, and in the middle of that long process, delete the file and see what happens. Or try taking away the read permissions of a file before trying to verify it.

This post has been edited by code65536: 04 July 2009 - 02:04 PM

[gUiTaR_mIkE]

Quote

try taking away the read permissions of a file before trying to verify it.

This makes sense, thanks for elaborating. Why anybody would delete a file while they were verifying it
who knows but, they deserve an error message.

Mike

[code65536]

gUiTaR_mIkE, on Jul 4 2009, 04:19 PM, said:

Quote

try taking away the read permissions of a file before trying to verify it.

Why anybody would delete a file while they were verifying it

Well, that was just an example; there are countless other scenarios that might crop up. For example, a stuff on a shared network drive might be deleted or moved by other users, or the network itself might fail for some reason. A user might forget that there's a file hashing operation going on and unplug a USB drive containing the files halfway through. Etc. There are just too many possibilities of stuff that might go wrong, and that's what "unreadable" is.

[gUiTaR_mIkE]

I sure hope you didn't think I was questioning your reasons, I was only asking. Your first response was sufficient for me,
and I was only making a joke when I said "they deserve an error message for removing a file while it was being verified".

I'm sorry I bothered you - it really wasn't a criticism of the app.

[code65536]

It's fine; I wasn't sure if that was a serious question, so I decided that an elaboration was the safer route.

[rds_correia]

Hi there code65536,
Excellent tool and excellent features!
I do miss one thing: a green check mark right next to one of the hashes when I paste a hash which matches the ones found by hashcheck.
Although there is already a feature that highlights a matching hash I'd say that a green icon right next to it "à lá" hashtab would make it a killer app.
Speaking of hashtab, I wouldn't like this to turn into a hashcheck vs hashtab thread just because of my comparison but I have to ask this: is it normal for hashcheck to be a whole lot slower than hashtab when reading a file to show hashes?
I've made a lot of trials with both hashtab and hashcheck on their x86 versions (hashtab v2.3.0 vs hashcheck v2.1.11) and hashtab always wins and most of the times it wins for more than a couple of seconds per 20 megabytes hashed.
Am I using/installing hashcheck in the wrong way or is this ok?
I'm fine with hashcheck's speed but the hashtab speed comparison was inevitable and the results are quite conclusive.
Sorry 'bout that mate and keep up your excellent work on hashcheck and cmdopen.
Cheers

This post has been edited by rds_correia: 13 July 2009 - 01:48 AM

[kliu0x52]

rds_correia, on Jul 13 2009, 02:48 AM, said:

I do miss one thing: a green check mark right next to one of the hashes when I paste a hash which matches the ones found by hashcheck.

Where would such a checkmark go? Because HashCheck supports multiple files, the concept of a single match or non-match in the file properties dialog does not make a lot of sense. This is why there is no compare hash function in the file properties dialog--there is instead a search function, where you can paste in a hash, and if none of the files have a hash that matches it, it will report not found, otherwise it will find every file that has a matching hash (there might be more than one). A checkmark does not make sense in this multi-file context. If you are suggesting that a checkmark be placed in the results text box, that is not feasible because it is a regular text box, and not a "rich text" box, and there are performance implications to using "rich text", if there are thousands of files hashed and displayed.

In the HashVerify window, there is no graphical icon because of performance (for people who hash and verify large directory structures with tens of thousands of files, the use of graphics like that has a negative impact on UI performance and footprint) and because graphics are non-scalable and thus look rather ugly for users with a high DPI.

Quote

is it normal for hashcheck to be a whole lot slower than hashtab when reading a file to show hashes?

No, it's not. A lot of care has gone into HashCheck's performance and to make sure that it is at least as fast as all of the common checksumming utilities (HashTab, QuickSFV, md5sum, etc.). In my personal experience, the two are about the same in speed in most situations, with HashCheck being slightly faster than HashTab; I've never seen HC work noticeably slower than HT.

It should be noted that the most important factor in determining speed is disk access. If a file that HashCheck is working on is fully cached in memory, it can process the file at several hundred MB per second. If the file is not cached in memory, then it's limited by the disk access speed, which is usually around 30-100MB/s, depending on factors like disk speed, fragmentation, where on the disk the file is located, etc. In most use cases, HashCheck's worker thread is idle, waiting for the disk to give it data. HashCheck also uses a very large read buffer to minimize the effect of disk access overhead (this is especially apparent when comparing HashCheck against most other hashing utilities with data over a high-latency network drive; in certain exceptional situations, HashCheck can be over twice as fast than some other checksumming utilities).

Because the disk is the bottleneck in most cases, it is very hard to do direct comparisons because if you hash a file with HashCheck and then hash the same file again with HashTab, then HashTab will win because that file would have been covered by the file system cache the second time through. To ensure a fair comparison, one has to fully read the file, and then hash with HC and HT so that they both benefit from the file being in the cache. Or one has to do a lot of other disk access to try to force the file out of the file system cache (which, depending on the size of your system memory, may be several hundred MB in size) before each hash operation to try to ensure that neither HC or HT get the benefit of the file being in the cache (this may not always work, esp. if you also have secondary non-FIFO caching like SuperFetch). Or hash two different files with similar sizes, fragmentation, and physical location on disk (which is hard to control).

This post has been edited by kliu0x52: 13 July 2009 - 06:03 AM

[rds_correia]

Thank you very much for your reply, kliu0x52.
I don't use the check multiple file feature and that's why I never really thought about where to place the checkmark.
As for the speed issue, I just noticed that you're right.
It does have influence having the file in cache and it is why HC has been slower than HT.
It's because in my trials, I always try hashing a file with HC and after that I hash it with HT...
Dumb of me for not having noticed.
Cheers