"Set Location" won't change save path #101

Closed
opened 2026-02-21 14:52:24 -05:00 by deekerman · 35 comments
Owner

Originally created by @jendralhxr on GitHub (Sep 23, 2012).

When I want to reseed some torrent, I do:

  1. download the torrent
  2. set the save path to certain location in my hdd
  3. force recheck, once it's completed I can seed
    but sometimes "Set Location" simply won't change the torrent's save path

--I am running around 800 torrents if it matters

Originally created by @jendralhxr on GitHub (Sep 23, 2012). When I want to reseed some torrent, I do: 1) download the torrent 2) set the save path to certain location in my hdd 3) force recheck, once it's completed I can seed but sometimes "Set Location" simply won't change the torrent's save path --I am running around 800 torrents if it matters
deekerman 2026-02-21 14:52:24 -05:00
Author
Owner

@fk0 commented on GitHub (Sep 30, 2012):

very annoying bug... can't understand why report not in 'critical' state

@fk0 commented on GitHub (Sep 30, 2012): very annoying bug... can't understand why report not in 'critical' state
Author
Owner

@jendralhxr commented on GitHub (Sep 30, 2012):

I don't report it in critical state because there's still possible workaround:

  1. change the default download directory,
  2. download the torrent,
  3. recheck

The workaround works just fine--but "Set Location" doesn't do what it's supposed to do is kinda annoying :)

@jendralhxr commented on GitHub (Sep 30, 2012): I don't report it in critical state because there's still possible workaround: 1. change the default download directory, 2. download the torrent, 3. recheck The workaround works just fine--but "Set Location" doesn't do what it's supposed to do is kinda annoying :)
Author
Owner

@fk0 commented on GitHub (Oct 1, 2012):

well, I've got into the more annoying situation when the free space on my root (?) partition was exhausted and qbt somehow forced to change default location for every torrent I've downloaded, even for completed ones. This time there were a few of them but usually I have dozens. Frightening perspective for the next time....

@fk0 commented on GitHub (Oct 1, 2012): well, I've got into the more annoying situation when the free space on my root (?) partition was exhausted and qbt somehow forced to change default location for every torrent I've downloaded, even for completed ones. This time there were a few of them but usually I have dozens. Frightening perspective for the next time....
Author
Owner

@jendralhxr commented on GitHub (Oct 7, 2012):

@aelfwyne
I'm on Linux x64 so I don't think it has something to do with drives, but I've to admit my mount points is kind of messy :)

Just now, I moved 8 eps drama, 7 successfully set into the new location, but 1 simply couldn't :(
I hope the developers would seriously take this problem into their account.

@jendralhxr commented on GitHub (Oct 7, 2012): @aelfwyne I'm on Linux x64 so I don't think it has something to do with drives, but I've to admit my mount points is kind of messy :) Just now, I moved 8 eps drama, 7 successfully set into the new location, but 1 simply couldn't :( I hope the developers would seriously take this problem into their account.
Author
Owner

@seanssel commented on GitHub (Oct 17, 2012):

Applying the operation to a large group of torrents is time-consuming; the change won't immediately register for each torrent.

@seanssel commented on GitHub (Oct 17, 2012): Applying the operation to a large group of torrents is time-consuming; the change won't immediately register for each torrent.
Author
Owner

@baby-luck commented on GitHub (Jan 29, 2013):

Same here, "Set location..." fails quite a bit now. IIRC it's not so bad on running incomplete torrents but when stopped is worse.

@baby-luck commented on GitHub (Jan 29, 2013): Same here, "Set location..." fails quite a bit now. IIRC it's not so bad on running incomplete torrents but when stopped is worse.
Author
Owner

@attila-lendvai commented on GitHub (May 4, 2014):

my use-case: copy some stuff from SSD to mechanical drive, then change the save path in qbittorrent to the new directory with all the download content intact already. at first it seems to work, but switching to another torrent and back shows that the internal state is still the old save path.

@attila-lendvai commented on GitHub (May 4, 2014): my use-case: copy some stuff from SSD to mechanical drive, then change the save path in qbittorrent to the new directory with all the download content intact already. at first it seems to work, but switching to another torrent and back shows that the internal state is still the old save path.
Author
Owner

@aquada commented on GitHub (Nov 4, 2014):

I am using 3.1.8 and have this issue. Adding torrents with existing data in a non default location, try to set location, the save path is updated, but when trying to Force Recheck or Download it resorts to the default download path.

@aquada commented on GitHub (Nov 4, 2014): I am using 3.1.8 and have this issue. Adding torrents with existing data in a non default location, try to set location, the save path is updated, but when trying to Force Recheck or Download it resorts to the default download path.
Author
Owner

@ngosang commented on GitHub (Sep 3, 2015):

@glassez after your changes this still happens?

@ngosang commented on GitHub (Sep 3, 2015): @glassez after your changes this still happens?
Author
Owner

@baldmosher commented on GitHub (Jul 8, 2016):

I'm getting this on 3.3.5

Some of them are changing OK, the others are not

@baldmosher commented on GitHub (Jul 8, 2016): I'm getting this on 3.3.5 Some of them are changing OK, the others are not
Author
Owner

@glassez commented on GitHub (Jul 9, 2016):

I don't know whether this refers to the same problem. Recently I faced the following: after some torrent was completed, it looked like it was moved to complete folder (the path was updated both in the properties window and in the fastresume data), but actually the contents are in the incomplete folder. @sledgehammer999 It seems like bug in libtorrent. When I get something like that again, I'll try to deal with it.

@glassez commented on GitHub (Jul 9, 2016): I don't know whether this refers to the same problem. Recently I faced the following: after some torrent was completed, it looked like it was moved to complete folder (the path was updated both in the properties window and in the fastresume data), but actually the contents are in the incomplete folder. @sledgehammer999 It seems like bug in libtorrent. When I get something like that again, I'll try to deal with it.
Author
Owner

@baldmosher commented on GitHub (Jul 9, 2016):

I definitely found that it was trying to download some of my torrents again into the downloads folder rather than the set location. I just switched back to uTorrent -- much less annoying and easier to manage locations. I'm still using Qbit for my main box for the time being.

@baldmosher commented on GitHub (Jul 9, 2016): I definitely found that it was trying to download some of my torrents again into the downloads folder rather than the set location. I just switched back to uTorrent -- much less annoying and easier to manage locations. I'm still using Qbit for my main box for the time being.
Author
Owner

@jnieurzyla commented on GitHub (Dec 21, 2016):

Like Baldmosher, I feel I will have to also do that, I have retained all my torrents, after my C: crashed, but am unable to reseed them. a real shame. I wish QBT would sort this mess out. QBT does not have a proper save and recover program either, so trying to sort the mess is too much for most users.

@jnieurzyla commented on GitHub (Dec 21, 2016): Like Baldmosher, I feel I will have to also do that, I have retained all my torrents, after my C: crashed, but am unable to reseed them. a real shame. I wish QBT would sort this mess out. QBT does not have a proper save and recover program either, so trying to sort the mess is too much for most users.
Author
Owner

@dmos62 commented on GitHub (Dec 22, 2016):

I have used qbittorent extensively and I absolutely support the cause of a free (libre) client. However, when it comes to edge cases, Tixati has solved my problems. It's a very well done client.

@dmos62 commented on GitHub (Dec 22, 2016): I have used qbittorent extensively and I absolutely support the cause of a free (libre) client. However, when it comes to edge cases, Tixati has solved my problems. It's a very well done client.
Author
Owner

@maxiwheat commented on GitHub (Feb 5, 2017):

+1 ... What's the use of "Set Location" if it just wont work as advertised. I copied my completed torrents to a new location manually, then paused the torrents and tried to "Set Location" to the new location... but it just won't change... :-/ Really annoying!

@maxiwheat commented on GitHub (Feb 5, 2017): +1 ... What's the use of "Set Location" if it just wont work as advertised. I copied my completed torrents to a new location manually, then paused the torrents and tried to "Set Location" to the new location... but it just won't change... :-/ Really annoying!
Author
Owner

@glassez commented on GitHub (Feb 6, 2017):

What's the use of "Set Location" if it just wont work as advertised. I copied my completed torrents to a new location manually, then paused the torrents and tried to "Set Location" to the new location... but it just won't change... :-/ Really annoying!

@sledgehammer, The misunderstanding arises because of the wrong wording here. The right word is "Move" or (even better) "Relocate".

@maxiwheat, "Set Location" is for moving torrent content (complete and still incomplete) to another place. It's not for pointing to another content. Your actions confuse the program.

@glassez commented on GitHub (Feb 6, 2017): >What's the use of "Set Location" if it just wont work as advertised. I copied my completed torrents to a new location manually, then paused the torrents and tried to "Set Location" to the new location... but it just won't change... :-/ Really annoying! @sledgehammer, The misunderstanding arises because of the wrong wording here. The right word is "Move" or (even better) "Relocate". @maxiwheat, "Set Location" is for moving torrent content (complete and still incomplete) to another place. It's not for pointing to another content. Your actions confuse the program.
Author
Owner

@maxiwheat commented on GitHub (Feb 6, 2017):

@glassez So, is there a "recommended" way of doing what I (and others) just said ? Pointing the torrent to the existing files location and expect qBT to "resume" from there ?

@maxiwheat commented on GitHub (Feb 6, 2017): @glassez So, is there a "recommended" way of doing what I (and others) just said ? Pointing the torrent to the existing files location and expect qBT to "resume" from there ?
Author
Owner

@glassez commented on GitHub (Feb 6, 2017):

"Pointing the torrent to the existing files location" is possible only for newly added torrent (if I remember correctly). If you want to move files of torrent from the session, then just use "Set Location" and allow qBittorrent to move files.
If you want move existing torrent content manually (why?) you may delete torrent from session (not deleting its content from disk) then move files manually and finally re-add the torrent pointing its save path to existing files path.

@glassez commented on GitHub (Feb 6, 2017): "Pointing the torrent to the existing files location" is possible only for newly added torrent (if I remember correctly). If you want to move files of torrent from the session, then just use "Set Location" and allow qBittorrent to move files. If you want move existing torrent content manually (why?) you may delete torrent from session (not deleting its content from disk) then move files manually and finally re-add the torrent pointing its save path to existing files path.
Author
Owner

@attila-lendvai commented on GitHub (Feb 6, 2017):

"Set torrent location" in english means to change the directory where the data is to be downloaded. it does not hint in any way that the already downloaded data will be moved, and in fact it hints just the opposite.

i suggest another label, something like: "Move data files", or "Move downloaded data"

it has also totally confused me until i have read the last few comments here above. because of the wording i assumed that qBt doesn't support moving the files, just setting the location (and then manually requesting the rechecking of the files).

@attila-lendvai commented on GitHub (Feb 6, 2017): "Set torrent location" in english means to change the directory where the data is to be downloaded. it does not hint in any way that the already downloaded data will be moved, and in fact it hints just the opposite. i suggest another label, something like: "Move data files", or "Move downloaded data" it has also totally confused me until i have read the last few comments here above. because of the wording i assumed that qBt doesn't support moving the files, just setting the location (and then manually requesting the rechecking of the files).
Author
Owner

@sledgehammer999 commented on GitHub (Feb 6, 2017):

"Pointing the torrent to the existing files location" is possible only for newly added torrent (if I remember correctly). If you want to move files of torrent from the session, then just use "Set Location" and allow qBittorrent to move files.
If you want move existing torrent content manually (why?) you may delete torrent from session (not deleting its content from disk) then move files manually and finally re-add the torrent pointing its save path to existing files path.

Actually torrent_handle::move_storage() (after my suggestion a long time ago) can now take an extra parameter to indicate what to do when libtorrent encounters the same filenames in the new path.
3 possible values:

  1. always_replace_files is the default and replaces any file that exist in both the source directory and the target directory.
  2. fail_if_exist first check to see that none of the copy operations would cause an overwrite. If it would, it will fail. Otherwise it will proceed as if it was in always_replace_files mode. Note that there is an inherent race condition here. If the files in the target directory appear after the check but before the copy or move completes, they will be overwritten. When failing because of files already existing in the target path, the error of move_storage_failed_alert is set to boost::system::errc::file_exists. The intention is that a client may use this as a probe, and if it fails, ask the user which mode to use. The client may then re-issue the move_storage call with one of the other modes.
  3. dont_replace always takes the existing file in the target directory, if there is one. The source files will still be removed in that case.

But I never got around in exposing it via the GUI.(or implement a dialog for the user to be asked).

@sledgehammer999 commented on GitHub (Feb 6, 2017): >"Pointing the torrent to the existing files location" is possible only for newly added torrent (if I remember correctly). If you want to move files of torrent from the session, then just use "Set Location" and allow qBittorrent to move files. If you want move existing torrent content manually (why?) you may delete torrent from session (not deleting its content from disk) then move files manually and finally re-add the torrent pointing its save path to existing files path. Actually `torrent_handle::move_storage()` (after my suggestion a long time ago) can now take an extra parameter to indicate what to do when libtorrent encounters the same filenames in the new path. 3 possible values: 1. `always_replace_files` is the default and replaces any file that exist in both the source directory and the target directory. 2. `fail_if_exist` first check to see that none of the copy operations would cause an overwrite. If it would, it will fail. Otherwise it will proceed as if it was in `always_replace_files` mode. Note that there is an inherent race condition here. If the files in the target directory appear after the check but before the copy or move completes, they will be overwritten. When failing because of files already existing in the target path, the error of `move_storage_failed_alert` is set to `boost::system::errc::file_exists`. The intention is that a client may use this as a probe, and if it fails, ask the user which mode to use. The client may then re-issue the move_storage call with one of the other modes. 3. `dont_replace` always takes the existing file in the target directory, if there is one. The source files will still be removed in that case. But I never got around in exposing it via the GUI.(or implement a dialog for the user to be asked).
Author
Owner

@sledgehammer999 commented on GitHub (Feb 6, 2017):

PS: We could rename the menu item to "Relocate..." or "Move..." But it will still confuse users that download to a temp location (Keep incomplete torrents in: feature)

@sledgehammer999 commented on GitHub (Feb 6, 2017): PS: We could rename the menu item to "Relocate..." or "Move..." But it will still confuse users that download to a temp location (`Keep incomplete torrents in:` feature)
Author
Owner

@maxiwheat commented on GitHub (Feb 6, 2017):

If you want move existing torrent content manually (why?) you may delete torrent from session (not deleting its content from disk) then move files manually and finally re-add the torrent pointing its save path to existing files path.

Sometimes moving files is expensive (and time consuming)... qBT doesn't provide any visual cue of the progression when moving files around. It also happened to me with a bad hard drive (very slow) to just freeze all transfers/seeds while moving files ... moving them manually made sense to me (visual cue and don't freeze qBT)

@maxiwheat commented on GitHub (Feb 6, 2017): > If you want move existing torrent content manually (why?) you may delete torrent from session (not deleting its content from disk) then move files manually and finally re-add the torrent pointing its save path to existing files path. Sometimes moving files is expensive (and time consuming)... qBT doesn't provide any visual cue of the progression when moving files around. It also happened to me with a bad hard drive (very slow) to just freeze all transfers/seeds while moving files ... moving them manually made sense to me (visual cue and don't freeze qBT)
Author
Owner

@baldmosher commented on GitHub (Feb 6, 2017):

I always copy files to the new location before trying to change the "Set..." location in qBT. But this still doesn't always work and with no visual feedback other than it simply not changing the location. From my p.o.v. as long as the location in qBT is actually changed, I can easily overcome problems with file mismatches.

@baldmosher commented on GitHub (Feb 6, 2017): I always copy files to the new location before trying to change the "Set..." location in qBT. But this still doesn't always work and with no visual feedback other than it simply not changing the location. From my p.o.v. as long as the location in qBT is actually changed, I can easily overcome problems with file mismatches.
Author
Owner

@vctls commented on GitHub (May 25, 2017):

This behaviour is just unacceptable. It can easily lead to loss of data. Moving back to another client.

@vctls commented on GitHub (May 25, 2017): This behaviour is just unacceptable. It can easily lead to loss of data. Moving back to another client.
Author
Owner

@glassez commented on GitHub (May 26, 2017):

So "Don't replace existing files" is expected behavior of "Set location"?

@glassez commented on GitHub (May 26, 2017): So "Don't replace existing files" is expected behavior of "Set location"?
Author
Owner

@quiet23 commented on GitHub (Jul 27, 2017):

I encrypted a non-system partition recently using TrueCrypt. Some of completed torrents that were seeded were on the partition. Now QBT displays I/O Error message for all of them because the assigned drive letter for the partition had changed and the previous drive letter now points to the encrypted partition that is recognized as having raw filesystem (not formatted; this is how TrueCrypt works). "Set Location..." option does nothing for the torrents.
The only way how I previously solved the situation was to delete the torrent, find corresponding torrent file in QBT BT_backup folder and readd the torrent pointing to the new location of the downloaded content. It is VERY time consuming and annoying. Please fix the bug.
I use QBT 3.3.14 64-bit on Win8.1 64-bit.

@quiet23 commented on GitHub (Jul 27, 2017): I encrypted a non-system partition recently using TrueCrypt. Some of completed torrents that were seeded were on the partition. Now QBT displays I/O Error message for all of them because the assigned drive letter for the partition had changed and the previous drive letter now points to the encrypted partition that is recognized as having raw filesystem (not formatted; this is how TrueCrypt works). "Set Location..." option does nothing for the torrents. The only way how I previously solved the situation was to delete the torrent, find corresponding torrent file in QBT BT_backup folder and readd the torrent pointing to the new location of the downloaded content. It is VERY time consuming and annoying. Please fix the bug. I use QBT 3.3.14 64-bit on Win8.1 64-bit.
Author
Owner

@slorrin commented on GitHub (Apr 1, 2018):

I solved this! Bothering me for a long time.

In settings, for download, unclick "store incomplete torrents in xxxxx/temp" or whatever the directory is. When you move the data, and then the directory, and "recheck", it's looking for it in the temp directory for absolutely no reason. So I unchecked that setting, and it looked in my new director, and I got a popup saying "so and so has finished downloading" for all my torrents.

@slorrin commented on GitHub (Apr 1, 2018): I solved this! Bothering me for a long time. In settings, for download, unclick "store incomplete torrents in xxxxx/temp" or whatever the directory is. When you move the data, and then the directory, and "recheck", it's looking for it in the temp directory for absolutely no reason. So I unchecked that setting, and it looked in my new director, and I got a popup saying "so and so has finished downloading" for all my torrents.
Author
Owner

@xakepp35 commented on GitHub (Apr 12, 2018):

vote up/ i downloaded torrent contents for instance to network path \192.168.1.1\t$ and now its unavailble (for instance disk was killed with a hammer) i cant just move or redownload it to \192.168.1.1\f$ because previous path is no longer availble.. i changed "Set location.." but it wont help and torrent in errored state because in cant access previous Save Path (it remained the same). So i got reciepe now 1) downoad torrent fo folder A. 2) make it no longer availble so io errors 3) shit bricks with just latest qbittorrent - either redownload or call a shaman for dance

@xakepp35 commented on GitHub (Apr 12, 2018): vote up/ i downloaded torrent contents for instance to network path \\192.168.1.1\t$ and now its unavailble (for instance disk was killed with a hammer) i cant just move or redownload it to \\192.168.1.1\f$ because previous path is no longer availble.. i changed "Set location.." but it wont help and torrent in errored state because in cant access previous Save Path (it remained the same). So i got reciepe now 1) downoad torrent fo folder A. 2) make it no longer availble so io errors 3) shit bricks with just latest qbittorrent - either redownload or call a shaman for dance
Author
Owner

@KristupasSavickas commented on GitHub (Jan 25, 2019):

@slorrin thanks, you suggestion solved my issue.

@KristupasSavickas commented on GitHub (Jan 25, 2019): @slorrin thanks, you suggestion solved my issue.
Author
Owner

@voycey commented on GitHub (Aug 20, 2019):

How is this still an issue after 7 years? So frustrating!
Unfortunately @slorrin 's solution doesnt work for me!

@voycey commented on GitHub (Aug 20, 2019): How is this still an issue after 7 years? So frustrating! Unfortunately @slorrin 's solution doesnt work for me!
Author
Owner

@eldertiger commented on GitHub (Sep 10, 2019):

The temp directory is used for something like SSD, you can download files directly in SSD to avoid arbitory IO in a HDD, after completion of the torrent, the file will automatically move to the destination you set. However, change the location manully in right click menue sometimes does nothing after several hours later I checked it. And it seems the original file is broken somehow because I can only move it to another destination in a speed of 1M/s which is weired. I would recommend using copy and restart the torrent and set the new directory and skip the hash check.

@eldertiger commented on GitHub (Sep 10, 2019): The temp directory is used for something like SSD, you can download files directly in SSD to avoid arbitory IO in a HDD, after completion of the torrent, the file will automatically move to the destination you set. However, change the location manully in right click menue sometimes does nothing after several hours later I checked it. And it seems the original file is broken somehow because I can only move it to another destination in a speed of 1M/s which is weired. I would recommend using copy and restart the torrent and set the new directory and skip the hash check.
Author
Owner

@thezman007 commented on GitHub (Oct 1, 2019):

I just wanted to add that I faced this issue when moving from a shared folder to a mapped drive. Most torrents moved as expected, but some of my torrents simply wouldn't move over. I found that the files were in both locations but qBittorrent refused to recognize the "new" location. I created a folder in the "old" location and moved the files into it ( I didn't want to delete them in case something went wrong). This way the files were no longer available in the place qB expected. Next, I went back into qB and set the location to the mapped drive where I wanted them to be. Worked just fine after that and qB is no longer looking for files in the "old" location.

THIS SOLVED IT FOR ME, I hope it helps someone else. Good luck!

@thezman007 commented on GitHub (Oct 1, 2019): I just wanted to add that I faced this issue when moving from a shared folder to a mapped drive. Most torrents moved as expected, but some of my torrents simply wouldn't move over. I found that the files were in both locations but qBittorrent refused to recognize the "new" location. I created a folder in the "old" location and moved the files into it ( I didn't want to delete them in case something went wrong). This way the files were no longer available in the place qB expected. Next, I went back into qB and set the location to the mapped drive where I wanted them to be. Worked just fine after that and qB is no longer looking for files in the "old" location. THIS SOLVED IT FOR ME, I hope it helps someone else. Good luck!
Author
Owner

@rudolphos commented on GitHub (Feb 28, 2020):

Still having this issue.. One disk is full. I set location to another drive. Pause. Recheck. Start again. Open destination folder and it opens the same old folder...

@rudolphos commented on GitHub (Feb 28, 2020): Still having this issue.. One disk is full. I set location to another drive. Pause. Recheck. Start again. Open destination folder and it opens the same old folder...
Author
Owner

@ghost commented on GitHub (Dec 5, 2020):

Since 4.3.0 you'll get a notification+log if a move failed. Most commonly moves fail because of a lack of space in the source or destination drive. The source drive also needs to have some free space to buffer the move process.
The location won't be updated unless the move succeeds. I think that should be enough to close this issue?
@FranciscoPombal

For reference https://github.com/qbittorrent/qBittorrent/pull/13151

@ghost commented on GitHub (Dec 5, 2020): Since 4.3.0 you'll get a notification+log if a move failed. Most commonly moves fail because of a lack of space in the source or destination drive. The source drive also needs to have some free space to buffer the move process. The location won't be updated unless the move succeeds. I think that should be enough to close this issue? @FranciscoPombal For reference https://github.com/qbittorrent/qBittorrent/pull/13151
Author
Owner

@FranciscoPombal commented on GitHub (Dec 6, 2020):

@an0n666

Yep, this is fixed as far as I can tell - tested in 4.3.1 on Windows with a couple of different disks.


If you have any issues with the latest version, please open a new issue report.

Thank you for your contributions.

@FranciscoPombal commented on GitHub (Dec 6, 2020): @an0n666 Yep, this is fixed as far as I can tell - tested in 4.3.1 on Windows with a couple of different disks. --- If you have any issues with the latest version, please open a new issue report. Thank you for your contributions.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/qBittorrent#101
No description provided.