Opened 14 years ago

Closed 14 years ago

#1647 closed Enhancement (duplicate)

[PATCH] Add a new rpc message set-download-dir

Reported by: tiennou Owned by: charles
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.42
Severity: Normal Keywords: patch
Cc:

Description

I'm trying to write a plist file for launch to manage the daemon transparently. And I can't seem to get it to use the directory I want. Attached is my launchd.plist file.

I'm running it with "./transmission-daemon --foreground --download-dir /Volumes/myHD/daemon", but whatever I set it to is ignored, and ends up in ~/Downloads.

Attachments (2)

com.transmissionbt.daemon.plist (1.1 KB) - added by tiennou 14 years ago.
Updated version with more tweaks
torrent-set-download-dir.diff (3.0 KB) - added by tiennou 14 years ago.
Patch v1

Download all attachments as: .zip

Change History (15)

comment:1 Changed 14 years ago by tiennou

Sorry, it works, but there's no way to easily batch-change the download dir, since it's overridden by the resume file.

comment:2 Changed 14 years ago by charles

05:08 <@charles_> tiennou: regarding #1647, are you using trunk or 1.42?
05:09 < tiennou> trunk, but it was my fault, and although behavior is wierd, it works
05:10 < tiennou> (I expected --download-dir to override resume file info)
05:10 <@charles_> it does
05:10 <@charles_> [charles@charles daemon]$ grep download-dir /home/charles/.config/transmission-daemon/settings.json  
                  "download-dir": "\/home\/charles\/Downloads", 
05:10 <@charles_> [charles@charles daemon]$ ./transmission-daemon -w /tmp/test/bargle -d 2>&1  | grep download-dir "download-dir": 
                  "\/tmp\/test\/bargle", 
05:11 < tiennou> that's what pointed me to the problem ;-)
05:11 < tiennou> but it doesn't override those under resume/
05:11 < tiennou> (the destination benc string)
05:13 <@charles_> I don't understand that.  Wouldn't that involve moving all the local data that had already been downloaded for 
                  those torrents?
05:13 < tiennou> yes, but it's what I did
05:13 <@charles_> setting download-dir only affects torrents added *after* download-dir has been set
05:13 < tiennou> (this is after the wierd crash which caused Torrents.plist to be deleted)
05:13 <@charles_> so what you're asking for is a "move local data" feature for the daemon, is that correct?
05:14 < tiennou> something like that
05:14 <@charles_> okay.  I didn't understand that from the ticket.
05:14 < tiennou> I was just expecting --dl-dir was overriding stuff, and I was wrong ;-)
05:15 <@charles_> it does override the settings.json
05:15 <@charles_> "
05:15 <@charles_> I'm running it with "./transmission-daemon --foreground --download-dir /Volumes/myHD/daemon", but whatever I set 
                  it to is ignored, and ends up in ~/Downloads." <-- makes it sound like -w is totally being ignored :)
05:16 < tiennou> yes, that's what I thought at first
05:16 < tiennou> but adding some well placed tr_nerr calls told me I was wrong ;-)
05:17 <@charles_> so that's what the second comment means there... ok

Changed 14 years ago by tiennou

Updated version with more tweaks

comment:3 Changed 14 years ago by charles

tiennou: what am I supposed to do with this plist? :)

At this point, I don't really understand what this ticket is for. I understand wanting the ability to tell Transmission where a torrent has moved to, but I don't see where the plist fits into that.

comment:4 Changed 14 years ago by tiennou

This plist is for Waldorf. I guess he wanted one for the script section in the Wiki.

I guess you can rename this ticket "Add a new rpc message set-download-dir" which allows to update a torrent's destination. Using "./remote -t all --set-download-dir dir" can handle the batch update I wanted to do earlier.

comment:5 Changed 14 years ago by livings124

Add a new rpc message set-download-dir

comment:6 Changed 14 years ago by livings124

  • Summary changed from daemon doesn't respect --download-dir on Mac OS X to Add a new rpc message set-download-dir

comment:7 Changed 14 years ago by tiennou

After taking a quick look at it, I guess it could be done by supporting the -t flag for --download-dir. I guess it could work like this : 1) If -t isn't present, change the default download dir (the session one), which will be used for transfers added thereafter. 2) If -t is present, change the download dir in the resume file.

I'm not sure how to correctly handle 2), because IIRC libT doesn't provide a nice "move the data file" command (you can only do it manually, by stopping the torrent, moving it in the place you want, update the resume file, and force-verify it to check it worked). I guess a lazy way to do it would be to let the user manage the actual move, and only stop the torrent, update the resume file, then restart the torrent.

Opinions ? I'm trying to understand how it works now, and (maybe) will provide a patch, handling the "lazy" way.

comment:8 Changed 14 years ago by charles

  • Type changed from Bug to Enhancement

Changed 14 years ago by tiennou

Patch v1

comment:9 Changed 14 years ago by tiennou

  • Keywords patch added
  • Summary changed from Add a new rpc message set-download-dir to [PATCH] Add a new rpc message set-download-dir

Named it torrent-download-dir. It seems I can't easily extend the semantics of the -w flag (--download-dir), so I added it as -W. Comments are welcome ;-).

comment:10 Changed 14 years ago by charles

I think the patch included in comment 9 is not a good idea.

In fact, I don't think tr_torrentSetDownloadDir() is a very good idea at all. It doesn't make sense to be able to set it at any arbitrary time; it should be set via the torrent ctor at creation time, or in tr_torrentMoveLocalData() as per ticket #920

comment:11 Changed 14 years ago by tiennou

Agreed, this is a little clunky. I'll try to make a patch for #920, and use it for this one then.

comment:12 Changed 14 years ago by turbo

#1483 is also slightly related...

comment:13 Changed 14 years ago by charles

  • Resolution set to duplicate
  • Status changed from new to closed

Maybe I'm being thick about this, this ticket still seems to be just #920 phrased differently.

Closing as a duplicate of #920, but feel free to reopen if I'm wrong... ;)

Note: See TracTickets for help on using tickets.