if a seeder changes the source after starting to seed ...

[nightshifted]

Scenario:

user posts a multi-file .torrent and starts to seed it, announcing as a seed

after starting to seed, the user changes a file and spoils one piece in the source, so that it no longer matches the SHA1 hash for it in the .torrent file -

The official client and Azureus do not rehash pieces immediately before sending them, so they'll happily send invalid copies of that piece, no leechers will complete, but the initial uploader will continue to announce as a seed.

BitTornado, ABC, and BitComet rehash every piece before sending it, and if it doesn't match its hash, these clients will not send it and will increase the "left" field in their announces to show they need it; that can mean a seed will demote itself to leecher.

Personally, I consider the latter behavior preferable, as it alerts the would-be seeder that something is wrong. It also alerts the downloaders, as they see there is no seed and there's no full distributed copy (or if there is a full distributed copy because the piece got out already, the would-be seeder can download it and be a true seed again). With the former situation, people are left puzzled and keep downloading and discarding the spoiled piece.

So, my question: which way does µTorrent handle it? Does it recheck the hash of a piece before sending it?

[Firon]

I think it works like Azureus and Mainline.... but don't quote me on that.

You could always try it yourself.

[nightshifted]

It takes two people to test it, or at least two computers, doesn't it, but I could look for a second person.

EDIT

Tested, failed ... it doesn't recheck but happily sends out bad copies that will fail their hash, just as Firon expected.

[ColdArmor]

Sounds like it would be a good feature if it is efficient.

[splintax]

Hmm, shouldn't µT lock the file so that you can't edit it?

[Firon]

You could stop it and start it. It doesn't check the files when you do that.

[nightshifted]

'Tacks: I don't know of any client that locks the files during seeding.

Firon: Yes, the would-be seeder could stop it, recheck the files, and restart it, but I'm writing from a tracker moderator's perspective, and the difficulty is in getting him/her to realize there's a problem and that (s)he should do that. You can PM the person and email him/her until your keyboard springs wear out and not get through. But if (s)he fell to 99%, (s)he and all the leechers would notice. Also, (s)he'd stop eroding the leechers' ratios and padding his/her own by resending that bad piece.

[Firon]

No, my response was towards splintax for changing the files. They could stop it and the file could get changed in the interim. When started uT wouldn't know the difference unless the filesize/name differed.

I'm not sure if it's feasible to implement checking of every piece without ramping up resource use significantly.

[nightshifted]

Thanks for explaining that, Firon. So you were talking about stopping the torrent, messing with a file, and restarting, then. But I'm not going to edit my previous post, because I still want to say what I said about stopping, rechecking, and restarting. At least µTorrent has manually-initiated rechecking available, and yes, it does demote a seeder to leecher if the source has been changed. That's way better than nothing; the problem, again, is getting the seeder to use the function.

You don't even have to stop and restart it to mess a file up; as with every other client I've used, files are writable during seeding.

I don't know either about the additional resource use to rehash before sending. At least three clients do it but I don't know how big the tradeoff is.

(I was going to suggest, "Maybe it could be done only for pieces lying in or extending into a file whose timestamp is newer than the .torrent file; that would still be imperfect, as someone could touch the .torrent file, but it would catch most incidents." Then it hit me that that would apply only to the original uploader and not, say, to a sole reseeder rescuing leechers. Nevermind.)

--

EDIT several days later

Saw it in action; on the tracker where I'm a moderator a seeder running µTorrent 1.2.2 messed with his source, and it just kept on sending out bad copies of the adulterated piece. Luckily he noticed that all the leechers were getting stuck at 99% and contacted us. I told him to stop the torrent and do a forced recheck, and that demoted him to leecher and confirmed the problem.

I wonder, what if, instead of rechecking every piece's hash before sending it, µTorrent write-locked the source during seeding? That way whatever was there during the initial analysis would stay unchanged. There would be ramifications to figure out: keep the locks during a pause, release them during a stop but reanalyze upon restarting the torrent, and so forth.

--

Another edit ... and I see where I "got" that idea; it was from a mentally unattributed memory of Splintax's post above. Sorry. Splintax gets all the credit, none for me.