Delete copy of .torrent file created by qbittorrent

[pixy-misa]

Give qbittorrent the ability for qbittorrent to delete copies of .torrent files that it creates. Copies are created in the "Copy .torrent files to:" and "Copy .torrent files for finished download to:" folders when those options are used. When deleting a torrent from the list, there should also be an option to delete the copy of the .torrent file just like there is an option to "Also delete the files on the hard disk". Both the files and the copy of the .torrent file are entities that the operator may wish to have removed and forcing the operator to go outside qbittorrent to remove the .torrent file is a potential source of error that I have seen created a situation for others where that person deleted the wrong .torrent file and then is faced with the issue of recovering the state of the bit torrent client so that deleted .torrent files is recovered and the files that it referenced may continue to seed or leech.

[vertigo220]

uTorrent:

Vuze:

I don't know about other clients, but uTorrent does not store a copy of the torrent file, but a torrent file for its internal use, it is not a copy, manually deleting it will cause a torrent error in the client. In uTorrent you can select a folder where torrent files it uses will be placed, this is analogous to the BT_backup folder in qBittorrent. There is no feature to copy torrent files in uTorrent. And something tells me that Deluge also has no feature to copy torrent files and if you delete it manually, this torrent will error in the client. In qBittorrent you can delete copied torrent files and your torrents will remain in place.

Similar to what @zakkarry said immediately above, saying something should or should not be done because of how it is or isn't done in another client makes little sense, unless speaking of a feature that they do that is great and should be implemented or that is terrible and shouldn't. You may as well say that since uTorrent has ads, that should be added here, or if another client doesn't allow sorting with the columns, that shouldn't be added here. There are reasons users choose qbittorrent over others, because of aspects of it that don't follow their design. If they all did or didn't do the same as the others, there would be no reason to choose one over another. The simple fact is, there have been numerous users in several issues across several years all expressing a desire for this functionality, likely for various reasons, but the point is people have use cases for this, and if the main reason for not adding it is that other clients don't do it, that's simply not a good reason. If the reason were added code complexity, which I understand, that would be one thing, but any code development has to weigh that with added functionality, and the fact is that this doesn't add much, as I've described above, beyond what's already there, whereas the added functionality appears to be fairly significant based, again, on the number of requests. I can only speak for myself, and my own use case, but despite the fact uTorrent and Deluge don't have this, I would very much like to see qbittorrent implement it, because it would help significantly with how I use it and save me a lot of time.

To clarify, I'm not talking about the files in the BT_Backup folder. I'm simply talking about saving backup copies of .torrent files when I add a torrent so I can keep them until I'm done with the torrent, in case I need them. Once I'm done with the torrent, I delete it, and I no longer have a use for the .torrent file, but currently that means going through and manually finding and deleting the ones for which I've deleted the associated torrents. None of this has to even touch qbittorrent's own files. I don't really care about those, at least with regards to this issue. I just want to be able to easily maintain a backup of .torrent files for incomplete torrents.

[zakkarry]

can only speak for myself, and my own use case, but despite the fact uTorrent and Deluge don't have this

I am confused, Deluge does exactly what I am proposing, I'd assume uTorrent does much the same. Either way, it IS irrelevant as you and I agree. Just wondering if this was a mis-speak. I showed a screenshot above.

As for the BT_backup folder, I'm not sure why you say they aren't real torrent files.

These .torrent files are not the "original" torrent files you added to qBit. They do not contain tracker/announce information. They are the the file information (info/files keys in the bencoded torrent file) as far as I understand and have seen, and nothing more. Meaning that if you were to take one of the .torrent files from BT_backup and try and load them into my Deluge instance, you would be in for a bad time. It would load and validate the pieces and files - and then nothing more.

Without their .fastresume file stored adjacent to the .torrent in BT_backup, these files are useless without manually adding the tracker they originated from.

[vertigo220]

can only speak for myself, and my own use case, but despite the fact uTorrent and Deluge don't have this

I am confused, Deluge does exactly what I am proposing, I'd assume uTorrent does much the same. Either way, it IS irrelevant as you and I agree. Just wondering if this was a mis-speak. I showed a screenshot above.

I was referring to stalkerok's comment above (https://github.com/qbittorrent/qBittorrent/issues/1606#issuecomment-2395190703) where they were saying uTorrent and Deluge don't maintain copies of the .torrent files.

As for the BT_backup folder, I'm not sure why you say they aren't real torrent files.

These .torrent files are not the "original" torrent files you added to qBit. They do not contain tracker/announce information. They are the the file information (info/files keys in the bencoded torrent file) as far as I understand and have seen, and nothing more. Meaning that if you were to take one of the .torrent files from BT_backup and try and load them into my Deluge instance, you would be in for a bad time. It would load and validate the pieces and files - and then nothing more.

Without their .fastresume file stored adjacent to the .torrent in BT_backup, these files are useless without manually adding the tracker they originated from.

Ok. I didn't get that far with them, so since they opened in qbittorrent showing what they were, I assumed they were fully operational. I'll assume you're correct, in which case that makes this request that much more important.

[zakkarry]

can only speak for myself, and my own use case, but despite the fact uTorrent and Deluge don't have this

I am confused, Deluge does exactly what I am proposing, I'd assume uTorrent does much the same. Either way, it IS irrelevant as you and I agree. Just wondering if this was a mis-speak. I showed a screenshot above.

I was referring to stalkerok's comment above (#1606 (comment)) where they were saying uTorrent and Deluge don't maintain copies of the .torrent files.

I mean, Deluge does - I haven't used uTorrent since 2.2.1 like almost 20 years ago. The original .torrent file is stored in the state folder by default. A copy is stored if you specify the option, entirely independent of it. If you select that it should be removed when you delete a torrent from Deluge, then that second one is ALSO deleted in addition to in the state folder.

Deluge does exactly what we are saying qBittorrent should be doing here. Are we talking about something different?

Whether stalkerok understands what Deluge does or not doesn't matter, he can think it's some impossible task or done incorrectly, but he's wrong.

As for the BT_backup folder, I'm not sure why you say they aren't real torrent files.

These .torrent files are not the "original" torrent files you added to qBit. They do not contain tracker/announce information. They are the the file information (info/files keys in the bencoded torrent file) as far as I understand and have seen, and nothing more. Meaning that if you were to take one of the .torrent files from BT_backup and try and load them into my Deluge instance, you would be in for a bad time. It would load and validate the pieces and files - and then nothing more. Without their .fastresume file stored adjacent to the .torrent in BT_backup, these files are useless without manually adding the tracker they originated from.

Ok. I didn't get that far with them, so since they opened in qbittorrent showing what they were, I assumed they were fully operational. I'll assume you're correct, in which case that makes this request that much more important.

Yep. If you were to try and use the BT_backup to migrate to another client or even to another qBittorrent instance by adding the BT_backup .torrent files normally, rather than replacing them with their fastresume pair in the new BT_backup folder, you would be in for a bad time.

[vertigo220]

Deluge does exactly what we are saying qBittorrent should be doing here. Are we talking about something different?

No. I haven't used uTorrent in many, many years as well, and I've never used Deluge, so I was just referring to their statements that they didn't have them, not as to the accuracy of said statements, but to their relevance. Just that, whether other clients can do something or not isn't a valid reason on its own to include or not include a feature. IOW, I'm saying they're incorrect in suggesting that the feature shouldn't be added simply because others don't have it, and you're saying they're incorrect in saying those other clients don't have it, which means their logic, which as I pointed out is flawed, falls flat entirely. At least that's how I'm understanding it, though admittedly I may be getting a bit mixed up on details in all the posts.

[zakkarry]

falls flat entirely

Pretty much.

[stalkerok]

I haven't used uTorrent for a long time too, but that doesn't mean I don't remember that it doesn't have a copy feature.

Ok, Deluge has this feature (according to you). The copied torrent files are for the user. How will the client behave if the user deletes the torrent file without deleting the torrent in the client? Will there be no error in the client? The client should keep track of these files.

[zakkarry]

According to me, someone who has had code merged into Deluge and is a moderator on our support forums, and writes plenty of code for the deluge community from plugins to projects interfacing with the core daemon, and miscellaneous scripts. According to the literal screenshot of this option existing in the client that I've posted now twice. Yes. It does this. Unquestionably. It's not a hard feature.

I don't have time to entertain your arrogance and pettiness surrounding this issue. Based on your GH profile and attitude/questions about this feature generally, I don't think this would even be something you'd contribute (whether because of skill or the position you seem to take matters not). Numerous people say it's a feature in uTorrent, a member of Deluge's team shows you screenshots and tells you it does this, and you seem to think this feature is so "out of reach of possible" that you question or declare it does not do this. It's embarrassing.

If you have a reason why you're against this at all, let's hear it, otherwise stop being so adversarial to the users and third-party developers who are advocating for a feature that is entirely reasonable and possible with minimal time spent.

And to answer your question, nothing happens if the torrent is manually removed by a user from the "copy" feature and then subsequently removed from the client. Why would you expect qBittorrent (or Deluge) to freak out and/or crash at a simple ENOENT or something. That's ridiculous and the fact that you are acting like this behavior isn't implied, and it should be considered that it handles a simple ENOENT ungracefully is also embarassing.

Feel free to share your opinion, but putting up petty and ignorant road blocks for a feature you either do not want or should not care about users who having the option to utilize is detrimental to the project, its team members, and the user base at large.