Custom directories

[michelsup]

Description

So once again, why wouldn't you let us set the Complete and Temp directories? Nearly everyone with a **arr stack would like to be able to change them to be able to use the hardlinking function.
Can you please elaborate please, as I really don't understand your "It would go against containers philosophy".

[panchuz]

In my case, after struggling with .rtorrent.rc, I managed to get where I want by mapping complete and temp instead of /downloads:

    volumes:
[...]
#      - "${PATH_TO_RTORRENT}:/downloads"
      - "${PATH_TO_RTORRENT}/.temp:/downloads/temp"
      - "${PATH_TO_RTORRENT}:/downloads/complete"
[...]

Not elegant in any possible way... but it gets me there.

Hope this helps

[RayBan91]

Hi, I'm interested this feature too. I don't want to auto-change my file location after download, I want them to leave all file in directory which I pointed out to them when adding torrent. I have differences paths mapped to my Plax Server with different categories of media.

[hitboxr]

@RayBan91 @panchuz That's not really relevant to this issue. That behavior is defined in /data/rtorrent/.rtorrent.rc:

docker-rtorrent-rutorrent/rootfs/tpls/.rtorrent.rc

Lines 57 to 60 in b4554e7

	# Move finished (no need Autotools/Automove plugin on ruTorrent)
	method.insert = d.get_finished_dir, simple, "cat=$cfg.download_complete=,$d.custom1="
	method.insert = d.move_to_complete, simple, "d.directory.set=$argument.1=; execute=mkdir,-p,$argument.1=; execute=mv,-u,$argument.0=,$argument.1=; d.save_full_session="
	method.set_key = event.download.finished,move_complete,"d.move_to_complete=$d.data_path=,$d.get_finished_dir="

To modify/remove this behavior you can simply edit/comment those lines, as per #44 (comment)

---

The real issue here is that /downloads is forced as a top level directory in this image. This is something that's been brought up many times here both as PRs (see #101, #119, #181, #386) and issues (#7, #44, #57, #105) but @crazy-max has been pretty adamant in saying that he won't allow custom path support. That most recent PR probably has the best chance of getting accepted (since it keeps the current behavior by default and allows optional configuration of paths w/ environment variables), but it's been up for review since July of last year and there hasn't been a peep from @crazy-max.

With regards to hardlinking, there is a workaround to enable hardlinking for *arrs while using this image as a download client that hasn't gotten much mention in discussions here. You can set a remote path mapping to map /downloads to wherever your *arr stack is expecting torrents to be. For example, if you're following TRaSH Guides directory structure of /data/torrents, you can set a remote path mapping of /downloads (remote) -> /data/torrents (local). This will translate the paths from rtorrent to match the true directory structure that your *arrs are using, and will allow them to properly hardlink files to your /data/media directories or wherever your root *arr directories are, since you don't have to use a separate bind mount to expose a fake /downloads directory to the *arr containers to allow them to find files from rtorrent.

That being said, it makes no sense to me to repeatedly refuse to implement this requested functionality, at least as an optional feature, simply because it "goes against Docker philosophy". God forbid someone suggest that Docker philosophy doesn't actually cover every possible use case and scenario. The path mapping workaround is flawed in ways that could easily be solved by this image allowing custom download directory paths.

[drrako]

I completely agree with @hitboxr — the enforced /downloads directory was one of the main reasons I decided to go my own fork.

Considering the diverse world of use cases for rTorrent, it makes much more sense for the r(u)Torrent image to be a simple, portable all-in-one app — offering the same level of configuration flexibility as a native rTorrent+ruTorrent setup, without imposing a rigid download folder structure.