directory change not saved

[Nicolas da Luz Duque]

Binary package hint: rtorrent

When you change the directory of a download, and then rtorrent is stopped (for any reason), at restart it tries to find the files in the default directory. When you try to tell it to look for the files in their proper place, it won't restart the download.

Steps to reproduce:
1. Start a download
2. Stop it immediately (with Ctrl-k)
3. Change the destination directory to something else (with Ctrl-o)
4. Restart the download (thus in the new directory)
<something unexpected happens (or an update), and you have to restart your computer>
5. rtorrent is restarted

Expected result: rtorrent remembers the directory change, and goes find the files there for hashing and resuming the download.
Actual result: rtorrent restarts the download from the beginning, in the default directory.

This is with a Ubuntu 9.10 using rtorrent 0.8.2-0ubuntu2 .

Here's what happened to me exactly: I usually want to download my torrents in my home directory. However, I came across this HUGE torrent, that won't fit in my home, so I stopped the download (with Ctrl-k) as soon as it started, and told rtorrent to download it on a (much bigger) USB external hard drive instead (with Ctrl-o). I restarted the download, and everything was fine... until my computer froze (not rtorrent's fault) and had to be restarted.

When I started rtorrent again, it tried to find the file in my default rtorrent directory (in my home folder, thus). I tried the same as before: stopping it, changing the directory, then initiate a hash to get it back to downloading. While the hash seemed to work (it was properly indicating how much of the download had previously been completed), the download stayed on status "OPEN" and "Inactive". Ctrl-s didn't help. No way to start this download again. The log indicated something like "impossible to create the folder" (well, obviously(!), since it was already there and rtorrent had just hashed it!).

I ended up changing the default directory in my .rtorrent.rc file and restarting rtorrent. That did the trick (the hashing went well, and this time Ctrl-s did restart the download (I don't understand why it went to "Inactive" and I had to restart it myself, though)), but it's a pretty ugly workaround, in my opinion. I'll have to change my config file after this torrent is done downloading...

[Alexei Colin (alexei.colin)]

Hi. Just for the sake of contributing some more information on this case, I went through your steps and here's what I got (also, Ubuntu 9.10 with rtorren t 0.8.2-0ubuntu2).

Case 1:
 1. Add torrent (adds into a CLOSED state, so no files are created in the default directory)
 2. Change torrent download directory
 3. Start the download (files created in the new directory)
 4. Kill rtorrent *not* graciously (e.g. killall -9 rtorrent) to simulate a crash
 5. Start rtorrent
Result: rtorrent opens with the torrent in the CLOSED state and directory set to the *default* directory.
 (5a - no effect). Start rtorrent (files created in default directory, since nothing was ever there), stop and close the torrent back.
 6. Change download directory to the new directory (with partial data)
 7. Start the torrent (Ctrl-s)
Result: Hash re-check is automatically triggered and torrent download is continued into the new directory.

At least this use case does not necessary suggest a bug. rtorrent is not cleanly shut down so the directory change does not make it to the session file, so when it starts back up the session information is out-of-date. The straightforward recovery from the situation worked for me (whereas it did not for you -- strange). I haven't read the code, so this might not be relevant, but perhaps session changes could be pushed to the file more frequently (and maybe fsync() should be used, esp. on events like directory change) -- just a thought. Note that if I cleanly quit rtorrent in step 4, then the directory change is remembered as expected.

By the way, to change the default directory without reloading .rtorrent.rc you can do Ctrl-x, directory=/path/to/dir.

Case 2:
 1. Add torrent
 2. Start torrent (creates files in the default directory)
 3. Stop and close torrent
 4. Change directory
 5. Try to start torrent (Ctrl-s)
Result: Cannot start torrent (error in log: "could not find file [one of torrent content files in torrent's new directory]").
 6. Try initiating hash recheck (Ctrl-r).
Result: rtorrent *crashes* with "rtorrent: TrackerManager::send_later() m_control->set() == DownloadInfo::STOPPED." and return code 255.

This use case looks like a bug, though. But maybe it was fixed in latest version of rtorrent.. I should try that soon.

[Andreas Moog (ampelbein)]

Thanks for the report, this issue is an upstream one and reported to the developers here http://libtorrent.rakshasa.no/ticket/2528

[rumburak (s3506963)]

I confirm this bug for rTorrent 0.8.6/0.12.6 on Ubuntu 10.04