aMule Forum
English => en_Bugs => Topic started by: Schuttwegraeumer on September 15, 2009, 05:12:34 PM
-
If aMule is finishing a file and during the hashing other files are finished too, the aMule hashes all this files and THAN finishes all files.
If aMule crashes befor all files are finished, after the restart all of the (green) files must be hashed again.
-
Are you sure? According to the source, one file is processed after the other. Of course, if the first file is still hashing, several others finish transfer meanwhile, and then aMule crashes, then all have to be hashed after restart.
-
A typical situation here.
The green marked files becomes more and more during the hashing.
and than a crash is interupting this procedure.
and after restart all files muste be hashed again.
If more files are with green bar all must be hashed befor all together will be finished.
-
The green color only means "download is finished, file is queued for hashing" in your case. If hashing is completed the part and part.met files are deleted and there's nothing to hash on next startup anymore. Your files are not rehashed, they were never hashed at all.
So the only remaining question is - why does it crash? Backtrace?
-
The green color only means "download is finished, file is queued for hashing" in your case. If hashing is completed the part and part.met files are deleted and there's nothing to hash on next startup anymore. Your files are not rehashed, they were never hashed at all.
During the hashing the green files becomes more and more.
I hade to stop downloading to stop this effekt and removing some of the complete but not finished files to hash only one file at once.
So the only remaining question is - why does it crash? Backtrace?
One freeze of aMule without a trace and 2 system freeze becaus the drive is a dm-crypt and the system is very old and not very powerfull and slow.
Hahsing need much CPU power if the files are on a ancryptet drive.
And if the crash happens bevor the last files is finished all of the green files are in the download list after restart of the amule and the hashing is starting at the first files again.
If ALL files are hashed all together where finished and moved to the incomming directory, not earlier.
-
Probably rather a problem of your crashing encrypted file system than of aMule. Maybe it doesn't commit the changes (deletion of the temp files after hashing) anymore.
Please check your logfiles for the entries
AddLogLineM(true, CFormat( _("Unexpected error while completing %s. File paused") )% GetFileName()
AddLogLineM(true, CFormat( _("Finished downloading: %s") ) % GetFileName() );
(and make sure your logfile isn't on that file system too).
-
Probably rather a problem of your crashing encrypted file system than of aMule. Maybe it doesn't commit the changes (deletion of the temp files after hashing) anymore.
Please check your logfiles for the entries
AddLogLineM(true, CFormat( _("Unexpected error while completing %s. File paused") )% GetFileName()
AddLogLineM(true, CFormat( _("Finished downloading: %s") ) % GetFileName() );
(and make sure your logfile isn't on that file system too).
No, its not a problem of my encryptet FS.
The aMule crash was a programm freeze, I rebootet because amuled was a zombie.
Und the other crashes was complete system freezes.
My system ist very slow and massive CPU usage causes such problems.
And the problem is that the hashed files where not finisched if there are other files to hash in the meantime.
Only after hashing ALL files ALL files where finished together.
My FS is mounted with short commit time (5 seconds) and with data=ordered.
-
Confirmed. Fortunate coincidence let me observe what happens.
Completing a file involves two ThreadTasks, the first will hash the file, the second will move it to the Incoming directory. Now if a second file finishes download before the first finishes hashing, there will be another hash-task pushed onto the queue before the completion-task. That is, the second file has to finish hashing before the first will be moved to Incoming. (2-files-case)
Unfortunately fixing this behaviour is more complicated than describing it.
-
Fascinating. :)
-
Sorry for the late reply.
Thank you for the description.