[request]Allow relocating of files out of tree

[GoogleCodeExporter]

This is feature request from the qbittorrent bug tracker: 
https://github.com/qbittorrent/qBittorrent/issues/439

This is a feature supported by utorrent. Enable the user to relocate/move a 
file somewhere in the filesystem, but still consider it part of the torrent, 
while the other files of the torrent stay at the default location(or move them 
to other locations too).

For example: One torrent with files a,b,c organized in this file tree
->a
->myfoldername\b
->myfoldername\c

You add the torrent and choose as save path c:\, so normally the file tree will 
be:
->C:\torrentname\a
->C:\torrentname\myfoldername\b
->C:\torrentname\myfoldername\c

The user should be able to change the actual file tree without modifying the 
torrent itself into something like this:
->C:\torrentname\a
->C:\long\path\into\the\drive\b
->H:\c

This is partially supported by rename_file(), but it is undocumented behavior 
and also has some shortcomings(see linked bug).

Original issue reported on code.google.com by hammered...@gmail.com on 5 May 2013 at 9:28

[GoogleCodeExporter]

Do you have a proposed API for this?

making rename_file() accept absolute paths feels scary, since relative and 
absolute paths are fundamentally different, and I would expect rename_file() 
(given its name) primarily is used to rename files within the torrent's 
directory.

How about adding a new function called move_file() which always takes an 
absolute path?

Original comment by arvid.no...@gmail.com on 10 May 2013 at 2:54

[GoogleCodeExporter]

>making rename_file() accept absolute paths feels scary, since relative and 
absolute paths are fundamentally different, and I would expect rename_file() 
(given its name) primarily is used to rename files within the torrent's 
directory.

Yup, I initially thought that rename_file() did only renaming. Let's keep the 
current behavior, and let the move be more explicit.

>How about adding a new function called move_file() which always takes an 
absolute path?

This sounds ideal. My concern is how to retrieve the current absolute path? 
file_entry::path should contain the absolute path, right? (never tested it 
myself)

From the linked qbt bug I have come up with an idea on how to achieve this with 
only rename_file(), but I haven't tried it yet. An explicit method would be 
much appreciated. This is what I thought:

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.

Any thoughts on this?

Original comment by hammered...@gmail.com on 10 May 2013 at 9:53

[GoogleCodeExporter]

> 2. Construct relevant path from source to destination path
I'm not familiar with what would or wouldn't work, but a general thought for 
the Windows implementation:
This might not work in Windows due to the fact that seperate drives and 
partitions ordinarily use different drive letters, and have no relative path 
between them.  The Unicode file APIs accept "\\?\"-style paths that can include 
drive letters, and if libtorrent is using those types of paths and libtorrent 
api interface allows it, it might work.  But regardless of the Windows API 
being used or how it's used and exposed by libtorrent, I also like the idea of 
an explicit libtorrent api function like move_file().  It would be more 
transparent.

Actually, even renaming rename_file() to move_file() and implementing and 
documenting the combined functionality would be more transparent than 
implementing it under rename_file(), with the long tradition of mv/move OS 
functions implementing that exact combination of behaviors.

Original comment by a...@lovetour.info on 11 May 2013 at 2:20

[GoogleCodeExporter]

>This might not work in Windows due to the fact that seperate drives and 
partitions ordinarily use different drive letters, and have no relative path 
between them.

I didn't take that into consideration, and without testing this, I think you 
are right.

Original comment by hammered...@gmail.com on 11 May 2013 at 3:25

[GoogleCodeExporter]

One way relative paths traversing drives do work in Windows:

If libtorrent is compiled to run under a posix layer/emulation, come to think 
of it, then relative paths will work on Windows as well. For what it's worth. 
For example, such full paths could look like "/dev/fs/C/Windows/notepad.exe" or 
"/dev/fs/D/Downloads/Funny Stuff on my D drive/laughter.ogg".  In some quick 
testing just now, I see that relative paths using ../ work fine in this context 
to access different drive letters.  If drives are additionally or instead 
mounted onto the file system *nix-style (which Windows supports but is little 
used), then relative paths will work in any case.  But if no emulation layer is 
used in compiling the Windows binary, then I would expect that to be better for 
performance.

Original comment by a...@lovetour.info on 5 Jun 2013 at 3:53

[GoogleCodeExporter]

I just checked in a patch to trunk which makes rename_file() support absolute 
paths. Please check it out!

Original comment by arvid.no...@gmail.com on 9 Jun 2013 at 10:31

[GoogleCodeExporter]

if this patch does not provide the functionality you would expect (in trunk), 
please re-open this ticket.

Original comment by arvid.no...@gmail.com on 13 Jun 2013 at 7:17

• Changed state: Fixed

[GoogleCodeExporter]

Sorry arvid for the delay. I am really busy in real life and cannot test it 
soon. It looks good. If any problems arise I will report it here.

Just one thought: Is there any way to query the current path of individual 
files in a torrent? If not, I think this should be implemented too. If yes, 
will it return the absolute paths too?

Original comment by hammered...@gmail.com on 13 Jun 2013 at 7:35