-----Original Message----- >From: [EMAIL PROTECTED] >Sent: Nov 21, 2006 3:57 AM > >On Mon, November 20, 2006 20:39, Brian Stretch wrote: >> New theory: could rtorrent/libtorrent be having trouble keeping track of >> partial chunks? I've noticed that some torrents have lots of partial >> chunks in the "Chunks seen" screen while others seem to have mostly >> complete (F) or mostly empty (0) chunks, even on the same tracker. >> There's probably still a compiler or other system bug at play here but >> this is... interesting. If I force a rehash all partial chunks are >> zeroed, which seems reasonable yet very similar to the failed torrent >> behavior. Shouldn't libtorrent favor completing chunks before beginning >> new ones? Perhaps some other clients don't do that? >> >> Just a guess, I haven't delved into the code or vagaries of the Bittorrent >> protocol. > >Partial chunks does not matter, when the last piece of a chunk is >downloaded it will be passed off to a different part of the program that >does hash checking and then marks it as done. If it gets past this point I >can be pretty sure the data is valid at that point. It is also not very >likely to modify the content afterwards, even with multiple downloaders of >the same piece. > >If you are getting zero-ed out data for partial downloads, it might >indicate that the filesystem doesn't properly sync pieces when doing >munmap straight after an async msync call. > >Try the attached patch. It should complain if msync returns any errors, >though it is more likely to just silently drop the data. > >Rakshasa
No effect. _______________________________________________ Libtorrent-devel mailing list [email protected] http://rakshasa.no/mailman/listinfo/libtorrent-devel
