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.

[sledgehammer999]

Just so you know it is a little strange to want to copy the .torrent files and then delete it. qbt always copies the torrent files for internal use, so there isn't a possibility to lose them unless the whole disk fails. (look for the BT_backup folder. its torrent is named afte its infohash).

[pixy-misa]

The main reason for copying the .torrent file into an user defined folder rather than relying on an internal system folder is for the sake of portability in reconstructing the bit torrent state. It frees me of having to rely on internal knowledge of where the bit torrent client may store things from release to release. It frees me from knowing how different bit torrent clients (e.g. qbittorrent, utorrent, ... etc.) store things internally. It can allow me to name the .torrent file using the same name as the destination folder that I choose to use in my collection area rather than the infohash. In the event that I need to rebuild the state of the bit torrent client from scratch, regardless of which bit torrent client I choose to use, I will know from the folder where the .torrent file is located whether I have a completed download or not, and which completed download were being shared because those that were removed from the list for sharing would have had their .torrent file deleted.

There are many features that I can easily do without such as support for a proxy server, a scheduler and the ability to toggle between two sets of UL/DL limits, but to me more important that those previous feature (which are probably important to many people) is the ability to keep a copy of the .torrent files in a separate "in-process" and "complete" folder, the ability to change the name of the .torrent file to match the destination folder that I use, and the ability to removed the .torrent files from the "in-process" and "complete" folders when they are removed from the torrent list.

For now, it sounds like I will have to use a different technique such as renaming the folders to distinguish those that are being shared from those that are no longer being shared since the .torrent files of those that are not being shared are not being deleted.

Thanks for your time.

• pixymisa

----- Original Message ----- From: "sledgehammer999" notifications@github.com To: "qbittorrent/qBittorrent" qBittorrent@noreply.github.com Cc: "pixymisa" pixy.misa@comcast.net Sent: Thursday, April 24, 2014 6:44:09 AM Subject: Re: [qBittorrent] [Wishlist] Delete copy of .torrent file created by qbittorrent (#1606)

Just so you know it is a little strange to want to copy the .torrent files and then delete it. qbt always copies the torrent files for internal use, so there isn't a possibility to lose them unless the whole disk fails. (look for the BT_backup folder. its torrent is named afte its infohash).

— Reply to this email directly or view it on GitHub .

[dmlemos]

I totally agree with this. Back in the days when I used uTorrent this would be my default delete option.

The reason torrent files are there is to maintain a copy state as pixymisa said. But I don't need the torrent file once I deleted the content from the disk.

[chrishirst]

But I don't need the torrent file once I deleted the content from the disk.

Then just delete them. In point of fact, you can delete the metadata (.torrent) files as soon as they are loaded, if you don't need them to maintain an 'archive' of your downloads. They are only kept for your convenience, as qBT/libtorrent use the hash ID named metadata files in BT_Backup for reference

And if you do not want two copies, simply uncheck "Move completed .torrent files to, then it will not move or copy them.

[FreePlague]

I always use this feature in uTorrent. Really miss it after moving to qBittorrent. Is it that we have only a BT_backup with obscure filenames or folder with normal torrent files, but like a trash (if not delete files manually each time).

[chrishirst]

I always use this feature in uTorrent. Really miss it after moving to qBittorrent

How??? The feature IS there

Tools -> Options -> Downloads -> Save torrent files in ...

and

Tools -> Options -> Downloads -> Copy torrents for completed jobs to .... If you don't care or don't need to know what is completed don't use the second option, if you want to match file name to payload, wet the "Copy finished" location to the same folder as your completed payloads are located.

The BT_Backup location is where qbittorrent keeps IT'S copy of the metadata, well away from user 'participation' [to put it nicely] and with a file name that only the protocol engine can read and link to the running task, THIS copy will also be removed when the task is removed from the client because it no longer needs the fastresume file OR the metadata file.

[chrishirst]

Oh and IF you do not want to keep a copy at all, do not set the "Copy torrent files to"

[FreePlague]

"Save torrent files in ..." and "Copy torrents for completed jobs to ...." work fine. Torrent file is stored where it is necessary. But the point is that when I delete torrent by GUI, this torrent in my folder is left. And over time this folder will turn into a dump, if I do not remove them manually every time. Let me explain why I need this folder. If I want to move/copy all my torrent to another BT client or maybe unfortunately qBittorent resume file will be corrupted, I will take torrents from this folder. And instead only the necessary torrents there will be all, including unnecessary and deleted.

[chrishirst]

Sorry, but I don't understand your problem, you can do whatever you want, at any time you want with any or all of the files in either of the user defined folders for storing metadata files. once loaded into qbittorrent those files are completely redundant as far as qbittorrent is concerned. You could delete all of them every hour if you wanted to and qbittorrent would continue working, try doing that with uTorrent.

The hash id named files in BT_Backup do NOT need any user managing, they will be created on loading the task, and removed on deleting the task. The user defined locations are for your convenience, delete them, keep them, move them to a different client or machine, whatever you want to do with them ... ... you can, with total alacrity.

I move some tasks and payloads to another machine on a weekly basis for jobs that I want to continue seeding without keeping my 'day to day' machine powered up 24/7 and the ones I don't need get deleted.

[FreePlague]

Ok, thanks. I understood you.

[student13371]

+1

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

Please add the option to DELETE .torrent file when removing a torrent from the list. Lots of people use this feature. The fact that you don't use this feature, doesn't mean that other people don't use it.

Ability to delete .torrent files is a feature that a lot of users use to manage their .torrent file collections. Those .torrent file collections can be used by multiple different torrent clients on different trackers etc.

It's a handy feature and lack of ability to manage .torrent files prevents me from migrating from uTorrent and Vuze to qBittorrent.

uTorrent:

Vuze:

Thank you.

[chrishirst]

https://qbforums.shiki.hu/index.php/topic,3738.0.html

[LittleVulpix]

I would also appreciate this feature, one of the two features missing after my migration from ad-infested utorrent.

[japrine]

+1 I need this, I've been manually going in and comparing download folder with .torrent file directory and have deleted 1000s of files so far selecting one at a time most of the time. How is this not a feature.

Here is why its needed - I download to multiple drives. If something happens and I need to add files back into torrent program to get seeds going again I need the .torrent files to be on the same drive as the data is. This way I just set default drive/directory to that drive and then select all the torrent files and hit enter. All instantly added back in. I have 12 download drives. All the .torrent files for the data on G is in a torrent files directory on G etc. (using the copy .torrent file to feature) Problem is I often delete downloads I dont want seeding anymore but the .torrent files are not deleted. So once a year or so when i have to redo qbit or use another torrent app I have all these .torrent files that don't have data for seeding and I dont want them redownloaded. What a pain. I like this app way better then utorrent but utorrent had this feature and its driving me nuts that I spend 8hours deleting files manually every so often.

[witZack]

There are like 20 feature requests for this feature.

[jdnixx]

Hey, I'd also like this. I use magnet links to start downloading, "copy .torrent file to..." checkbox option to keep them around for archival purposes and to re-seed if I were to reformat my machine, but I like to try e.g. 3 different torrents for the same thing to compare their quality or whatever, and later delete all but 1. The .torrent files sticking around even after deleting with "also delete files on hard disk" makes keeping track of what I actually would want to re-seed a nightmare, as someone else in another issue thread already put it

[DJAlik]

Please add this. I want to move from uTorrent to this but manual .torrent file management after I remove the download from the client is showstopper for me.

[Fytch]

Very interested in this feature, alongside with many others it seems.

[Mrsash2020]

Yes would like to see this added. Preventing me from moving to qbittorent.

[mat926]

It amazes me that the developers still haven’t implemented this feature after 8 years. How hard can it be?

[Mrsash2020]

It amazes me that the developers still haven’t implemented this feature after 8 years. How hard can it be?

I don't think that's the issue. They are definitely capable. I have seen some posts in this forum where people have requested it over the years but have been brushed off. Reminds me of when Microsoft removed classic Menu and insisted we use their product as they want us to. As if we dont have a clue what we are doing.

I remember a friends advice either live with it or move on.......

Anyway not egging anyone on. Its their software and they have the choice so.... I leave it in their court.

[mspykerez]

Coming from uTorrent I miss this feature... is any of the devs looking into it?

[tinysalad]

This is a must have feature. Given the seeming very large amount of users who are noticing this as a problem and requesting the resolution I don’t understand why it’s taking years to implement. Real shame.

[jwshields]

I know that my post is sort of tying a few different issues together, I apologize in advance for this, but I feel they're all related, and people keep on bringing up enabling the option of "copy .torrent file to..."
I'm finding that I am seeing some odd behavior or something I'm not fully understanding.

Running Windows 10.19044.1645 & qbittorrent 4.4.2
When I have the "copy .torrent file" option enabled, it does not copy the file from the watched folder, it removes/moves it from the watched folder. Is this intended?
I also have found that those torrents, when I delete them, the .torrent files do not get removed (whether they came from a watched folder or not)

I have some confusion around removing/deleting torrents as well, sometimes it seems that the files that get removed bypass the recycle bin. I can't provide a solid example right now, but has this behavior been seen before, and could it be somehow tied into the overall issues noted here WRT the .torrent file handling upon addition and removal?

Also, Is there a mismatch with the verbiage used for the option "Delete .torrent files afterwards" ...? To me, it implies that it will delete the .torrent file upon addition to qbittorrent (Tooltip text: Whether the .torrent file should be deleted after adding it)
Does this truly mean what the tooltip says? Because, if so, I have the option unchecked and it still removes torrents from watched folders. This seems to be counter-intuitive and going against what the checkbox option purports to do.

But, opening a .torrent (not from a watched folder) - does not get removed. Why is there a disparity there? Is that intentional?

One last bit... How do these two configuration parameters play into all of this?

[Preferences]
General\DeleteTorrentsFilesAsDefault=true

[Core]
AutoDeleteAddedTorrentFile=Never

---

To clarify, the behavior I am looking for is this:

1. Any new .torrent that is added, either manually or via a watched folder will not be removed from the original folder that I have added it from. (or an option to enable/disable that functionality)
2. When deleting a torrent from the UI, the .torrent that qbittorrent stores will be removed as well, (and the original torrent referenced in my first point will not be affected by the removal)

And, I guess, last thing... It seems that categories are not being applied to the incomplete path for torrents, when the category options show they should be. Is any of this at all possible? I assume there would need to be some sort of state tracking for torrents added via the watch function, as to not trash disks and waste cycles all of the time. I dug around the forums a small bit and found a few threads which seem to fit along the same vein of thinking expressed in this issues...

https://qbforums.shiki.hu/viewtopic.php?t=9795
https://qbforums.shiki.hu/viewtopic.php?t=9574
https://qbforums.shiki.hu/viewtopic.php?t=8691
https://qbforums.shiki.hu/viewtopic.php?t=8661
https://qbforums.shiki.hu/viewtopic.php?p=38034
https://qbforums.shiki.hu/viewtopic.php?p=26822

Again, apologies for sort of mushing up multiple issues and topics into one post, but I feel there is a relationship between many of these options, and things just don't seem to be adding up.

[thalieht]

When I have the "copy .torrent file" option enabled, it does not copy the file from the watched folder, it removes/moves it from the watched folder. Is this intended?

Yes it's intended, otherwise it would keep trying to add already added torrents. These options are not connected. "Copy..." options generate a .torrent file based on the metadata qBt has about this torrent (from the BT_backup folder).

I also have found that those torrents, when I delete them, the .torrent files do not get removed (whether they came from a watched folder or not)

The original .torrent file is not touched by qBt after it is added except when "Delete .torrent files afterwards" is enabled (this option doesn't apply for watched folders because .torrents are always deleted from there).

it seems that the files that get removed bypass the recycle bin

Everything qBt deletes is final. Recycle bin is not used in any option or operation.

How do these two configuration parameters play into all of this?

DeleteTorrentsFilesAsDefault is for the confirmation dialog when manually deleting torrents. AutoDeleteAddedTorrentFile is for "Delete .torrent files afterwards" option.

And, I guess, last thing... It seems that categories are not being applied to the incomplete path for torrents, when the category options show they should be.

Torrent has to be in Automatic Management Mode for category settings to apply.

I assume there would need to be some sort of state tracking for torrents added via the watch function, as to not trash disks and waste cycles all of the time.

Watched folders are checked on a timer (10-20 sec, don't remember) and if a .torrent or .magnet file is found it is parsed. Leaving such files in the watched folder would force qBt to continually parse and compare if they already exist and naturally, this would start to get taxing if enough such files are accumulated. So qBt simply opts to delete them when they are added.

[jwshields]

Apologies for the slow response, but thank you for the details on all of my points!

Everything qBt deletes is final. Recycle bin is not used in any option or operation.

uTorrent had an option to either delete to recycle bin or fully remove; is that a feature that could be implemented in qBittorrent? Or has that been definitively decided this is the way it will work? Could I ask that the qBittorent team evaluate this behavior?

Torrent has to be in Automatic Management Mode for category settings to apply.

Understood, and I think I figured that out on my own shortly after posting my original comment. But thank you.

Leaving such files in the watched folder would force qBt to continually parse and compare [...]

Would it be feasible/possible to implement a feature of "Move added torrents to x directory" - if so, could I also ask that the team consider this sort of function? To clarify, I don't mean the currently existing option of Copy .torrent files to: & Copy .torrent files for finished downloads to: - I mean mostly for watched folders; that way a sort of archive can be kept if I need to start from scratch and re-add everything.
The current method where torrents don't have their respective .torrent file removed upon removal of the torrent itself (From the copied dir & completed dir) makes for a bit of a mess, and would be difficult to manage if I did have to start from scratch and re-add all ~6000 torrents that I currently have running.

Thank you again for the detailed response, I truly appreciate it!

[thalieht]

uTorrent had an option to either delete to recycle bin or fully remove; is that a feature that could be implemented in qBittorrent? Or has that been definitively decided this is the way it will work? Could I ask that the qBittorent team evaluate this behavior?

qBt relies on libtorrent for deletions but it doesn't have "Delete to recycle bin" functionallity. To implement it manually, code would have to be written for each OS individually. Ideally libtorrent should implement it but since Qt6 now offers a cross platform way to do it, someone might implement it in qBt using that. There's an open issue about this with many 👍 IIRC.

Would it be feasible/possible to implement a feature of "Move added torrents to x directory"

Maybe you're talking about this #2323. If not, you should make a new issue for it.

The current method where torrents don't have their respective .torrent file removed upon removal of the torrent itself (From the copied dir & completed dir) makes for a bit of a mess, and would be difficult to manage if I did have to start from scratch and re-add all ~6000 torrents that I currently have running.

Sounds to me like you want to backup the currently active torrents and from the sound of it, it's for batch purposes which means torrent names don't matter? If yes you could use some sync utility on the BT_backup folder with somewhere else.

[jwshields]

This is getting off topic & I don't want to derail this issue any more, but thank you for all of the insightful comments-

[justchil]

I think this is the same issue I've run into. I'm simply not experience enough yet to figure it out or to even find a solution yet.

I keep a "Copy .torrent file for finished downloads to: /home/justchil/downloads/torrents" and I use this directory for my rsync to other seedboxes. I also run a script several times an hour to check for "Unregistered Torrents" and tag them as "UNREG".

When I manually delete the UNREG torrents from the WebUI manually... it doesn't delete the torrent in /home/justchil/downloads/torrents. So my rsync script still pushes the .torrent to other seedboxes.

I would like the torrent to be deleted or moved to another location. I'm not sure this is a feature a ton of people will want... but maybe?

[mat926]

I really need this feature but it seems it hasn't been implemented yet. Is there already an existing tool that will cleanup the old .torrent files?

[donsenilo1968]

I would like to have this feature too. When it's possible in utorrent, why not in qb ?

[vertigo220]

Not only has this issue existed for a decade now, but this problem has spawned multiple duplicate issues (#2323, #5506, #16322, #19222) and discussions (#18985). Clearly this is a high-demand issue, and the lack of it is wasting numerous users' time by requiring us to periodically go through and manually delete these files. This should take literally 5 minutes to implement by someone familiar with the code (slightly longer if adding another option instead of replacing the current copy option with a move or delete one), so it amazes me something that has such a widespread negative effect that can be quickly resolved is being ignored.

[stalkerok]

https://github.com/qbittorrent/qBittorrent/issues/18818

[zakkarry]

Deluge does this as well, and given the SQLite database's utility for larger torrent loads and reliance on the .torrent files themselves in BT_backup by third-party software (such as the project I am a part of - for instance), it would be useful to be able to either have a "live" BT_backup (of .torrent files) to work off of while still utilizing the SQLite database or add an option for removal of the "Copy" that is stored. when that option is used.

Currently, users of our software who want to use SQLite can choose to use a .torrent copy folder, but it becomes outdated and creates issues when the torrents present in that folder are no longer in the client.

It would be beneficial, for our project and it many other users who want this for a variety of their own reasons to simply add another "custom" field to the fastresume or SQLite db associated with the torrent. You add fields anyway, a path to the reference/original torrent is a trivial addition that has no downside. If the user does not want this, they will not enable it and you can proceed as it currently is.

Given that qbittorrent mutates the .torrent files stored in BT_backup to begin with, having an accurate and complete .torrent store makes sense, If I ever wanted to migrate an instance of qbittorrent to another client for long-term seeding or if I lose my config directory due to corruption/hardware failure, I am shit out of luck unless I have an up-to-the-minute backup.

I'd propose the ability to replicate a sort of BT_backup with the original .torrent files, either with SQLite enabled for portability and third-party reference and/or independently as a means of having a point of live backup of the client's torrents.

I've seen other issues asking for this citing that "utorrent does it" (deluge also provides this) - and contributors and members of this org hating on the idea, and the only reason I can gather is seemingly because someone else originated it.

There is no denying a store of the original .torrent files that are active in the client can be useful in a wide variety of scenarios, that's why it is and was a standard feature in multiple other relatively popular clients. The fact that qbittorrent mutates the .torrent's stored in BT_backup has always perplexed me, but it should not be the sole source for that data, leaving the torrents non-portable, especially when using the SQLite feature you are now introducing.

[stalkerok]

https://github.com/qbittorrent/qBittorrent/issues/18818#issuecomment-2395126876

[zakkarry]

#18818 (comment)

I'm fully aware, but that's not the same thing at all.

You're not going to be able to export torrents AFTER data loss. You're not going to have a live accounting of the actual torrents in your client. You're not going to be able to add them at a later time if it crashes and corrupts due to a power outage.

That's like a tiny "solution" that only works in the best-case "everything works out" scenario and even then, do you expect someone to export each torrent after they add it, and then follow up and delete them after every single removed torrent? What about torrents that meet their seeding limits and are removed automatically?

This isn't a huge refactor or a major architectural change. I'm not sure why it's been a decade and met with so much reluctance or acknowledgment of validity. It's a feature request, one that users want and other clients have supported both currently and historically. Saying "NUH UH YOU DONT NEED IT" is kind of ridiculous. Further, citing exporting manually as some sort of solution to the feature request/issue is pretty disingenuous.

If you get a flat tire, handing over a pair of tennis shoes for walking is hardly equivalent to replacing the tire.

[glassez]

If you get a flat tire, handing over a pair of tennis shoes for walking is hardly equivalent to replacing the tire.

A funny analogy. But wouldn't another one be more appropriate? You bought a motorcycle and scold its manufacturer for having only two wheels, but it is more convenient for you to drive a car with four wheels.

In fact, there are so many disparate comments on this subject that it is difficult to figure out what exactly is the "common denominator" of them. What kind of torrent files are we talking about?

1. Do you want qBittorrent to store information about the paths of the .torrent files from which the torrents were added for the entire lifetime of these torrents, and (optionally) delete them along with deleting the torrents?
2. Or instead do you want qBittorrent to (optionally) store backup copies of all added .torrent files in a specified location, and (optionally) delete them along with deleting the torrents?

[zakkarry]

A funny analogy. But wouldn't another one be more appropriate? You bought a motorcycle and scold its manufacturer for having only two wheels, but it is more convenient for you to drive a car with four wheels.

It seems like this statement is making the argument that users who want this feature should switch clients, that they chose the wrong client because they want a minuscule feature in the client they otherwise like. My analogy said that there is a problem users are looking for a solution for, and instead of giving them that solution after a decade, a token (exporting) feature is referenced and is expected to meet their needs despite knowing there are use cases that it does not solve. If you are against this, I think that you should give a valid reason, I've read over several of these duplicate issues for this feature request and so far I haven't seen any meaningful justification as to why a relatively small feature request is being treated like it is.

To be frank, developer to developer, my use case is for the tens of thousands of users my project has who chose qBittorrent and may want to, either now or in the future, utilize qBittorrent and the SQLite database feature. I do use qBittorrent as my main client, but (as I'm a team member of Deluge using this very feature on in our client) do not see why you would not accommodate the many users who want a feature that is more or less trivial, by comparison, to some of the other features you are adding. We have plans to integrate directly with qBittorrent's API - but that is somewhat problematic with large instances as even currently adding torrents can receive terminated fetch calls and need repeat attempts to succeed.

My qbittorrent instances I do have are running 4.4.5, I'm content there, but I do not use them for anything I cannot just afford to lose anyway. I WOULD rather not have "stripped" .torrent files in my BT_backup, but it is what it is. I know what I'm getting myself into, I just don't know why you would CHOOSE to make it harder on users who may not be as prepared as others might be for any of the situations I outlined. I don't know why this was chosen, but I'm sure you have a reason. I would be curious to hear it, if you were party to that decision.

Digressing, you gave me two "choices" - whether this is a sincere inquiry for my opinion or not I am not sure, but I will gladly tell you what I think.

I think that you should retain the "Copy .torrent file to a location on add/complete" and store the path in one of the custom key/fields in fastresume or however you translate that to SQLite. When that torrent is removed from the client, simply delete that torrent if a checkbox for "Remove .torrent file when deleted from client" is selected.

For reference, albeit from a biased source, here is Deluge's option. It's simple and requires very little additional code.

Once again, I'm not sure why you would not store the original .torrent to begin with. You are taking away information that makes that .torrent file useful beyond that torrent and its session. If a user wants a copy of the original and wants it deleted when it's gone, that seems entirely valid.

Exporting torrent files manually is not even close to providing a valid/meaningful alternative to this.

[vertigo220]

If you get a flat tire, handing over a pair of tennis shoes for walking is hardly equivalent to replacing the tire.

A funny analogy. But wouldn't another one be more appropriate? You bought a motorcycle and scold its manufacturer for having only two wheels, but it is more convenient for you to drive a car with four wheels.

In fact, there are so many disparate comments on this subject that it is difficult to figure out what exactly is the "common denominator" of them. What kind of torrent files are we talking about?

1. Do you want qBittorrent to store information about the paths of the .torrent files from which the torrents were added for the entire lifetime of these torrents, and (optionally) delete them along with deleting the torrents?
2. Or instead do you want qBittorrent to (optionally) store backup copies of all added .torrent files in a specified location, and (optionally) delete them along with deleting the torrents?

While I agree the original analogy wasn't perfect, this one is so far off the mark it seems disingenuous. The requested feature doesn't at all make using the software less convenient, as 4 wheels on a motorcycle would. A perhaps more apt analogy would be that the motorcycle doesn't come with a tire iron (lugnut wrench) because it comes with tires that are impenetrable and never wear and and thus never require replacement and so one is not "needed," while completely ignoring the fact the owner of the motorcycle may desire one anyways since they might want to swap the tire out for one with different tread or a different look, or may want to be able to take the tire and put it on another motorcycle. The whole point is that the current setup makes things less portable, i.e. makes it more difficult to move to another client, a practice that is commonly used with paid software and is not seen in a good light from any software, including free software. And as pointed out, it relies on things working, and if something goes wrong, the torrents may not be able to be recovered.

As for your questions, there's little difference between them, and making it seem like things are so confusing and "disparate" again comes off as disingenuous. Either way, the .torrent file is kept, and either way, it's optionally deleted once the torrent is removed/deleted. The only difference between your two "disparate" options is whether qbittorrent is actually storing the copies itself or just keeping track of where they're stored. Either way, they're stored in some directory somewhere that qbittorrent knows about and can delete them from when requested. That's it, nothing more complicated than that, not these wildly different requests that you suggest. You even say yourself "what kind of torrent files are we talking about" then go on to refer to option a) .torrent files, or option b) .torrent files.

[glassez]

Digressing, you gave me two "choices" - whether this is a sincere inquiry for my opinion or not I am not sure, but I will gladly tell you what I think.

It was sincere. I really don't like the way it is right now. I would like to change this so that it is convenient for both users and developers (I am really convinced that users should not poke their noses into those files/data that the application has for internal use).

I think that you should retain the "Copy .torrent file to a location on add/complete" and store the path in one of the custom key/fields in fastresume or however you translate that to SQLite. When that torrent is removed from the client, simply delete that torrent if a checkbox for "Remove .torrent file when deleted from client" is selected.

Ok. But it seems to me that there should be only one "copy" option left. If you do not agree, please refute in a reasoned way what is the use of having two of them. From what I understand, you just need to save a copy when adding. Why do we need a second one?

[zakkarry]

I do not have a strong opinion on this, as if you remove the file when it is deleted from the client, whether the .torrent file is copied on add or completion is irrelevant, as it will never be left there erroneously (whereas now if I add a torrent and it stalls and cannot complete, it would be left there). At least if it is on completion it is a "valid" download and likely to be something I am almost certainly inclined to need/want to be stored)

These are all relatively small issues/nits, and given any solution after a decade would almost certainly please a sizable number of users who have been waiting on, or would otherwise find useful, this feature.

Furthermore, I think the introduction of SQLite and removal of the torrent store in BT_backup entirely necessitates some form of a solution, if nothing else for backwards compatibility to we developers who depend on a session directory that BT_backup once was.

[glassez]

Either way, they're stored in some directory somewhere that qbittorrent knows about and can delete them from when requested.

That's not so. The files from the "BT_backup" folder you may be referring to are not real torrent files (it was a mistake to leave such extensions for them and "BT_backup" for their folder).

That's it, nothing more complicated than that, not these wildly different requests that you suggest. You even say yourself "what kind of torrent files are we talking about" then go on to refer to option a) .torrent files, or option b) .torrent files.

You either misunderstood this or knowingly misinterpret me. These are really different options for implementation. Either we keep a link to the source files or to copies. Or maybe you want both? And what about the existing qBittorrent option "delete source .torrent files after adding a torrent"? How could it be integrated into this system of options?

[zakkarry]

The source torrent file and the copy of the torrent that is saved are independent. One does not choose "Save a copy of this and remove it when I add it" with the intention of that workflow doing just that.

I think where the idea that you are being disengenuous perhaps come in is with what appears to be feigned ignorance with questions like this...You think someone genuinely would want to both save a copy and delete that same copy in a few milliseconds?

That doesn't even make sense, and the answer to that question shoudl be obvious that the torrent file I load from my desktop and the torrent file I tell qbittorrent to save a copy of to C:\backup\torrents are not meant to be the same.

[glassez]

You think someone genuinely would want to both save a copy and delete that same copy in a few milliseconds?

I don't know why you think I'm such a fool to mean this nonsense...

[zakkarry]

And what about the existing qBittorrent option "delete source .torrent files after adding a torrent"? How could it be integrated into this system of options?

Because it appears that you were asking precisely that? You would delete the originating source .torrent file....and you would create a copy. If the option to remove the copy upon removal from the client was made, you'd delete the copy after removal.

It seems very self-explanatory. If the user added the torrent from the location and filename where the copy inevitably would be made, you could still follow this flow - it would delete the original, and readd it. You could check for this and skip the deletion if you wanted to save file system I/O - but it is all irrelevant and this pretty much works itself out regardless.

[stalkerok]

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.

[zakkarry]

, this is analogous to the BT_backup folder in qBittorrent.

I've already covered that it is not for a non-insignificant variety of use cases,

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.

Wrong. There are copies of every torrent in the state folder with fastresume and session state information stored in pickled files.

[stalkerok]

I've already covered that it is not for a non-insignificant variety of use cases,

I'm not saying those files can be used, deleting them from the BT_backup folder will also cause an error in qBittorrent.

There are copies of every torrent in the state folder with fastresume and session state information stored in pickled files.

The removal of which won't affect anything? Right?

[zakkarry]

The removal of which won't affect anything? Right?

What are you talking about? If you delete the active state folder data, it will affect your state. If you delete the "copy of the torrent files and if you delete it manually" it will not negatively or adversely affect anything. These files are independent of one another, despite being identical in Deluge because we do not mutate or transform any .torrent files as qBittorrent does presently.

All of that is irrelevant though, because Deluge, uTorrent, and any other clients' implementation of the requested feature FOR QBIT both in functionality and methodology should not be your concern at all. If it didn't work in Deluge at all (for example), you would not be expected to make it non-functional in your implementation in qBit. I'm not sure where this thread was supposed to be headed.

None of the other client implementations are the responsibility of qBittorrent. None of the team here has any influence on or responsibility for them. The feature is being requested here, for this client, for the last ~10 years. That should be the focus.

Other clients were cited as reasons why this feature was being requested because, partially, this feature was previously made available in them and found to be worthwhile and useful to users. Whether or not it functioned in a similar way to how it may in qBittorrent (or at all) has zero significance.

[vertigo220]

Either way, they're stored in some directory somewhere that qbittorrent knows about and can delete them from when requested.

That's not so. The files from the "BT_backup" folder you may be referring to are not real torrent files (it was a mistake to leave such extensions for them and "BT_backup" for their folder).

Actually, it is so. The option "Copy .torrent files to:" does exactly this. I assumed, as clearly did many others, this meant it was making a copy of the .torrent file for qbittorrent to use later, including to delete it when deleting the torrent. The confusing design of this option, combined with the option to delete the .torrent file when adding a torrent, where both act on the .torrent file at the same time, doing different things, while being located in two different subsections of the options, has caused a fair bit of confusion. This, along with the desire for different behavior (which, again, would be what many expected) is why I suggested a while back in this or another issue that the options be renamed. Regardless, to clarify for you and anyone else (bearing in mind I can only speak for myself), the behavior I, and I suspect many others, want, is that when I download a .torrent file and open it with qbittorrent, that it would be moved out of my Downloads folder and into a folder of my choosing that qbittorrent will then manage, deleting the .torrent files when a torrent is removed (optionally), while providing a local repo of .torrent files of those I haven't removed so I can use them as needed later. In addition, it would be highly preferable if it would keep the .torrent files in two separate directories, one for completed torrents that I haven't yet removed and one for incomplete torrents.

As for the BT_backup folder, I'm not sure why you say they aren't real torrent files. I just today spent, not for the first time, a fair amount of time going through and cleaning up (i.e. deleting) old .torrent files that are no longer needed, which is why this feature is so needed, because I spend (waste) a lot of time doing this every so often that it would be very nice to not have to, having qbittorrent do it automatically. In this process, I deleted a bunch of .torrent files in this directory. While they have random names instead of their original names, and so I had to open them with qbittorrent to see what they were, they were, in fact, "real" .torrent files.

That's it, nothing more complicated than that, not these wildly different requests that you suggest. You even say yourself "what kind of torrent files are we talking about" then go on to refer to option a) .torrent files, or option b) .torrent files.

You either misunderstood this or knowingly misinterpret me. These are really different options for implementation. Either we keep a link to the source files or to copies. Or maybe you want both? And what about the existing qBittorrent option "delete source .torrent files after adding a torrent"? How could it be integrated into this system of options?

Well then I misunderstood, because you weren't clear, simply saying "what kind of torrent files" when they're all .torrent files in this discussion. Perhaps you should have said which copy of the files. Anyways, as I mentioned, and as you even state here, the only difference between the two options you presented and claimed to be drastically different from one another is whether a copy is made that qbittorrent manages or it just manages the original file without making a copy. Ultimately, it's only a difference of one option, and minimal difference from the current options to integrate this. It already provides the option to store a copy and one to delete the original.

As I've proposed before, as mentioned above, I believe it would be best to combine these two options for clarity and simplicity into one, so the user chooses to either delete, copy, or move the original .torrent file or to do nothing with it. If it's deleted, it's obviously not tracked. If it's left, copied, or moved, and a secondary option to delete .torrent files when a torrent is deleted is enabled, its location, whether where it was moved to or if it was left in the original folder, will be tracked by qbittorrent to allow it to delete the file later. Or better yet, it should just always track them if they're not deleted, then give the option to delete them when deleting the torrent, like it does when asking whether to delete the content (ideally with an option to set its default, i.e. I'd want to be able to say to always check that option when deleting a torrent, and I'd have to uncheck it to keep the .torrent file, as opposed to always having to check it).

*regarding a copy option, this would complicate things a bit and I'm not even sure it's necessary, though I'm sure some would have reason for it so I wouldn't want to say it shouldn't exist. But either there would have to be agreement that when it's used, either the original or the copy should be tracked, or there would need to be a secondary option for choosing which one (or both).