Relocate Feature

[maya923]

If there's a way to do this, please let me know.

Some of my torrent's data are in sub-folders, for example:

/Artist
/Year - Album Title

And after the torrent seeds, I end up wanting to take the files out and rename the root folder like so: "Artist - Album Title (Year) [Format].

In uTorrent, using the Relocate feature, I was able to right-click on each of the files within that sub-folder, and point it to the file directly, that way when the torrent is force-rechecked, it bypasses the sub-folder and everything checks out.

Is this implemented in qBitTorrent, or could it be? It's really the only thing keeping me from converting 100% to Linux.

Thank you!

[Belove0]

I agree, I find this very restrictive. I "need" to be able to use the files I download, where I use them, and be able to seed them as well. This can also allow for doing things like seeding the same files from multiple torrents concurrently.

[sledgehammer999]

In the Content tab if you right click a folder/file you can rename it. Rename the root folder also and I think you can achieve what you ask. I will close this. If I am wrong please comment and I will reopen this.

[Belove0]

Hi, that's a bit different than the request.

Renaming the root folder works very nicely, and allows having a different-named root folder. It does not change the folder the root is in, but that feature is provided by right-clicking the torrent and changing the save directory.

Those are good features that in combination, relocate all the files together in a good way.

EDIT: Yes, you can rename individual files, but you cannot change their location in the file system independently from the torrent. Subfoders of the torrent can get a new name, but files can't even be "relocated" within the torrent's root. It occurred to me to attempt that by renaming to a name with a backslash in it, but Qbittorrent doesn't support that.

However, I believe the request is for the ability to relocate all files and folders in the torrent independently, as you can in uTorrent. Torrents aren't always packaged together in the way that the files are most useful to a downloader.

This request would compound problems for users if this data could be lost in certain circumstances, ala #569, #468, and others. So that might be good to consider any confirmed bugs that will specifically relate to the implementation of this as a dependency/dependencies.

[sledgehammer999]

Well yes, I can see the use case now. Relocate is for when the user wants to move the files outside of the root folder and/or change file structure entirely.

I think I saw such a capability in the libtorrent API somewhere....

[sledgehammer999]

Looking at it again, I cannot find something in the libtorrent API. So with the current libtorrent interface this feature cannot be implemented in qbittorrent.

[Belove0]

I wonder what happens if rename_file is passed a full path?

[sledgehammer999]

I don't think rename_file works that way. I don't have time to test it.
move_storage() moves the entire torrent. We are talking of moving only individual files out of a multifile torrent

[cdumez]

@sledgehammer999 I believe rename_file() does that. It takes the relative path of the file within the torrent in argument.

[sledgehammer999]

hmm, ok I'll give it a go sometime in the next hours...

[sledgehammer999]

@cdumez It seems that rename_file does allow to specify a relative path. It is cumbersome to work with though. It doesn't seem to accept absolute paths. This has a side-effect that if you pass the same relative path twice, the second time you pass it the path will be created again under the first time's path. Also if you just pass the original filename it will not put the file back at its original place.

[Belove0]

@sledgehammer999 So if a move is intended, the relative path has to be specified in relation to the CURRENT path (relative to the save location for the torrent)? This could involve "../../../newpath/filename" and the like?

I noticed in the libtorrent docs something about custom overrides [any sic mine] for the file access stuff possible, where you can build on/override the existing behavior to suit your needs.

Also, in their changelog they did show recent improvements to the behavior of rename_file() when moving folders, so there might be someone on that project with enough interest to implement absolute path support.

[sledgehammer999]

Also, in their changelog they did show recent improvements to the behavior of rename_file() when moving folders, so there might be someone on that project with enough interest to implement absolute path support.

Maybe, but I think we need an additional API to query the current filepath of each file. I'll try to open a bug report upstream and see what happens. (I'll back link here too)

[Gelmir]

I noticed in the libtorrent docs something about custom overrides [any sic mine] for the file access stuff possible

http://www.rasterbar.com/products/libtorrent/manual.html#storage-interface

This would require reimplementing the whole storage_interface class.

[sledgehammer999]

Appropriate label attached.
Also upstream bug: https://code.google.com/p/libtorrent/issues/detail?id=472&thanks=472&

[Belove0]

I noticed in the libtorrent docs something about custom overrides [any sic mine] for the file access stuff possible

http://www.rasterbar.com/products/libtorrent/manual.html#storage-interface

This would require reimplementing the whole storage_interface class.

@Gelmir - Can't a derived class only reimplement those functions it needs to?
I'm not suggesting it's the simplest or best solution.. I don't have the knowledge/expertise. At all :).
Hopefully the update is taken on upstream where it will likely be simpler and benefit all the downstream projects.

[sledgehammer999]

Hmm this may be feasible after all. Problem was that not all public API had doc pages. I am talking about file_entry and file_storage.

Suggestion to try:

1. New menu item 'Relocation that pops a dir-selection-dialog
2. Construct relevant path from source to destination path (QDir probably provides a function for this)
3. Wait for the file_renamed_alert and check it's 'name' attribute. If it contains folders(QDir again?), update the content treeview accordingly. Otherwise examine the file_entry::path for this particular file.

[Belove0]

there's a patch upstream, and I'd be happy to test it if this makes a test build or whatever. Espcially with Gulmir's RSS early download patch included 💃 :D

[Gelmir]

By the way. Last time I checked storage move blocked all other torrents.

[sledgehammer999]

Yeap I have seen the patch, but currently I am too busy to test and use it in qbt. @Gelmir you are free to work on this if you want. I wont touch this feature for several days from now anyway.

By the way. Last time I checked storage move blocked all other torrents.

+1 but I am not sure about that. At least I know for sure that if you move multiple torrents, the move happens sequentially. Also if you move one torrent and force recheck another one, the second one will be queued.

[Belove0]

Should this still be flagged "waiting API implementation"?

[sledgehammer999]

It shouldn't but I'll leave it on, because I want to find this issue quickly. When I find time I'll implement it. If I remove the tag it will be lost in the flood of "wishlist" items.

[910nico]

I remember, this feature is very important to encourage seeding,
for example with utorrent i was seeding dragon ball videos collection (100GB) and i restructured the folders for a use with Plex.(cause seasons from torrent were not structured like seasons from the thetvdb.com)
But since i use qb i just deleted this torrent cause i can't restructure folders :( so i have the files but i can't seed them :'

[Lightborne]

trackers are starting to ban utorrent 3.4.2 left and right (and rightfully so) I really want to switch but this feature is super important to me! I hope it makes it in soon.

[4rev4]

This is the only missing feature that's keeping me from switching from uTorrent.

Every other thing I can deal with but this makes it impossible to migrate my massive library of torrents.

[welp-ops]

I believe as of 2016 libtorrent supports renaming files to absolute paths, meaning this issue can be solved without additional upstream support.

That being said, I'm a bit confused at why so many people want this implemented. What can you do with a relocate feature that you cannot do by renaming files in the "add torrent" dialog and then setting "do not create subfolder"?

[jathek]

That being said, I'm a bit confused at why so many people want this implemented. What can you do with a relocate feature that you cannot do by renaming files in the "add torrent" dialog and then setting "do not create subfolder"?

You can point torrent files at absolute paths that are outside the directory structure of the torrent, which is not possible with just renaming files. Or even just flatten torrents. If the torrent has a structure like this:

/nfo
/season 1
/season 1/Episode 1
/season 1/Episode 2

You could flatten it with absolute paths to:

/nfo
/Episode 1
/Episode 2

Getting rid of that "Season 1" folder is impossible without absolute path support.

[maya923]

My original request was for torrents already downloaded and then just seeding if that helps any. However, I am so over this. It’s just funny to see people talk about it.

…

On Aug 20, 2021 at 7:32:15 PM, nearcatch ***@***.***> wrote: That being said, I'm a bit confused at why so many people want this implemented. What can you do with a relocate feature that you cannot do by renaming files in the "add torrent" dialog and then setting "do not create subfolder"? You can point torrent files at absolute paths that are outside the directory structure of the torrent, which is not possible with just renaming files. Or even just flatten torrents. If the torrent has a structure like this: /nfo /season 1 /season 1/Episode 1 /season 1/Episode 2 You could flatten it with absolute paths to: /nfo /Episode 1 /Episode 2 Getting rid of that "Season 1" folder is impossible without absolute path support. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXTWTA6J4PE7PPJZXBCGADT53QX7ANCNFSM4ADPXULQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[Aurareus]

That being said, I'm a bit confused at why so many people want this implemented. What can you do with a relocate feature that you cannot do by renaming files in the "add torrent" dialog and then setting "do not create subfolder"?

You can point torrent files at absolute paths that are outside the directory structure of the torrent, which is not possible with just renaming files. Or even just flatten torrents. If the torrent has a structure like this:

/nfo
/season 1
/season 1/Episode 1
/season 1/Episode 2

You could flatten it with absolute paths to:

/nfo
/Episode 1
/Episode 2

Getting rid of that "Season 1" folder is impossible without absolute path support.

Exactly this.
Without being able to point to absolute paths it essentially becomes impossible to have your own file organization and still seed a torrent's content, unless you keep a second copy of files just for seeding.
Also it often makes it impossible to cross-seed the same data on different trackers simply because the uploaders have used a different directory structure.

Someone should really remove the "Waiting upstream" tag.

[Traeskie]

First off: I'm just a user, and I don't want to get anyones hopes up, but...

I've been trying to get this to work using v4.4.0beta3 in Windows.
Was a while since I last tried this, but there seems to have been some progress. Not sure if deliberate or just a side effect of something else?

I have only done a quick test, but both upload and download seem to work in the scenarios below.
The renaming function seem quite bugged in this build when playing around with it too much, trying to use stuff like \, ..\, X:\ etc . And the WebGUI doesn't seem to work with the tricks below.

Would love to hear from anyone else who have played around with this!

Scenario 1:
Torrent contents:

mainfolder\test1.txt
mainfolder\test2.txt
mainfolder\test3.txt

Want to seed as:

mainfolder\folder1\test1.txt
mainfolder\folder2\test2.txt
mainfolder\folder3\test3.txt

Seem pretty straightforward. Just use the GUI to change filenames from test1.txt to folder1\test1.txt etc.
Might need to restart the client to get the folders to show up as folders and not as part of the filename.

Scenario 2:
Torrent contents:

mainfolder\folder1\test1.txt
mainfolder\folder2\test2.txt
mainfolder\folder3\test3.txt

Want to seed as:

mainfolder\test1.txt
mainfolder\test2.txt
mainfolder\test3.txt

Just renaming all the subfolders to \ in the GUI seems to work.
Might need to restart the client for the subfolder to actually disappear in the list.

Scenario 3:
Torrent contents:

mainfolder\test1.txt
mainfolder\test2.txt
mainfolder\test3.txt

Want to seed as:

X:\test1.txt
Y:\test2.txt
Z:\test3.txt

This one is trickier. But manually editing the fastresume file in %localappdata%\qBittorrent\BT_backup seems to work.
There might be easier ways, but I did it like this:
First renaming the files to test1b.txt etc in the GUI, just to get the "mapped_files" section added to the fastresume file.
Then closing the program and changing the paths of mapped_files to the absolute paths (X:\test1.txt etc) in a regular text editor.
The number after mapped_files is the length of the next string. ex mapped_filesl12:X:\test1.txt12:Y:\test2.txt12:Z:\test3.txt

[SinAddict]

Still very much need this. It's been 10 years and it's said the libtorrent API allows for it.

[saberblaze]

I have discovered a workaround to move files around and create/delete folders within a torrent, and it's by using qBitController for Android. When renaming files it shows the full path within the torrent, allowing you to create new folders and move the files around. It's cumbersome doing it on Android for multiple files and folders although connecting a mouse and keyboard to your Android device helps.

[luzpaz]

@saberblaze any idea where in the code it is ?

[Belove0]

@luzpaz If you're thinking of trying to implement relocating based on the renaming mechanism, my recollection is that that won't work (for instance, it would not allow for relocating outside of the torrent folder). There is discussion in the issue history. Libtorrent did implement a proper relocate feature since the time this issue was created though, so this could be worked on.

[someshittyeletronicmusicband]

At this point devs just don't want to implement this feature. This issue has been around for literally a decade, is one of the most commented issues on their tracker, was pinned for ages before they removed it, support upstream has been confirmed for ages as well, and so on. They simply don't care.

[glassez]

They simply don't care.

No, "they" just consider the idea of placing files of the same torrent outside from common directory to be "doubtful feature".

[4rev4]

No, "they" just consider the idea of placing files of the same torrent outside from common directory to be "doubtful feature".

The reason so many people want this is pretty simple, either:

1.) They're trying to put SomeVideo.mp4 into an organized directory for media sharing, but that torrent also contains SomeVideoSample.mp4 (or other unnecessary files) and they don't want SomeVideoSample.mp4 being recognized as the SomeVideo.mp4 itself, and thus breaking the media sharing program. The retort to this is always "make a copy" but space is limited and this ends up being "stop seeding and get rid of the junk files" which is bad for everyone torrenting.

or...

2.) They're being a good egg and trying to cross-seed the same files between trackers, but the directory structure is slightly different. Again the retort is always "make a copy"... but you know how that turns out.

We want to be able to seed the files and move them around for other purposes as well.

[someshittyeletronicmusicband]

They simply don't care.

No, "they" just consider the idea of placing files of the same torrent outside from common directory to be "doubtful feature".

Yeah, a "doubtful feature" every other torrent client has and is even implemented on the libtorrent API itself.

If they really don't want to implement it, they should come out and say "we don't want this shit on our project" and close the issue, as opposed to whatever they are doing currently. This is simply disrespectful, people have been asking for this feature for literally a decade, they promised it would be implemented once upstream support came, and when it came they did fuck all and actually removed it from the pinned issues.

I've had to use a separate client to cross-seed since I've migrated to qbittorrent a long time ago, just because this feature exists everywhere but here.

[stalkerok]

@glassez, what are the obvious disadvantages or pitfalls of this function? Is there really a meaningful argument to abandon it for good? If developers don't need it, you forget that there are hundreds of other people who will be very happy with it and will use it for a variety of purposes. Why not compromise and everyone would be satisfied?
There are huge torrent collections, even in my torrent library there are torrents weighing more than 2 TB, I could divide it all, sort it the way I need it, but I don't have the ability to do it using qBittorrent. I also know people who, due to the lack of this feature, still use such junk as uTorrent. This is one of the critical functions.
It is also worth noting that due to the lack of this function, users have come up with quite a lot of workarounds, which indicates the demand for this function. Here, for example, is another one https://github.com/xob0t/qBittorrent-File-Matcher

[floppyD]

I've been using filesystem links to work around the lack of this feature for a while now, which is quite sad since when I used uTorrent all I had to was simply right click - select path.

[glassez]

No, "they" just consider the idea of placing files of the same torrent outside from common directory to be "doubtful feature".

The reason so many people want this is pretty simple

I understand for what purposes it may be desired by users. By calling it "doubtful feature", I refer more to the problems of implementation and maintainance.
Currently all the qBittorrent logic proceeds from the assumption that all the torrent files are in the same folder. By implementing this feature, you can easily break some others along the way.
There is no professional (paid) team that would sit and work on this. This is a community project. Everyone makes their own contribution. But unfortunately, most prefer to invest only in the form of dissatisfied comments that some "gin from the bottle" does not fulfill their wishes of 10 years ago.
In addition to the fact that someone is asking for a feature, there must be someone who wants and can implement it in a suitable way. And many of the "requesters" of all kinds of features do not even bother to take any part in their development, at least in the form of testing. There are only a few more or less active testers here (great respect for them). But they also can't cover everything, especially those aspects that they don't personally use as users.

[AbsenceJam]

I had some strange behavior when moving a torrent to another drive and renaming at the same time and I ended up with one folder located elsewhere and outside the torrent folder. I removed it before I thought to experiment or screenshot but in the content tab the different drive letter appeared as a directory within the top level directory of the torrent but I can't remember how exactly it was named.

I only skimmed some of the earlier discussion but on Windows at least you can rename and relocate anything with the GUI so long as it's within a torrent's root.
For example rename file.ext to a\b\c\d\e\file.ext and in the filelist you'll see that path as the name, click away to another torrent and back and you'll have the correct tree view. Renaming a directory to "" (blank) or backslash moves its content up one level but not to the root ("folder already exists"). You can also move up individual files with ..\file.ext. And this works to get a file to the root.

With "..\file.ext" in the root you can also move a file one level outside a torrent's directory so long as you're not using "do not create folder." But I can't get it back in because a warning about absolute paths pops up.

For all I know there are other tricks too.

I wanted to know if any of this could be potentially abused. Can a file within a torrent be named in such a way that it ends up somewhere unexpected?

[saberblaze]

I tested using Web UI in docker, looks like it's very clunky but you can keep move a file upwards by writing "../filename" and creating folders with "new folder/filename", similar to the android app I had mentioned previously. It gets real messy and it's difficult to accurately move files around, not to mention very cumbersome to do so for every single file.

Also, it looks had someone had already made a pull request a couple of years ago that includes the relocation feature that we all want: #15903

It was requested of him that the relocate feature be made into a separate pull request, and his code needs to comply with qbittorrent guidelines/standards and maintainers 'requests. Understandably, life commitments have prevented him from continuing to work on it. If there is any hope of ever seeing this implemented, it would be for him to come back at some point to finish the code or for someone to take his code and finish what he started. In the latter case at least there is a foundation to start with.