starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Delete copied .torrent file when deleting torrent #15876

New issue

Open

opened 2026-02-22 02:35:01 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-22 02:35:01 -05:00

Owner

Originally created by @xeophyte on GitHub (Jun 30, 2024).

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.

Originally created by @xeophyte on GitHub (Jun 30, 2024). ### 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.

deekerman added the

Feature request

label

2026-02-22 02:35:01 -05:00

deekerman commented

2026-02-22 02:35:06 -05:00

Author

Owner

@vsemozhetbyt commented on GitHub (Aug 4, 2024):

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

@vsemozhetbyt commented on GitHub (Aug 4, 2024): Users of uTorrent are accustomed to this feature, so it would be helpful to have it in the qBittorrent as well.

deekerman commented

2026-02-22 02:35:08 -05:00

Author

Owner

@Danny3 commented on GitHub (Oct 22, 2024):

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

@Danny3 commented on GitHub (Oct 22, 2024): Honestly I want a different checkbox for that. like: Also remove the .torrent file With the "remember choice" think in front of it too.

deekerman commented

2026-02-22 02:35:08 -05:00

Author

Owner

@stalkerok commented on GitHub (Oct 23, 2024):

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

@stalkerok commented on GitHub (Oct 23, 2024): 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

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@xeophyte commented on GitHub (Oct 23, 2024):

There is no feature to copy torrent files in uTorrent.

He meant deleting .torrent file when deleting torrent.

@xeophyte commented on GitHub (Oct 23, 2024): > > > There is no feature to copy torrent files in uTorrent. > He meant deleting .torrent file when deleting torrent.

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@zakkarry commented on GitHub (Nov 28, 2024):

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.

@zakkarry commented on GitHub (Nov 28, 2024): > Duplicate of #1606 #18818 > > > There is no feature to copy torrent files in uTorrent. > > [#1606 (comment)](https://github.com/qbittorrent/qBittorrent/issues/1606#issuecomment-2395190703) 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. ![image](https://github.com/user-attachments/assets/1ac27c78-beda-411d-88c0-63b7f986fdb2) 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.

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@stalkerok commented on GitHub (Nov 28, 2024):

@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.

@stalkerok commented on GitHub (Nov 28, 2024): @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.

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@zakkarry commented on GitHub (Nov 28, 2024):

@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.

@zakkarry commented on GitHub (Nov 28, 2024): > @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? ![image](https://github.com/user-attachments/assets/3f0911d1-00fc-49ec-8f55-353fc2280a25) 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.

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@badhorsey commented on GitHub (Jan 22, 2025):

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.

@badhorsey commented on GitHub (Jan 22, 2025): 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.

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@xavier2k6 commented on GitHub (May 25, 2025):

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:

Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.
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.)

@xavier2k6 commented on GitHub (May 25, 2025): ## 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.)**

deekerman commented

2026-02-22 02:35:09 -05:00

Author

Owner

@zakkarry commented on GitHub (May 25, 2025):

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.

@zakkarry commented on GitHub (May 25, 2025): 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.