"Open torrent file for seeding" option.

[Poromenos]

If you open a torrent file now, it checks in the default location, and if you have set your torrents to be moved elsewhere, it begins redownloading all over again. If you set the location it still keeps on downloading, so it would be good if there was an "open torrent for seeding" option that would only check the torrent and seed it (NEVER mess with it if it wasn't there).

[nightshifted]

There's an option by that name now, but it seems to do what its namesake in BitComet does: it announces as a seed whether you have the content or not. (You have to Stop, Force Re-Check, and Start again to get it to be honest.)

I wonder what it does when a leecher asks you for a piece that you don't really have.

[Firon]

Not quite. If you have -any- missing files, the torrent will not start. (Error: Files Missing)

[nightshifted]

Sorry, knew about that one (users of the tracker where I'm a moderator write in about it all the time), should have said. But what if the files are present yet contain wrong data, or are not the right size? I really don't want to try it out on a live torrent and risk sending hash-failing pieces.

[Firon]

If they have wrong data (not sure about wrong size, never tried), then that'll screw over the downloaders, but eh. Sometimes you can get away with bypassing the check

[nightshifted]

That brings us back to something I asked about long ago ... since µTorrent doesn't rehash pieces before sending, a change made after the check can lead to poisoning, and now here's a way to enter a swarm with no checking at all so long as you have something with each of the right names. So "open for seeding" is safe to use only when you're positive you can bypass the check, and it's not safe for use by tyros.

Ever moderate a tracker with thousands and thousands of greenhorns?

[Firon]

But no client rehashes them... it'd generate too much CPU use, and there's also the fact that you rarely ever send out a full piece, so that'd be very wasteful (CPU and disk reads)

[nightshifted]

BitTornado, ABC, and BitComet/BitLord rehash each piece before sending. As you said, though, that helps only if the recipient collects all slices of the piece from senders whose clients rehash.

I think the same thing could be accomplished if the client would write-lock the files from the start of the check, but a function to jump in without checking would defeat that as well. It's one of the reasons I was posting a while back about not counting received hash-fails in the downloaded amount reported to the tracker.