ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

HashTab Shell Extension

<< < (2/3) > >>

MilesAhead:
btw if using a checksum program implemented as a Shell Extension, such as on a Property Page etc., if it has an option to limit the feature to smaller files I would take advantage of the setting.  Anything that hooks Explorer and bogs can make the shell very flaky.  I did a couple of things as Shell Extensions and it was best to get it done and get out when hooked to the shell.

It is a cool feature to have the checksums displayed right in the property page though.   :Thmbsup:

xtabber:
Google Developer now provides only SHA-256 checksums, so if you want to check factory image downloads for Nexus devices (HIGHLY recommended), you need a hash checker that supports that.

MilesAhead:
Google Developer now provides only SHA-256 checksums, so if you want to check factory image downloads for Nexus devices (HIGHLY recommended), you need a hash checker that supports that.
-xtabber (September 07, 2016, 12:29 PM)
--- End quote ---

I'm sure there are plenty of exceptions.  With the number of free checksum utilities around I don't see the requirement to have only one or two at your disposal.  In C# all the various checksum routines are available.  But I doubt the md5 one is as fast as a C++ implementation from Code Project.  That is what I adapted.  The features I added were queuing of jobs and fast file handling.  In published articles for checksum routines the author is obviously demonstrating the checksum function(s) and wants the rest of the program to be simple and foolproof.  More like a proof of concept.  I have seen fast checksum programs where the file buffer is 1 KB on the stack.  I don't fault them for that.  The allure of the article and code is to start with a working base and enhance it after all.

MilesAhead:
A feature of MD5Hash that I forgot to mention.  If md5hash.exe is run with no argument on the command line, it does not participate in the "single instance" behavior.

Let's say you have a copy of md5hash running processing 2000 files because you right clicked on a folder to process it.  Now you have a big video file you want to check but you do not want to wait for the 2000 file queue to empty.  Run md5hash.exe with no argument(not using Explorer context menu either) and when it comes up, either type in the name of the file or drag and drop the file on it.  If the new file is on a separate drive that happens to be an SSD then it should zip along pretty well even though the other copy of the exe is processing 2000 files.

IainB:
... if it has an option to limit the feature to smaller files I would take advantage of the setting.  Anything that hooks Explorer and bogs can make the shell very flaky. ...
_________________________
-MilesAhead (September 07, 2016, 11:02 AM)
--- End quote ---
Yes, xplorer² can give a column showing checksum, and I use it fairly frequently, so I have that column displayed in most of the pane layouts that I use. I find it very handy - e.g., when comparing file versions in the archives - but the user needs to set a lowish limit to the max file size for hashing, otherwise it can engage the CPU/HDD too much and impact screen display/refresh rates with all that computing overhead going on. That overhead is multiplied, of course, the more files you have in a folder, so I employ a pane layout without the checksum column for those folders with lots of files.
When I want to check the hashkey for a larger file, I prefer to use the HashTab Shell extension, as that seems to function only when you invoke that Tab in the File Properties view, and it seems pretty efficient.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version