mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
"Set Location" won't change save path #101
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#101
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jendralhxr on GitHub (Sep 23, 2012).
When I want to reseed some torrent, I do:
but sometimes "Set Location" simply won't change the torrent's save path
--I am running around 800 torrents if it matters
@fk0 commented on GitHub (Sep 30, 2012):
very annoying bug... can't understand why report not in 'critical' state
@jendralhxr commented on GitHub (Sep 30, 2012):
I don't report it in critical state because there's still possible workaround:
The workaround works just fine--but "Set Location" doesn't do what it's supposed to do is kinda annoying :)
@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....
@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.
@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.
@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.
@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.
@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.
@ngosang commented on GitHub (Sep 3, 2015):
@glassez after your changes this still happens?
@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
@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.
@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.
@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.
@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.
@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!
@glassez commented on GitHub (Feb 6, 2017):
@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.
@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 ?
@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.
@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).
@sledgehammer999 commented on GitHub (Feb 6, 2017):
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:
always_replace_filesis the default and replaces any file that exist in both the source directory and the target directory.fail_if_existfirst 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 inalways_replace_filesmode. 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 ofmove_storage_failed_alertis set toboost::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.dont_replacealways 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):
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)@maxiwheat commented on GitHub (Feb 6, 2017):
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)
@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.
@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.
@glassez commented on GitHub (May 26, 2017):
So "Don't replace existing files" is expected behavior of "Set location"?
@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.
@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.
@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
@KristupasSavickas commented on GitHub (Jan 25, 2019):
@slorrin thanks, you suggestion solved my issue.
@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!
@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.
@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!
@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...
@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
@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.