Project

General

Profile

Bug #479

Transmission Reset's Path after Update

Added by devnet over 11 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Apps
Target version:
-
Start date:
03/19/2010
Due date:
% Done:

0%


Description

I have changed the path in the web interface of transmission so that my downloaded files go to one of my larger drives. After an update however, this path is reset to the default one which, for me, goes to a smaller 120GB drive. Now, this isn't a big deal for me...but if I were running with a smaller SSD or a smaller hard disk, it might fill things up quickly when downloading many things. This would then cause the partition table to become unstable and possibly cause major problems with the OS.

The worst part is, you don't know when an update has occurred...so you just have to be vigilant and check the preferences each time you look at the web interface.

I think this behavior should change. Most configuration files for rpm installation are written as .conf.rpmnew or similar. I think this should also be the case.

History

#1 Updated by devnet over 11 years ago

I have discovered that the path is reset EVERY time the application has no torrent to track. So if I empty out all the torrents I have and it is blank...the next time I open the application up it has reset the path again.

#2 Updated by gboudreau over 11 years ago

Please confirm how I can reproduce.
1. change download-dir using the web ui, to something else than /var/hda/files/torrents
2. and then remove any torrent
3. Reload the web UI (CTRL-R)
4. check that the download-dir is back to the default /var/hda/files/torrents
?

#3 Updated by gboudreau over 11 years ago

Ah, not needed really. The download-dir is hard-coded in the initd script.

ps aux | grep transmission | grep -v grep

would show you that transmission-daemon is running using it's -w parameter set to /var/hda/files/torrents

We could change the initd script to remove that hard-coded path I'd bet.
Before we release that fix, please test it manually:

Edit /etc/init.d/amahi-transmission
change:
daemon --user transmission $TRANSMISSION_BIN -w $TRANSMISSION_DIR
to
daemon --user transmission $TRANSMISSION_BIN

Then:
service amahi-transmission restart

Then change your download-dir again, and add/remove torrents, and restart the service once more and verify the download-dir is still intact.

#4 Updated by cpg over 11 years ago

  • Status changed from New to Feedback

I changed the path in the web interface, then tried to restart the service (which kept the new path across restarts - however, I got a very strange error!):

[17:22:21](1)milan:~# service amahi-transmission stop
Shutting down Transmission daemon:                         [  OK  ]
[17:22:32](1)milan:~# service amahi-transmission start

gzip: level1.gz: invalid compressed data--format violated
chown: cannot access `level1': No such file or directory
Starting Transmission daemon...                            [  OK  ]
[17:22:43](1)milan:~# ps aux | grep transmission | grep -v grep
cpg       5564  2.6  0.3 955900 29508 ?        Sl   Apr18 150:43 transmission
483      14492  1.6  0.0 317564  2924 ?        Ssl  17:22   0:00 /usr/bin/transmission-daemon
483      14533  8.0  0.0 239356  2048 ?        SNsl 17:22   0:00 /usr/bin/transmission-daemon
[17:23:01](1)milan:~# 

#5 Updated by devnet over 11 years ago

If you set the path inside the GUI application on the desktop and then restart the service, does that matter? If this is as easy as setting it up first with the GUI then...well, I guess it's whatever you're after. If you're after the seamless integration through web interface, then GUI setting won't matter :/

#6 Updated by bigfoot65 over 7 years ago

  • Status changed from Feedback to Closed

No longer valid.

Also available in: Atom