Safehash

From EMule Wiki

Revision as of 20:31, 28 November 2008 by AUG (Talk | contribs)

Safehash is a viarion of the old filehashing, so the hashing is done in a different thread instead of blocking the gui.

Official implementation

Safe Hash:

Gaps are clipped to the file size when loaded. If the part file size is smaller than the expected size then the gap in the end is added in the case it's not already there(Can be caused by crash while flushing the buffer, or by outside modifying if the part file). Gaps are also added in a more controlled manner, which completely prevents gap overlapping(fixed, eMule 0.29).
Fixed possible bug that only checks the first chunk of each written block for completion, even in the unlikely(but possible) case that two chunks are written to and completed at once(fixed, eMule 0.29).
Added check when loading the part file to make sure the part file size doesn't exceed the desired size(In case it was enlarged by outside modifying). Prevents bug with both file completing and initial hashing(fixed, eMule 0.29).
Loaded hashlists are not assumed to be valid, and are checked against the file hash. Prevents a case of using a corrupt hashlist due to part met file corruption(fixed, eMule 0.30).
Closing eMule while files are still hashing no longer causes any crashes, and all threads exit quickly and safely(fixed, eMule 0.30).
Only one known file is hashed at a time(fixed, eMule 0.30).
Refreshing the shared files while files are hashing no longer causes these files to be hashed twice(fixed, eMule 0.30).
Fixed handling of files which divide evenly into chunks, meaning the last chunk is 0-sized, to be compatible with eDonkey's protocol(fixed, eMule 0.30).

Moves the hashing of finished parts to a separated threads what reduces GUI lock downs and increases the overall performance.
It adds a separated list with parts confirmed correct that is used instead of IsComplete to prevent just finished but not verified parts form being uploaded till they are verified.

SaferHash with JobQueues based on Sluggfiller's SafeHash

JobQueue 1: Using a JobQueue for harddisk-access Threads except for hashing of just downloaded parts and buffer-flushing.
User can decide how many jobs are processed simultaneously (1..10, default: 1)
Added 'Hash Jobs' list to Server-Window to show the waiting jobs
JobQueue 2: for hashing of just downloaded parts and buffer-flushing another JobQueue which allows 10 simultaneous jobs is used.

Based on Sluggfiller's SafeHash, implements one hashing thread per file instead of one thread per part, it also simplifies the thread communication.

Hashing Priority: the hashing process is a resource hog task. You can set different priorities for it, but take in account that a lower priority will give you a more responsive system while the hashing process will last a little longer.