Opened 12 years ago

Closed 8 years ago

#1496 closed Enhancement (fixed)

Support specification of download directory for individual torrent

Reported by: duncanbeevers Owned by: jordan
Priority: Normal Milestone: 2.80
Component: Web Client Version: 1.40
Severity: Normal Keywords:
Cc: ian@…, hibou@…, nodiscc@…

Description

Further out on the roadmap, user should be able to specify ultimate download destination for torrent's files. Since this is a web ui, interface must support some view over the daemon's local filesystem, local filesystem browser is unsatisfactory.

Attachments (5)

svn.diff (5.1 KB) - added by Grug 11 years ago.
Diff against SVN adding "enter location" dialog and sending "torrent-set-location" for the selected torrents
rpc.diff (694 bytes) - added by Grug 11 years ago.
Remove the erroneous? torrent-set command from the rpc protocol document
location.diff (5.2 KB) - added by Grug 11 years ago.
Updated diff against current SVN (replaces svn.diff)
Transmission-10529-web-browse-folder.diff (17.0 KB) - added by rampitec 10 years ago.
transmission-2.32-dirmod.diff (18.4 KB) - added by hamfratv 9 years ago.
patch that works for 2.32

Download all attachments as: .zip

Change History (28)

comment:1 Changed 12 years ago by turbo

With #920, it can always be moved later...

comment:2 Changed 12 years ago by charles

  • Summary changed from Web Interface should support specification of download directory for individual torrent to Support specification of download directory for individual torrent

comment:3 follow-up: Changed 11 years ago by charles

I don't think it's possible to open up a directory browser for the server machine -- even if we wanted to, which would probably raise security issues -- so do we let the user just type in the path by hand? That seems error-prone.

comment:4 Changed 11 years ago by faltrock

Maybe have some kind of basedir-restriction?

comment:5 in reply to: ↑ 3 Changed 11 years ago by Grug

  • Cc ian@… added

Replying to charles:

so do we let the user just type in the path by hand? That seems error-prone.

Related to #2044. That is exactly what you currently have to do with transmission-remote --find), which is exactly what I'm doing with all my torrents atm. Very tedious!

I don't think it's possible to open up a directory browser for the server machine

Not "natively". This would probably be in the form of a directory browser coded into the RPC (see comments here: #2044)

even if we wanted to, which would probably raise security issues

I personally would support an option to enable such a directory browser, with the comment that enabling it could be a security risk, etc... but given the need to add this to the RPC...

Replying to faltrock:

Maybe have some kind of basedir-restriction?

I'm not such a fan of a single basedir restriction as that wouldn't work for my use case. However, a list of directories would be workable. I think that could also cover #2484.

Changed 11 years ago by Grug

Diff against SVN adding "enter location" dialog and sending "torrent-set-location" for the selected torrents

comment:6 Changed 11 years ago by Grug

This diff , would have been ready in about an hour if the RPC spec was up-to-date... ;-)

I was initially looking at the "torrent-set" method trying to send "location" without any feedback. I eventually checked the remote's source and found the newer method... and scrolled down the rest of the spec page and there it is. Oops.

Maybe "location" should be removed from the "torrent-set" method to possibly save others confusion?

comment:7 Changed 11 years ago by livings124

Can you include a diff for the RPC specs as well?

Changed 11 years ago by Grug

Remove the erroneous? torrent-set command from the rpc protocol document

comment:8 Changed 11 years ago by Grug

Sure... there it is. It isn't much, simply removing the "location" line under "torrent-set".

I don't know that it is correct, simply that using that command didn't work (at least as I expect). My guess is that it is now out of date and its removal was overlooked.

Someone with more than 2 hours knowledge of the code should take a closer look. ;-)

comment:9 Changed 11 years ago by vovan888

I think this should be done as a set of categories, like it is done in Ktorrent.

Something like this in config file:

"categories": "default, music, video, software",
"download-dirs": "\/mnt\/downloads, \/mnt\/music, \/mnt\/video, \/mnt\/software",

RPC interface should provide a way to select a category while adding a torrent.

This way we do not need to open a file browser for server-side filesystem and still have ability to set location for downloaded files.

Thinking further it could be nice to guess the category while adding torrent - e.g. *.mp3 -> music, *.avi -> video, etc.

Changed 11 years ago by Grug

Updated diff against current SVN (replaces svn.diff)

comment:10 Changed 11 years ago by Grug

I personally don't like the idea of being restricted to categories as I have completed torrents spread out over more than 15 places on the filesystem, although the ability to select a category _or_ enter the exact directory would be useful.

Extending the RPC would be more of a longer term goal, but I consider this patch a worthy start simply as it brings the web client closer to that of transmission-remote (I don't know how the QT client handles this issue).

comment:11 Changed 10 years ago by theMan

Any update on this? I need such an download destination chooser.

Thanks.

Changed 10 years ago by rampitec

comment:12 Changed 10 years ago by rampitec

I've created diff for that (against svn revision 10530, as per `svn diff'), file Transmission-10529-web-browse-folder.diff attached.

To support the feature a new rpc call is exposed: 'folders-get'.

Input parameter: 'path', string, required (should be a full pathname).

Output:

'folders' -- array of strings (list of folders existing in path to which transmission user has access). 'pathDelim' -- string, server path delimiter (/ or \). 'folderName' -- string, cleaned version of input path. 'parentFolder' -- string, contains a pathname of folder's parent (if path is root parameter is absent on output).

The change has been tested on Linux and MacOS both as server and client, Firefox and Safari. I have no Windows, but rpc should work (except for manual selection of alternative drive letter).

comment:13 Changed 10 years ago by Gaahl

  • Version changed from 1.40 to 2.04+

Anything new regarding implementation of this feature? I, too, really need it. Also, native uTorrent is coming out which implements it in similar way to Ktorrent - preconfigured multiple download dirs.

comment:14 Changed 10 years ago by livings124

  • Version changed from 2.04+ to 1.40

comment:15 Changed 10 years ago by bobcote

Yep, something new ? I also don't like preconfigured categories. What I would like is something like a list of the last 5 folders you selected to download torrent inside. See this as quick often used shortcuts. If you want to download in another folder, then you still have a button to browse remote filesystem inside default download dir.

Changed 9 years ago by hamfratv

patch that works for 2.32

comment:16 Changed 9 years ago by jordan

The patch's coding is fine, but.. hm.

I'm torn on this feature. Having an RPC method that returns all the subdirectories of any given path on the server's filesystem... that seems pretty risky, privacy-wise.

Maybe we could use a predefined set of paths instead.

Does anyone else have an opinion on this?

comment:17 Changed 9 years ago by jordan

#4331 has been closed as a duplicate of this ticket.

comment:18 Changed 9 years ago by neufeind

For me a fixed list of download-locations wouldn't work out. And since I currently get upset because the webui doesn't allow me to specify a path, then login via console to check the path and fire a transmission-remote-request via CLI for it the filebrowser wouldn't show me things I'm not allowed to see anyhow :-)

Make this an option that can be turned on/off if you feel like it. Allowing to set the full path by hand might also good (many people know where their files are) and perhaps some base-directory (as already suggested) might be a good idea in terms of security.

Thinking of how virt-manager does that: They have "mountpoints" where you define one or more points in your filesystem to start browsing from, but allowing you to see everything below those directories. I think that might a possible solution here as well. So then we'd need a function to return the list of mountpoints and the already proposed browse-functionality which then takes a mountpoint as an argument and relative paths from there.

comment:19 Changed 8 years ago by hibou

  • Cc hibou@… added

comment:20 Changed 8 years ago by nodiscc

  • Cc nodiscc@… added
  • Version changed from 1.40 to 2.32

comment:21 Changed 8 years ago by livings124

  • Version changed from 2.32 to 1.40

comment:22 Changed 8 years ago by jordan

  • Milestone changed from None Set to 2.80
  • Owner changed from Gimp to jordan
  • Status changed from new to assigned

comment:23 Changed 8 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

Added in r14005

Note: See TracTickets for help on using tickets.