No longer able to set a destination using relative paths

[karmix]

What is the issue?

I have drives on which I store the content for many torrents, as well as all of the associated transmission config and state files. On those drives, I also have scripts for starting up transmission-daemon and others for analyzing and managing the torrents (via transmission-remote) and other content on the disks. Everything worked well until several years ago when transmission-remote started to fail with the message 'Error: download directory path is not absolute' whenever my scripts tried to add a new torrent.

The problem I run into is that you cannot use absolute paths for anything in this environment when external drives mount at different points on different machines and operating systems and may even include components of a logged in account's name. Once you detach the drive from one system and attach it to another, transmission-daemon will look for data files for each torrent that was added using an absolute download path under a mount point that does not exist.

For several years I have been able to restore previous functionality by stopping transmission and editing destination in the resume file. However, modifying state files is a brittle workaround and I expect it will eventually break. I understand that this regression was an intentional, but as I have projects that relied on the prior functionality, I would really like to see the ability to pass a download directory relative to the working directory for transmission-daemon restored in some form.

Which application of Transmission?

None

Which version of Transmission?

4.0.5

[tearfur]

Sounds like you are interacting with a Transmission instance on the local machine, and you've said that the paths are relative to the working directory. Can't you just construct the absolute path in your scripts?

[karmix]

That is correct. My scripts and transmission-remote run on the same machine as transmission-daemon and know exactly where everything is located. My scripts now have to do exactly what you described and use an absolute path for the download directory just so transmission-remote will register the torrent with transmission-daemon.

The problem is that transmission-daemon stores that absolute path in the resume file for the torrent, so the next time I attach the disk and the O/S gives it a different mount-point, starting transmission-daemon will read the absolute path containing the old (hopefully invalid) mount point, look for the download directory in the wrong place, then try to download everything all over again (with various results, none of which are good). This wasn't an issue until transmission-remote stopped accepting relative paths.