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 :dancer: :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.

[dvanmat]

I want this feature so bad. It's the only thing keeping me from dumping utorrent.

[Lightborne]

Hi, I was wondering if this feature was any closer to being implemented.

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

[dvanmat]

Would be nice to see some progress on this.

[dvanmat]

Starting to think this will never happen.

[cojj90]

Could this be looked at? I've moved to qbittorrent recently and every key feature I need is here except for this one

[orkoapprentice]

This seems like an essential feature, and I'm very surprised it has not been implemented.

[zeule]

File system hadlinks do the trick. You can copy downloaded files to any location you want, and run a tool which detect file duplicates and replaces them with hardlinks. I don't think it makes sense to pollute qBt with such functionality, but it is easy to implement without any support from libtorrent.

[maya923]

Although I am over this request and qBitTorrent, as I have moved to rtorrent using ruTorrent for a UI, I still agree it is the only necessary feature missing from the client. However, @evsh, what you're suggesting has absolutely nothing to do with the actual request of a relocate feature.

[zeule]

@maya923 the only difference between the "relocate" feature and the hardlinks is that the file system keeps an entry for the file in the original download dir. Do I miss something or this file system entry makes a problem?

[maya923]

@evsh Wouldn't that be more than necessary? All the relocate feature is a move. I'm not looking to keep two copies of every torrent on the same HDD, let alone the same computer. If µTorrent has had this implemented for so long, I really have no idea why qBitTorrent hasn't done the same. For those who continue to use qBitTorrent, I hope one day, hopefully soon, it gets implemented for them.

[zeule]

@maya923 if one wants to download a file using network node A and them move the file to node B, why keep it in the qBt? It is not a file manager. If one wants to relocate files to another file system (another HDD or partition), then again, what's the purpose of this action? One can either download to the target file system, or move it there (into a hidden directory, for instance) and hardlink wherever it's needed.

[Belove0]

but it is easy to implement without any support from libtorrent.

@evsh, libtorrent added the support for this long ago.

[dvanmat]

Would be nice if this happened. A client that can't cross seed properly isn't really very useful.

EDIT (FranciscoPombal): qBittorrent can still cross-seed just fine by leveraging symlinks and/or hardlinks.

[insurw]

edit: Now I see the renaming was mentioned at the start already.

I've been migrating to qbittorent from utorrent. The only time you'll have to use hard links is if you download a torrent and want to spread the files in different folders/HDDs instead of the original one folder for a trilogy. If you want fix incorrect episode naming you can name the files correctly but keep the folders names or rename it "Mixed S1-S2". Scrapers only look at the parent folder name (The Simpsons) and filenames.

If you want to rename the files and keep seeding you can do it with qbittorent. You either do it when you add/readd the torrent (double click) or you rename the folder/files in the content tab (right click).

[breadbread]

Just wondering if this feature is still being looked at to be implemented, especially if its easy to do?

hardlink wherever it's needed.

It would be nice to have this feature despite using hardlinks. The reason for this is there are software that do no support hardlinks (eg. DrivePool, which only supports symlinks, and is used to pool several drives together).

[jathek]

This is tagged as waiting API implementation, but according to this issue libtorrent implemented the required functionality in 2013. Any movement on this?

[so-lost]

Still waiting for an implementation of this

[Tvtossen]

Pretty please with sugar on top

[floppyD]

That's the only reason I haven't moved from uTorrent yet, please consider implementing this feature.

[rekcus2]

And after the torrent seeds, I end up wanting to take the files out and rename the root folder

Ok then do it, take them out, copy them out, do with then what your heart desires!

I do not get this. Why do you need this? Just keep the torrents seeding and move copy and reorganize your files elsewhere. Disk space is incredible cheap and music does not take a lot of space. Use https://picard.musicbrainz.org/ to reorganize. I think it even has a setting to copy instead of move. IMO things like this should NOT be priority on any torrent client with, especially with 2600+ issues open.

@sledgehammer999 said in 2013

cumbersome to work with.

In relation to something I have no clue about. I have some clue about programming (just web stuff) and can only imagine that features like this make the entire code-base way more complicated and potentially break others things.

[jathek]

And after the torrent seeds, I end up wanting to take the files out and rename the root folder

Ok then do it, take them out, copy them out, do with then what your heart desires!

I do not get this. Why do you need this? Just keep the torrents seeding and move copy and reorganize your files elsewhere. Disk space is incredible cheap and music does not take a lot of space. Use picard.musicbrainz.org to reorganize. I think it even has a setting to copy instead of move. IMO things like this should NOT be priority on any torrent client with, especially with 2600+ issues open.

This is not a good or efficient solution and I don't know why you're proposing it to the OP. Your solution would be to duplicate every file that a person wants to move around.

As stated above, an issue for this was fixed on libtorrent's old issue tracker in 2013. People just want qBittorrent to add support and bring closer parity to uTorrent.

This feature is very helpful for keeping torrents alive while still allowing people to organize their files exactly the way they want to.

[rekcus2]

Damn it Picard actually has no option to copy files but found it was in the works but never made it. https://github.com/metabrainz/picard/pull/44 and https://github.com/metabrainz/picard/pull/350 and https://tickets.metabrainz.org/browse/PICARD-183. With someone actually making a good PR it would be a feature for sure.

If you move and/or rename them Bittorrent loses track obviously. Sadly that makes my point not as good but you still can just copy them out manually and then use Picard on your copied files, just one more step. I bet people do not evne know about it. Any stupid half as crap solution build into a software that is made for a entire different purpose makes not much sense. Since 2013 this got just a few comments and only 10 thumbs up. 2600++ issues scream "Do not open this book of worms!". Nested categories is more then enough you have for basic sorting. A BitTorrent client should have no need for keeping track of renamed files but it seems it already can do that crazy thing! So what is the actual issue here? You can move into a new "nested category" that is essentially just another folder. You can name it "Artist - Whatever/2000 - Whatever/" you can do that and then you can even rename files, everything from within this crazy bit-torrent client while it keeps seeding them. And you want more? Seriously?

I use Sonarr for series and that does just copy the files out into their right directories while they are kept seeding. Nothing that nested categories cant handle, its just automated and does a little more then that.

I do think people who claim features like this are essential are stupid. I am off renaming, sorting the new Tool and tagging it correctly - bye.

[Aurareus]

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.

This was posted in June 2013. It's nearly 2020 now and this hasn't been done. I have been watching this thread since it was opened but figured there wasn't really any reason to comment, and I don't like to sound entitled when it comes to free software. But at this point I'm just very confused as to why this is still not implemented, I have been waiting to switch from uTorrent for the better part of a decade because as someone who wants to cross-seed, organise and actually use my files this feature is pretty mandatory. Ancient versions of uTorrent have this feature. It is known and has been since 2013 that it's possible to implement this. It's obviously not an issue of visibility or priority seeing as out of over 2700 open issues this is one of only 3 pinned issue. It's also incorrectly labelled "Waiting API implementation", so can that at least be removed?

[ghost]

There is a simple solution. Make reflink copies ( Btrfs, ZFS) or hardlinks (NTFS, ext4, XFS..). You can then rename or move the cloned files however you want without having duplicate space usage.

Of course this doesn't work across filesystem boundaries. Perhaps soft links works, but I have not tested this.

Linux with Btrfs/ZFS:

cp -a --reflink=always src target

Linux with hardlinks:

ln -p link target

http://man7.org/linux/man-pages/man1/ln.1.html

Windows:

MKLINK [[/D] | [/H] | [/J]] Link Target

        /D      Creates a directory symbolic link.  Default is a file
                symbolic link.
        /H      Creates a hard link instead of a symbolic link.
        /J      Creates a Directory Junction.
        Link    Specifies the new symbolic link name.
        Target  Specifies the path (relative or absolute) that the new link
                refers to.

[jathek]

That's not even remotely a simple solution. Torrents can have dozens of files. Creating a manual hard link for each one is ridiculous. It also creates a huge amount of clutter on your disk, as you would have two system files for every torrent file.

[ghost]

Directory junctions would be enough. If you didn't want rename the files.

But as it seems there are bugs and other issues needing more developer time I thought these were good options.

Personslly I use cp -a --relink=always which makes a CoW clone at no extra cost. All Torrents stay in my torrent folder and copies are moved to other places. Very efficient. Even works over samba shares with the vfs_btrfs plugin.

[PebbleThrower]

Was waiting on this request for far too long. Moved on to Tixati, ability to move individual files easily and renaming individual files as well.