I recently had to remove and re-add a 120GB torrent that I created and that I'm seeding. When I point the re-loaded torrent to the data folder containing the data, all the data is re-checked. I'd like the ability to skip this re-check and tell the program that all the data is fully intact and at 100% completion.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Doesn't the "skip hash check" checkbox in the add torrent dialog achieve what you want?
No. I don't have an "add torrent" dialog. I may add a hundred torrents in a few minutes, so that is off. There are several things I'd like to see available outside of that dialog that are part of that dialog, such as the ability to download magnet metadata without starting the actual data download, but I don't want drill down into settings twice to turn that box back on and then back off every time I have one particular torrent I'd like to make that exception for. I didn't know that was in that box because I always have it off, so it is effectively dead to me. Edit: might have come across harsh, but not meant that way, sorry
i'm opposed to skipping the data check for seeding in the official qBittorrent releases.
If someone wants to do this they should have to recompile the client from source and then the client should announce itself with a radically different peer_id that doesn't claim to be qBittorrent in any way, shape or form.
This feature can be heavily abused to seed fake/poisoned torrents or files that have been intentionally changed and corrupted to send malicious data specially crafted to crash some remote clients or conduct various remote exploit attacks (including, but not limited to, potentially doing a remote code execution in the remote client). This "feature" is also a relatively common tactic used by anti-piracy enforcement companies.
Well-designed clients will drop any bad checksum data without crashing (or executing remote code while crashing), but poisoning torrents with bad checksummed files is enough of a low-effort way to waste the time of thousands of other users.
if qBittorrent implements in the official releases such features that contribute to torrent poisoning, it will then probably become blacklisted / banned from pretty much every tracker out there.
@R-Adrian Well according to @FranciscoPombal it apparently already has the feature (tucked away in a dialog box that some users prefer to disable) and it's not blacklisted everywhere, so...maybe read the thread prior to adding your two cents? Just a thought.
true, it has the checkbox for when adding a torrent file... which can have its contents be 0,001% finished or 99% finished downloading. That one can be useful when resuming a download.
But the client then does another full data check anyway when it finishes downloading and starting to seed.
This check is what's at issue: full torrents being seeded with bad data. Partial torrents... meh.
You don't seem to understand how useless your argument is. All I have to do to poison the data in your scenario is have the legit data on hand first, then in-place overwrite the parts I want to taint after the data check finishes. Alternatively, the fastresume can be modified offline to contain the desired state, bypassing the check entirely. Also, the client doesn't do a full data check when it finishes downloading unless you check a box that explicitly forces that to happen.
You are arguing that the program should police the owner of the machine, much like DRM and software activation. This is an unacceptable stance, especially in a piece of open source software, and doubly so when the anti-user provision is hilariously easy to bypass. The only reason I don't do it instead of adding a feature request is because it's merely a matter of (in)convenience for me; I can wait for 121GB to transfer over a 2.5G ethernet connection from a RAID array, but I don't think I should have to when I'm the origin seeder and my copies are literally all of the source data for the torrent.
ok.. for particular cases where there are lots of unique data, it might make sense to have a checkbox for skipping all checks somewhere under tools -> options -> advanced ... preferably behind a warning that says "beware...you risk making a mess of things. Also, there's a leopard in here."
Bad torrent data will happen anyway, either in official or custom-compiled builds, but its better to not make it too easy to happen (Murphy and his laws...)
And it's not exactly useless.. it raises the knowledge bar a bit, being probably just enough of an inconvenience so that we don't see it everywhere. Not many people will venture to modifying those program configuration files.
Also, about the second data check, on finish... i didn't realize that... i probably enabled that setting long ago and got so used to it that i forgot about it... though i still like its use, especially when qBittorrent crashes randomly. (last such crash that i had was in... november last year... i had to redo all my qBittorrent settings.)
A possible way to mitigate your concerns is to have the program run a data integrity check on a piece before it is sent out. That not only prevents sending out bad data, but also catches any sort of corruption, intentional or otherwise, and brings it to the user's attention. That would actually be a nice thing.
indeed, a delayed just-in-time data check only when a piece is first requested seems useful
just like with manufacturing, instead of checking the entire stock before production, check it during production, when needed.
https://en.wikipedia.org/wiki/Just-in-time_manufacturing
this might actually solve the problem of checking large files.
@R-Adrian @jbruchon
Guys, the situation is really not that bad. @an0n666 has done some work recently to prevent "fake" seeding and torrent poisoning (theses fixes made it to 4.3.0): https://github.com/qbittorrent/qBittorrent/pull/13206 and https://github.com/qbittorrent/qBittorrent/pull/12037. From my understanding, as soon as a piece is requested from a file that doesn't exist, the torrent will go into "missing files" state. Also, I'm pretty sure libtorrent doesn't let you seed bad pieces on purpose already (for example, if you create files with the same name but with random/bogus data for seeding). A sufficiently motivated attacker can of course modify the code to allow for this, but at least mainstream libtorrent-based clients have peer-banning heuristics built-in to defend against this.
So I really don't see a problem in adding a way to add multiple torrents with "skip hash check" at once. But please, @an0n666 @arvidn correct me if I'm wrong here.
I personally would want to make sure the data was at 100% before seeding. I know that I have downloaded some stuff, that obviously was seeded as a new torrent, but had only completed to maybe 99.5% from its original torrent. I currently sucks as of 4.3.0.1 with the torrents and rechecking and all that, because that's happened to me a lot, too, so I can see why you're so upset that you had to sit there, waiting for your 120 GB data to be checked.
@as-muncher My concern is when I know I have the data at 100%, particularly because I'm the person who made the torrent. In such a situation, being able to skip the hash checking process makes a lot of sense.
Yeah, I guess that makes sense if you're making a new torrent like that. I suppose qbittorrent might have to do something if there were, for some odd reason, already a torrent with the same name. Maybe it's making a hash of the torrent or something.
Most helpful comment
No. I don't have an "add torrent" dialog. I may add a hundred torrents in a few minutes, so that is off. There are several things I'd like to see available outside of that dialog that are part of that dialog, such as the ability to download magnet metadata without starting the actual data download, but I don't want drill down into settings twice to turn that box back on and then back off every time I have one particular torrent I'd like to make that exception for. I didn't know that was in that box because I always have it off, so it is effectively dead to me. Edit: might have come across harsh, but not meant that way, sorry