starred/qBittorrent

Fork 0

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

clicking 'set this as the default directory' in torrent dl save dialog moves all torrents to that directory #3160

New issue

Closed

opened 2026-02-21 16:37:00 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-21 16:37:00 -05:00

Owner

Originally created by @WaterSibilantFalling on GitHub (Oct 6, 2015).

Linux 4.1.0-2-rt-686-pae #1 SMP PREEMPT RT Debian 4.1.6-1 (2015-08-23) i686 GNU/Linux

qBittorrent 3.3.0 beta

As per the subject line, clicking Save As > Set as Default Save Path in torrent download save dialog moves all of my already completed torrents to that directory. I only realized when the device filled up. That's all my torrents (until I stopped it)

Options> Downloads > Hard Disk > "Save Files To Locatiion" is then set to this location, and can not be cleared - I can't clear it, I can't make it blank, and any non-existent directory that I type into it is created, and all of my completed torrents are then moved into that directory.

I would imagine that this is a bug.

As a work-around, I have made an unreadable, unwriteable directory, and set that as the default Options> Downloads > Hard Disk > "Save Files To Locatiion". So no problems with that in the future.

But this has caused another problem: qBittorrent now claims that the files it had moved to the (formerly) non-existent directory that it, qBittorrent, then created (I have moved them all back by hand and deleted that directory) are now in the empty unreadable-unwriteable directory that I made. One is even 'seeding' out of that directory.

Originally created by @WaterSibilantFalling on GitHub (Oct 6, 2015). Linux 4.1.0-2-rt-686-pae #1 SMP PREEMPT RT Debian 4.1.6-1 (2015-08-23) i686 GNU/Linux qBittorrent 3.3.0 beta As per the subject line, clicking Save As > Set as Default Save Path in torrent download save dialog moves all of my already completed torrents to that directory. I only realized when the device filled up. That's all my torrents (until I stopped it) Options> Downloads > Hard Disk > "Save Files To Locatiion" is then set to this location, and can not be cleared - I can't clear it, I can't make it blank, and any non-existent directory that I type into it is created, and all of my completed torrents are then moved into that directory. I would imagine that this is a bug. As a work-around, I have made an unreadable, unwriteable directory, and set that as the default Options> Downloads > Hard Disk > "Save Files To Locatiion". So no problems with that in the future. But this has caused another problem: qBittorrent now claims that the files it had moved to the (formerly) non-existent directory that it, qBittorrent, then created (I have moved them all back by hand and deleted that directory) are now in the empty unreadable-unwriteable directory that I made. One is even 'seeding' out of that directory.

deekerman closed this issue

2026-02-21 16:37:02 -05:00

deekerman commented

2026-02-21 16:37:05 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Oct 6, 2015):

related to #468

A better work-around is to make a real, empty and spacious directory as the Options> Downloads > Hard Disk > "Save Files To Locatiion" directory, let all the files be moved automatically by qBittorrent to to there, and then individually Set Location for each torrent back to their correctly locations.

For each completed torrent now assigned to my unreadable-unwriteable directory, I will do "Copy Magnet Link", delete the torrent, add the link, set the directory to the correct location, force a check, and all should be ok.

I will then set the Options> Downloads > Hard Disk > "Save Files To Locatiion" to the unreadable-unwriteable , and all should be ok - no more automatic moves by qBittorrent.

Note that I am currently checking alll my torrents in qBittorrent, but by using fnotifystat I can see that no checking is taking place, only the on-going, unapproved by me, movement off torrents to this Options> Downloads > Hard Disk > "Save Files To Locatiion", a new, empty directory.

There should be no ability for qBittorrent to move any completed torrent files without explicit approval of the user. One of my partitions filling up wasn't such a big deal, but it's not really cool.

@WaterSibilantFalling commented on GitHub (Oct 6, 2015): related to #468 A better work-around is to make a real, empty and spacious directory as the Options> Downloads > Hard Disk > "Save Files To Locatiion" directory, let all the files be moved automatically by qBittorrent to to there, and then individually Set Location for each torrent back to their correctly locations. For each completed torrent now assigned to my unreadable-unwriteable directory, I will do "Copy Magnet Link", delete the torrent, add the link, set the directory to the correct location, force a check, and all should be ok. I will then set the Options> Downloads > Hard Disk > "Save Files To Locatiion" to the unreadable-unwriteable , and all should be ok - no more automatic moves by qBittorrent. Note that I am currently checking alll my torrents in qBittorrent, but by using fnotifystat I can see that no checking is taking place, only the on-going, unapproved by me, movement off torrents to this Options> Downloads > Hard Disk > "Save Files To Locatiion", a new, empty directory. There should be no ability for qBittorrent to move any completed torrent files without explicit approval of the user. One of my partitions filling up wasn't such a big deal, but it's not really cool.

deekerman commented

2026-02-21 16:37:05 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 8, 2015):

Are you using "Keep incomplete torrents in:" or "append labels to save path"? Or both?
PR #3649 might be relevant
tagging @glassez to keep an eye on it too.

@sledgehammer999 commented on GitHub (Oct 8, 2015): Are you using "Keep incomplete torrents in:" or "append labels to save path"? Or both? PR #3649 might be relevant tagging @glassez to keep an eye on it too.

deekerman commented

2026-02-21 16:37:05 -05:00

Author

Owner

@glassez commented on GitHub (Oct 8, 2015):

@RichardWilliamPearse This is not a bug. It's just unfinished/experimental feature (version 3.3 is still under development/testing). We'll fix it for release. For more details, see #3495.

@glassez commented on GitHub (Oct 8, 2015): @RichardWilliamPearse This is not a bug. It's just unfinished/experimental feature (version 3.3 is still under development/testing). We'll fix it for release. For more details, see #3495.

deekerman commented

2026-02-21 16:37:05 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Oct 11, 2015):

Ah, yes, it is #3495. Thank you. I always search before posting, but I must have chosen incorrect search terms or something.

I read your discussions. Can I add that moving a user's torrents with out aboslutely and definitely getting their approval should be, has to be, completly out-of-consideration. Moving possibly huge amounts of data could lead to a partiton filling up - it did in my case - which could lead to a computer crashing or not responding appropriately. One time out of 100 this will, in turn, lead to some genuine, real world, incident. That is an unacceptable situation: it must not happen. You should even refuse to do it if the use approves but the resulting situation would be a partition more that 99% full.

@WaterSibilantFalling commented on GitHub (Oct 11, 2015): Ah, yes, it is #3495. Thank you. I always search before posting, but I must have chosen incorrect search terms or something. I read your discussions. Can I add that moving a user's torrents with out aboslutely and definitely getting their approval should be, has to be, completly out-of-consideration. Moving possibly huge amounts of data could lead to a partiton filling up - it did in my case - which could lead to a computer crashing or not responding appropriately. One time out of 100 this will, in turn, lead to some genuine, real world, incident. That is an unacceptable situation: it must not happen. You should even refuse to do it if the use approves but the resulting situation would be a partition more that 99% full.

deekerman commented

2026-02-21 16:37:06 -05:00

Author

Owner

@glassez commented on GitHub (Oct 24, 2015):

@sledgehammer999 Doesn't #3649 close this issue?

@glassez commented on GitHub (Oct 24, 2015): @sledgehammer999 Doesn't #3649 close this issue?

deekerman commented

2026-02-21 16:37:06 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 24, 2015):

Yes, I think it was fixed by #3649.

@sledgehammer999 commented on GitHub (Oct 24, 2015): Yes, I think it was fixed by #3649.

deekerman commented

2026-02-21 16:37:06 -05:00

Author

Owner

@snadsnad commented on GitHub (Dec 6, 2015):

This is not fixed. I WAS running 3.3.0 on Windows but just backed down to 3.2.5 because I woke up this morning to 2000 torrents having been moved to the default download directly for some incredibly stupid reason after they had been finished. Some of these had been done for 5 plus years. NOW I have to move thousands of files by hand back to their original location and hope qBittorrent doesn't fuck it all up again. Thanks.

@snadsnad commented on GitHub (Dec 6, 2015): This is not fixed. I WAS running 3.3.0 on Windows but just backed down to 3.2.5 because I woke up this morning to 2000 torrents having been moved to the default download directly for some incredibly stupid reason after they had been finished. Some of these had been done for 5 plus years. NOW I have to move thousands of files by hand back to their original location and hope qBittorrent doesn't fuck it all up again. Thanks.

deekerman commented

2026-02-21 16:37:06 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Dec 6, 2015):

@snadsnad I suppose you use "watched folders". There is a bug in v3.3.0 which is fixed for v3.3.1. It will be released either today or tomorrow.

@sledgehammer999 commented on GitHub (Dec 6, 2015): @snadsnad I suppose you use "watched folders". There is a bug in v3.3.0 which is fixed for v3.3.1. It will be released either today or tomorrow.