Timeout during hashing process

[KL-sw]

Feature Description

Prevent freezing of the overall hashing process by implementing a timeout.
If this occurs, skip the file being processed and display a popup window at the end of the hashing/comparison process with a list of all the files that have been skipped.

The timeout may be rather long by default (even up to 10 to 30 minutes would be acceptable).
Alternative: implement a configurable timeout time.
Alternative: use statistics on the longest normal hashing process / estimate the system operating speed by measuring the normal execution speed on several files of X MB and then extrapolate the timeout treshold at 10x the time it would normally require to process a file of e.g. 4GB

[qarmin]

If I understand correctly, you are facing a freeze issue.
There is no safe way to stop a long, blocking operation once it is executing, even if it is running in a separate thread.
The only possible workaround would be to fork the problematic library and add periodic checks for a stop flag, but even this does not provide 100% protection.

The only real way to fix this is to fix the issue directly in the broken library, most likely image-rs or one of its derivatives. First, the problematic file needs to be identified manually by narrowing down the set of scanned files(with trace logs, checked file should be printed to logs). Adding a new method to track which file is currently being processed is not really feasible, due to the added complexity and limited usefulness outside very specific cases. I tested these libraries using a fuzzer to prevent such situations, so nowadays almost no one encounters these issues.

[KL-sw]

I suppose I'm the only unlucky guy with a messed up picture library who cannot easily locate the problematic file.
Seriously, if I encounter this situation, someone else will also have the same issue, but just might not have taken the time to report it.

Also, any process/subroutine that is started can be technically be shadowed by a parallel timeout monitoring process.
If such timeout condition occurs, it should be possible to kill the frozen process/subroutine.

I also opened another feature request (#1772) to actually allow to identify the problematic file.
I created 2 issues since these are 2 different requests: 1x with a goal to identify the problematic file, 1x with the goal to allow the overall comparison to complete 99.999% of all files.

I agree that the identification of the problematic file has more priority as this could eventually be uploaded to find out why the hashing process is freezing on the specific file.