aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: corrupted files after aMule crashes  (Read 2513 times)

m2kio

  • Full Member
  • ***
  • Karma: 0
  • Offline Offline
  • Posts: 152
    • http://little-bat.de
corrupted files after aMule crashes
« on: March 26, 2004, 01:24:41 PM »
hi,

i posted this already to de_bugs, assuming German is one of the developers native languages...

after aMule crashes, and, it crashes every 1 or 2 days and most times i let it run and run until it crashes... it leaves retrieved data and meta info about retrieved data in a mismatching state on disk:

-1- after a crash, each chunk which was busy downloading when aMule crashed, finishes as 'corrupted' when completed.

-2- i had multiple instances where files, when completed, were restored to download mode because the final checking found one or even two corrupted chunks. thats not only bad, its probably even worse, because i probably also served those broken chunks several times! i don't know whether the peers could detect the corruption, but at least i hope so.

so what to do?

please always write the chunk data to disk prior to writing/updating associated meta data to disk.

please checksum all part file chunks after (re-)starting aMule. Its really no good serving broken data.

besides that: good work!

        ... m2kio !
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: corrupted files after aMule crashes
« Reply #1 on: March 26, 2004, 03:37:44 PM »
Ok, let's clarify some stuff :)


We do write the data on disk BEFORE writing the metadata. But the metadata stores only the 'complete' status for a chunk after it's downloaded COMPLETELY. That means, if aMule crashes, while downloading some chunk, and amule rehashes it, and say it's corrupt, well, it's corrupt. For sure. It doesn't happen on my side, so I *guess* you really have problems with corrupted files. There are flush() calls over the writing of metadata, and as I say, metadata is alwas written after the data, so, I don't see how could it store wrong values. I can be wrong and I had just woke up, of course. :)


About the corruption spreading: aMule only shares completed chunks hash-verified so there is no corruption coming out from your aMule :)

And thanks for using it ;)
Logged

m2kio

  • Full Member
  • ***
  • Karma: 0
  • Offline Offline
  • Posts: 152
    • http://little-bat.de
Re: corrupted files after aMule crashes
« Reply #2 on: March 26, 2004, 05:59:45 PM »
hi Kry, tnx for your reply.

Quote
Originally posted by Kry
We do write the data on disk BEFORE writing the metadata. But the metadata stores only the 'complete' status for a chunk after it's downloaded COMPLETELY.

then, how do you detect the partially received chunks after aMule restarts? you _do_ detect them, somehow. probably the problem is with the method you do this?

Quote
Originally posted by Kry
About the corruption spreading: aMule only shares completed chunks hash-verified so there is no corruption coming out from your aMule

you probably do not mean that a chunk is hash-verified each time before it is sent to a peer. you trust at some point that it _was_ successfully verified. i believe that a chunk shown black in the progress bar and green in all peers chunk lists  _is_ assumed to be ok. right? then aMule shares them, though they are broken, as it finds out at the final check before storing a complete files away.

believe me or tell me where i'm wrong.

     ... m2kio !
Logged