Transmission download location gets the last subfolder removed on new torrents

Bug #505861 reported by shankao on 2010-01-11
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Fix Released
transmission (Ubuntu)

Bug Description

Binary package hint: transmission

I have set the default folder for torrents in the "preferences > torrents" menu.
When I add new torrents, that would be offered as the default download location for the torrent but my $HOME directory appears instead.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: 56f6196d6c59b6b05a94181cc3955a09
CheckboxSystem: c4d84cd56dc0e1c868ed7fe87c94fd31
Date: Mon Jan 11 12:51:33 2010
DistroRelease: Ubuntu 10.04
Package: transmission (not installed)
ProcVersionSignature: Ubuntu 2.6.32-9.13-generic
SourcePackage: transmission
Tags: lucid
Uname: Linux 2.6.32-9-generic i686

Charles Kerr (charlesk) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

  * I'm not able to reproduce this error -- what specific steps should I take to recreate this bug?

  * Does the folder you chose in preferences > torrents exist? Do you have read/write access to it?

  * If you change the folder in preferences > torrents, then close the preferences dialog, then reopen it, does the preferences dialog show the correct folder, or $HOME (or something else?)

Changed in transmission (Ubuntu):
status: New → Incomplete
shankao (shankao) wrote :

Answered question by question.

* Steps to reproduce the bug:
1. Set any folder in the preferences->torrents dialog. In my case, the "Donwload" folder under $HOME that AFAIK, was introduced since karmic.
2. Open a .torrent file from nautilus.
3. In the new window that opens (Torrent options), the selected destination folder is always my $HOME folder.

* Yes, the folder exists and I have the correct access privs. I have checked with two different ones ("Download" and "Pictures", automaticaly generated for new users) and still shows the same behaviour.

* Tested, still same thing :-(

Changed in transmission (Ubuntu):
status: Incomplete → New
Philipp Meier (meier-philipp) wrote :

Unfortunately I could not reproduce it. Have you installed lucid newly or upgraded from kramic?
Because I have just tested on a completely fresh install.

Changed in transmission (Ubuntu):
status: New → Incomplete
Philipp Meier (meier-philipp) wrote :

Tested on my upgraded machine as well. Could not reproduce with the torrent file for xubuntu. Could you please test it with that file?

shankao (shankao) wrote :

Same thing with the file you have included. I am using an upgraded lucid from karmic. I think this is the corresponding configuration line in the file .config/transmission/settings.json:

"download-dir": "\/home\/shankao\/Download"

Charles Kerr (charlesk) wrote :

I still can't reproduce this, so I'm going to try two wild guesses to see if they help any:

1. If settings.json is somehow corrupt, Transmission may be using your home directory as a fallback value. Could you please run your ~/.config/transmission/settings.json file through a JSON parser (such as to check for parse errors?

2. It's possible that there's some kind of bug and/or installation error in your copy of GTK+. What version of GTK+ are you using? Is it the standard version for 10.04?

3. This requires a little bit of work, but it will help to eliminate GTK+ and upgrade errors from the list of suspects -- copy your ~/.config/transmission directory to a flash drive, then boot a live CD of the Lucid prerelease. Launch its copy of Transmission from a terminal with "transmission -g /media/your-flash-drive/transmission-config-dir --paused" ... this way you can test your settings on a "clean" install of Lucid.

Charles Kerr (charlesk) wrote :

It's possible that this ticket and bug 500011 are related. shankao, could you please take a look at and answer those questions? Those are all pretty straightforward, and less effort than downloading a live cd... :)

shankao (shankao) wrote :

@charles: I have tested your theory in bug 500011 and seems to be correct. If I change the download location, it always gets the last subfolder removed. If this is a transmission or gtk+ problem, I don't know...

summary: - Transmission does not respect the default download location setting
+ Transmission download location gets the last subfolder removed on new
+ torrents
shankao (shankao) wrote :

My settings.json parses without problems (tested with the online parser @charles indicated).
How can I know my current GTK+ version or which package should I check?

Changed in transmission (Ubuntu):
status: Incomplete → New
Charles Kerr (charlesk) wrote :

shankao: unfortunately I don't know how to answer that; I don't use Ubuntu.

If you have the gtk dev package installed, you can get it by running "pkg-config --modversion gtk+-2.0" in a terminal. If you don't have the dev package installed, that command will probably return "No package found" instead....

Since I'm not able to trigger this bug in either gtk+ 2.10.4 or 2.18.6, I suspect it's a new bug in the version of GTK+ in Lucid...

Charles Kerr (charlesk) wrote :

According to, the current version number in Lucid is 2.19.3

shankao (shankao) wrote :

Same version that I have (and yes, I use the official one included on lucid):

$ pkg-config --modversion gtk+-2.0

shankao (shankao) wrote :

I have came as far as completely removing transmission (sudo apt-get purge transmission-common transmission-gtk) and the .config subdirectory (rm -rf ~/.config/transmission) and reinstalling again.

No change, so I suppose it's not a transmission fault.

As a side note, shouldn't the purge command also remove the ~/.config/transmission subdir?

shankao (shankao) wrote :

Would be good to find the correct package for this but I'm going to assign it to GTK+2.0 after charles comments.

affects: transmission (Ubuntu) → gtk+2.0 (Ubuntu)
Sebastien Bacher (seb128) wrote :

the issue is an application one, gtk opens the default location when used if not specified otherwise, transmission could specify an another directory to use if that makes sense

affects: gtk+2.0 (Ubuntu) → transmission (Ubuntu)
Guy Stacey (gystcy) wrote :

Can confirm this behaviour on my karmic> lucid alpha2 upgrade, and just closed my duplicate post. Folder permissions are fine. Workaround and evidenced by adding dummy subfolder at the required download location.

Krzysztof Klimonda (kklimonda) wrote :

I can't reproduce it on the up-to-date Lucid anymore - I was able to when the bug was reported but now everything works as expected. Please, make sure that your system is up to date and test in the guest session - if the problem persist please make a video that captures the problem.

Changed in transmission (Ubuntu):
status: New → Incomplete

I can confirm the bug with my regular user on lucid upgraded from karmic, but when making a new test user the bug is no longer present.
Removing the ~/.config/transmission folder does not help, so the problem is probably related to gconf/gtk

Hew (hew) wrote :

I can verify this bug still exists on up-to-date Lucid with Transmission 1.91, see duplicate bug 529036.

Changed in transmission (Ubuntu):
importance: Undecided → Low
status: Incomplete → Confirmed
Charles Kerr (charlesk) wrote :

Hew: bug 529036 has (I think) the same root cause as this ticket, but it has the advantage of being a little more self-contained than the examples here -- transmission-1.9x/gtk/relocate.c has a static string, "previousLocation", where we hold the default destination inbetween the times that the "Set Location" is popped up.

ISTR you're comfortable building from source. Could you add a couple of g_message statements to relocate.c to find out what the value of previousLocation is right before we pass it to gtk_file_chooser_set_filename() and right after we pull it from gtk_file_chooser_get_filename()? Also could you report how those g_message() values compare to what you see in the GUI?

Since only Lucid users are experiencing this bug, I wonder if it's not a regression in gtk_file_chooser_set_filename() that drops the last subfolder from the path if there's a '/' missing from the end, or a regression in gtk_file_chooser_get_filename() that omits the trailing '/'... these are just guesses.

Changed in transmission:
status: Unknown → Fix Released
Charles Kerr (charlesk) on 2010-03-11
Changed in transmission (Ubuntu):
status: Confirmed → In Progress
importance: Low → Medium
Charles Kerr (charlesk) wrote :

This is fixed for 1.92. Thanks to kklimonda for suggesting The Fix. :)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package transmission - 1.92-0ubuntu1

transmission (1.92-0ubuntu1) lucid; urgency=low

  [ Krzysztof Klimonda ]
  * New upstream release (LP: #538034), rebased on debian testing.
    Remaining changes:
    - debian/control:
      + Added replaces & provides clutch (now included as part of transmission).
        Can be removed in lucid+1
      + Added liblaunchpad-integration-dev and lsb-release to Build-Depends
    - debian/rules:
      + create a po template during package build.
    - debian/patches/01_lpi.patch:
      + integrate transmission with launchpad
    - debian/patches/20_add_x-ubuntu-gettext-domain.diff:
      + add x-ubuntu-gettext-domain to .desktop file.
    - debian/transmission-daemon.default:
      - remove --auth from OPTIONS
    - debian/control, debian/rules:
      + build transmission gtk+ client with both gconf and libcanberra support.
    - debian/patches/dont_build_libevent.patch:
      + disable libevent in and because we use autotools
        to regenerate build files.
    - lucid/debian/patches/updateminiupnpcstrings_double_escape_slash.patch:
      + Deleted as the bug is fixed upstream
  * Fixes bugs:
    - Fix directory selection error in GTK+ 2.19 (LP: #518692)
    - Transmission "Set Location" - dialog doesn't disappear (LP: #529037)
    - The "Torrent Options" dialog's Torrent Priority row gets too much
      vertical stretch (LP: #527299)
    - "Open Folder" behavior can be confusing for single-file torrents
      (LP: #505861)
  * Refreshed 99_autoreconf.patch

  [ Chris Coulson ]
  * debian/patches/disable_web_ui.patch:
    - Disable the web UI by default again (LP: #542194)
 -- Krzysztof Klimonda <email address hidden> Wed, 03 Mar 2010 02:55:26 +0100

Changed in transmission (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.