Jump to content

[Release] HashCheck Shell Extension 2.1.11 (32/64-bit)


code65536

Recommended Posts

2009/03/17 - 2.1.8.3

  • [Bug #81] [Localizations] Portuguese is now available as pt-PT in addition to pt-BR. (translator: "LPCA")
  • [Bug #84] [Localizations] Updated French translation. (translator: "mooms")
  • [Bug #85] [General] Exchanged positions of the font button and preview in the options dialog.

2009/03/02 - 2.1.8

  • [Bug #54] [General] Fixed a problem in which the Windows file picker dialog would maintain an open handle on the directory to which a checksum file was saved.
  • [Bug #59] [Localizations] Added Romanian translation. (translator: Oprea Nicolae, a.k.a. "Jaff")
  • [Bug #65] [General] MD4/MD5/SHA-1 checksum files will now have the '*' flag set for compatibility with third-party checksum verification programs that look for this flag.
  • [Bug #66] [Localizations] Added Italian translation. (translator: "Botta")
  • [Bug #77] [Localizations] Added Traditional Chinese translation. (translator: Jack Chang)
  • [Bug #78] [info] 2.2/3.0 roadmap update.

Edited by code65536
Link to comment
Share on other sites

  • 3 months later...

2009/06/07 - 2.1.9

  • [Bug #161] [installer] Improved the way in which the uninstaller deletes the DLL.
  • [Bug #180] [Localizations] Added Czech translation. (translator: Václav Veselý)
  • [Bug #183] [Localizations] Fixed a bug that prevented the Traditional Chinese translation from working under NT 6+.
  • [Bug #194] [Localizations] Added Swedish translation. (translator: Stefan Friman)

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
2009/07/01 - 2.1.11

  • [Bug #184] [installer] On Windows 7 RC and newer, Windows will no longer incorrectly display the "This program might not have installed correctly" message after installation.
  • [Bug #202] [HashSave] Fixed a bug that prevented HashCheck from appearing in the context menu when invoked from Total Commander on versions of Windows prior to Vista.
  • [Bug #203, #204] [Localizations] Added Russian and Ukrainian translations. (translator: Yurii Petrashko)
  • [Bug #205] [installer] Moved the installer's UAC elevation to right before the actual installation, instead of when the installer is first launched.

Link to comment
Share on other sites

Thank you for your efforts with HashCheck - love the utility for sure! :yes:

I do wish you would change "UNREADABLE" to "MISSING" - this is more appropriate for the file state if

I understand this is the only condition for "unreadable" ie; the file is "missing". Regardless, HashCheck

is a great tool.

Mike

Link to comment
Share on other sites

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.

Edited by code65536
Link to comment
Share on other sites

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. :hello:

Mike

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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

Edited by rds_correia
Link to comment
Share on other sites

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.

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).

Edited by kliu0x52
Link to comment
Share on other sites

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...