Arvid Norberg
Arvid Norberg
>> it sounds like you're asking that the "check-resume" step not validate the resume data against files on disk > > Not exactly. > I think it still makes sense...
actually. a flag that means "don't validate any of the resume data against files on disk" would be sufficient for your use case, I think. It would have very similar...
would you mind testing this? https://github.com/arvidn/libtorrent/pull/5173
Currently it's possible to specify the piece- and file priorities for more pieces and files than there are in the torrent. This is specifically to support affecting those priorities for...
I hadn't thought of that use case. I agree
one slight complication with: "check files and stop the torrent if the resume data doesn't match the disk, but keep all the resume state" is that currently checking the files...
one nuance is that "providing resume data" isn't quite a "yes" or "no". Since the same code path is used for adding a torrent for the first time as subsequent...
@master255 I don't know what you're referring to. It sounds like you describe normal use of resume-data. I did land this: https://github.com/arvidn/libtorrent/pull/5173 Which effectively allows deferring some checks of the...
> Very often I hear it from you. I can be more specific. You say you have a cache of "torrent_handle state". a `torrent_handle` is a `std::weak_ptr`. It doesn't seem...
@master255 are you opposed to using the term "resume data" instead of "cache". It's just a historical name, since back in 2004 when bittorrent clients started doing this. It's easier...