Delete copied .torrent file when deleting torrent

[xeophyte]

Suggestion

Torrent file copy is not deleted when deleting torrent. When in the Settings/Downloads these options are enabled

• Copy .torrent files to
• Copy .torrent files for finished downloads to

the .torrent files are not deleted when deleting torrent and you have to do it manually.

Add that option or function.

[vsemozhetbyt]

Users of uTorrent are accustomed to this feature, so it would be helpful to have it in the qBittorrent as well.

[Danny3]

Honestly I want a different checkbox for that. like: Also remove the .torrent file With the "remember choice" think in front of it too.

[stalkerok]

Duplicate of https://github.com/qbittorrent/qBittorrent/issues/1606 https://github.com/qbittorrent/qBittorrent/issues/18818

There is no feature to copy torrent files in uTorrent.

https://github.com/qbittorrent/qBittorrent/issues/1606#issuecomment-2395190703

[xeophyte]

There is no feature to copy torrent files in uTorrent.

He meant deleting .torrent file when deleting torrent.

[zakkarry]

Duplicate of #1606 #18818

There is no feature to copy torrent files in uTorrent.

#1606 (comment)

Did you "forget" about the comments that followed the one you linked to? They aren't exactly hidden...because as you were told Deluge actually does do this...completely, whether or not uTorrent does. But even if no other client did this already, it would not make the feature request any less reasonable and/or possible. Either way, your points were refuted successfully 3 weeks before you posted this latest misleading comment.

https://github.com/qbittorrent/qBittorrent/issues/1606#issuecomment-2395241980

To top it all off, this baseless campaign you have against this feature seems to have fallen flat and failed, because @glassez has made several commits referencing adding this, despite how impossible you contend it must be.

Despite functionality from other clients (Deluge, and you claim only partially in uTorrent) cited with screenshots from people on said client's dev team (myself), you seem to incessantly crusade around declaring anyone speaking on this issue give it up, basically throwing wrenches into FR's that can, should, and - now - are being worked on.

I think it'd be best for the user base involved with this particular issue/FR if you took a step away from the discussions, as it's obviously being worked on despite your erroneous position and stance, I'm not entirely sure how you behave in other threads on this repository, but you don't seem to understand this issue, and you don't appear to be speaking in congruence with the actual development team of qBittorrent or to the potential roadmap and efforts they are headed towards.

I have no idea why you care so much about this particular issue, as you don't seem to want or need it, but the rest of us do. Continuously spreading misinformation to imply the opposite of the reality and direction things seem to be heading now, with commits being made as recently as 2 weeks ago referencing this, is disingenuous at best, and a complete dick move at worst.

This is not what FOSS is supposed to be about at all.

[stalkerok]

@zakkarry You know the expression “consumer extremism”? I'd like to see much higher priority features not yet implemented than this one.Looks like you got what you wanted. Congratulations! @glassez Thank you, finally this whining will stop.

[zakkarry]

@zakkarry You know the expression “consumer extremism”? I'd like to see much higher priority features not yet implemented than this one.Looks like you got what you wanted. Congratulations! @glassez Thank you, finally this whining will stop.

Given that I'm definitely not a consumer in this scenario or trade if used colloquially, I assume you saying YOU are a consumer extremist?

I can only assume this is an admission about you, by you, in which case your behavior even up until this reply I'm making is pretty telling. I would severely question @glassez and the development team's allowing you to run around as the self-appointed "ambassador" to PRs and issues.

Not my project though, I only know how FOSS is meant to be.

[badhorsey]

Also, when a torrent finishes, the torrent file is COPIED instead of MOVED to the "finished torrents" directory, so now there are two copies of it. This may be a result of the same bug.

[xavier2k6]

ANNOUNCEMENT!

For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future! Here are some options available to you:

1. Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.

2. Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket. (new/existing contributors/developers are always welcome)

---

DO:

• Provide constructive feedback.
• Display how other projects implemented same/similar etc.

DO NOT:

• Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s). (These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)

[zakkarry]

Was there outstanding questions I can help answer about the implementation I described Deluge having above specifically?

Basically, I imagine with both fastresume and SQLite, if the option is enabled, keep some form of a key in fastresume or a column in SQLite that tracks the "Copy of" version of the ORIGINAL torrent file. 1:1 of the original. Then upon deletion, simply check if that file still exists and if so delete it to if deletion of .torrent when torrent is removed is selected.

Further discussion was had above, but I'm not sure what exact sort of information is necessary other than to track the "copy of" and then run through some if "option is enabled to delete upon removal" - check for the file still existing (as a user could have removed it manually for some reason and filesystem throwing access errors or ENOENT etc bad - if it exists maybe even check its infohash to verify that its one and the same and hasn't been replaced in some weird trump/nuke/error where a reupload was made with the same title, and then delete it.

Further things that may be worth investigating is the naming of the files, in cross-seed we append the infohash to the actual file, which would make the previous a little less of an issue in the sense of conflicting with same name.

example: The.Last.Torrent.Ever[9275485gacabaddabada30f5c39c890d].torrent (I know this is not the correct length infohash this is I just an example)

We've already implemented the full API as a mechanism for indexing in cross-seed at this point, which was my entire reasoning for getting involved in this feature in the first place. However, due to the response and time since, we've just made our own solution. I still think it's a valuable and useful feature, and that's why it's included in other clients, but it just isn't as urgent for our user base now.