Unstoppable hashing of large directory leaves no option than kill explorer.exe

[Korkman]

This is a serious problem when tabbing through the tabs in properties of large (or otherwise slow to read) directories. Hitting OpenHashTab is a one-way ticket to either killing explorer.exe or waiting for a day for it to complete.

Please, please thread it properly and add a "stop hashing" button on the tab or give an option for a "start hashing" button.

(this relates to #31 and #116, but is less of an edge case)

[ThioJoe]

I think it would be nice to just be able to disable it for folders altogether. Or maybe for folders, it can first check the size or number of files, and if it detects a large amount, have a button that the user presses before it actually starts hashing.

[Korkman]

Or maybe for folders, it can first check the size or number of files

This operation would be potentially slow on its own, and would require a "stop calculating" button 😉

Actually, no buttons would be required if it was behaving well: entering the tab must not lock up the GUI, leaving the tab should stop the hashing in progress. That way one could simply tab through.

[namazso]

Please, please thread it properly and add a "stop hashing" button on the tab or give an option for a "start hashing" button.

It is threaded properly. It isn't the hashing that causes the lock-up, it is Windows adding the finished hashes to the list, after hashing is done on a couple of files. Not sure how I could solve this, as I certainly wouldn't want to develop my own gui element.

[ThioJoe]

I was imagining something roughly like this - just enough so it wouldn't be run accidentally. Not sure what would be involved in implementing it. The window seems to freeze completely, so I'm not sure if a "stop hashing" button would even work in the current state.

[namazso]

Correct, a stop button wouldn't work. However that click to start might, and could be exposed as an option.

[namazso]

Actually, in the current model that wouldn't work either because enumeration needs to be ran to know how many files we want to hash. This is the architectural issue I attempted fixing a few times but found a bit hard to completely pipeline everything.

[ThioJoe]

Perhaps there could be an option to disable the tab on folders altogether. For me it's kind of a dealbreaker that accidentally hitting the tab might freeze explorer if I have the properties window open for a folder.

[factor27]

I think you usually only want to hash recent files anyways. So maybe allow the user to set a recent time (i.e. last 24h) for files that auto-hash in a folder.

This requires reading the time of all the files, but you can add those files while the background thread finds/hashes them.

[Korkman]

Perhaps there could be an option to disable the tab on folders altogether. For me it's kind of a dealbreaker that accidentally hitting the tab might freeze explorer if I have the properties window open for a folder.

This won't address large VM files on a network share. It would lessen the risk, but not eliminate it. And some people probably do use the feature to hash a folder and don't want to hit the bug either.

I think you usually only want to hash recent files anyways. So maybe allow the user to set a recent time (i.e. last 24h) for files that auto-hash in a folder.

That would be an overly complicated way to fix this for some users.

@namazso The outdated HashCheck doesn't have this issue. It starts hashing on tab entry and presents a "stop" button. Maybe peek at their implementation to see how they solved it?

[Gorrrg]

Please, please thread it properly and add a "stop hashing" button on the tab or give an option for a "start hashing" button.

It is threaded properly. It isn't the hashing that causes the lock-up, it is Windows adding the finished hashes to the list, after hashing is done on a couple of files. Not sure how I could solve this, as I certainly wouldn't want to develop my own gui element.

Buffer the hash results and send them to the GUI at a slower rate while the file hashing goes on with max speed in a seperate thread. I imagine you are currently sending the results as soon as they are done. But with a rate buffer the list will fill up with hashes from small files not too quickly and when your hashing routine is working on a huge file the list will catch up quickly but then wait for the huge file to finish.

[Aonodensetsu]

I think adding a "hide tab for folders" setting as a temporary solution would be the best option while alternative - and perhaps better - solutions are invented, this way users that have a use for the functionality can choose to keep this bug in mind, while the rest of users that only need per-file hashes will be "free" of it

[Josephur]

It would seem to me if your threading yielded time back to explorer or ran at lower priority perhaps explorer could continue to function?