Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3378 closed Bug (invalid)

watchdir torrents keep being readded

Reported by: Astara Owned by: charles
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.01
Severity: Normal Keywords:
Cc:

Description

they are the torrents that won't die! ARG...friggin zombie torrents!

I 'remove' them and think they are gone -- problem is, they aren't. the .torrent file is still in transmission's home directory under 'torrents', AND there is still a file for it under the "resume" directory.

Suggestion -- if you don't want to delete them (and maybe, they should be deleted out of transmission's home dir, if the user says remove them. Remove and delete is to remove the data -- so remove, maybe should cover all the torrent related files). But if you feel some need to keep them -- then maybe those files should be renamed to something like xxx.torrent.removed, and xxx.noresume.

Anyway -- because those files stick around -- the next time you restart transmission -- those 'removed' torrents come back.

Change History (21)

comment:1 Changed 11 years ago by Astara

Update -- I think the above is incorrect now... It's because the torrent files are still in the watch dir, I think that they get restarted -- then they end up in the 'resume' and 'transmission-home/torrent' dir.

So -- same point -- but it looks like the real culprit are the torrent files left in the watch dir.

So maybe rename it to .torrent.remove?

comment:2 Changed 11 years ago by charles

Which client are you using?

comment:3 Changed 11 years ago by Astara

Combination of the 'Pascal' based Windows GUI and heavy supplementing with the command line for the many things you can't do in that GUI.

At one point used the python based curses interface -- was handy for toggling turtle mode which I used at the time, but since I don't use that anymore, I don't use that client. I also used the linux GUI, initially -- most of the parameters were set by that GUI. When I later started running the daemon, I made sure its' config pointed to the same files as the GUI, so it would use all the same settings.

unfortunately, the GUI doesn't talk to the daemon, so I haven't used it since -- or it would cause conflicts with the daemon (them using the same files and all).

At first, I used the feature of moving files into the watch dir to start files. As I went off of utorrent, I set it up to move finished torrents into transmission's watch dir. It would pick them up and verify the data and pickup "uploading", where utorrent had left off. But when those file get moved into the watch dir, there's no way to clean them out (short of manual deletion) -- so if you ever want to delete a torrent or remove it from the list -- it will get picked up again from it being in the watch dir. Transmission doesn't "do" anything with them once it has read them, so they just sit there, ready to restart themselves if you remove them from the GUI.

It appears, that removing them in the Windows GUI, causes the corresponding torrent and .restart files in 'transmission's "home" directory to disappear, but it does nothing with the torrent file that may have started it sitting in the watch dir.

Upon a reboot, or restart, it sees them as new additions.

comment:4 Changed 11 years ago by Longinus00

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

EditConfigFiles: trash-original-torrent-files

comment:5 Changed 11 years ago by Astara

  • Resolution worksforme deleted
  • Status changed from closed to reopened

'trash-original-torrent-files' deletes the torrent file.

I want to keep it -- but I don't want the torrent restarting every time I restart the daemon.

That the daemon restarts itself from a torrent I have removed is the bug.

That's why I suggested renaming torrent files for removed torrents to something other than "X.torrent".

Either that or move the torrent files out of the the 'watch' dir into a 'done' or 'processed' dir (assuming the user doesn't want to trash them)...

comment:6 Changed 11 years ago by livings124

  • Resolution set to worksforme
  • Status changed from reopened to closed

What you're suggesting is outside the scope of what we want to do with torrent files. We do not want to worry about managing them, etc.

comment:7 follow-up: Changed 11 years ago by Astara

I wasn't suggesting anything.

I reported a bug

It is still a bug whether you like my solution or not.

Torrents still restart at random.

I don't have trash torrent files turned on.

Show me where it is documented that I have to have 'trash originals' turned on or my torrents will restart randomly after deletion. If that isn't documented behavior, then I assert it is a bug. Having torrents restart at random is unpredictable and unwanted behavior -- unless you are documenting that you must have "trash originals" turned on or you will get "random behavior". But I don't recall reading that anywhere -- is this documented behavior?

Last edited 11 years ago by Astara (previous) (diff)

comment:8 in reply to: ↑ 7 Changed 11 years ago by charles

Replying to Astara:

I wasn't suggesting anything.

I reported a bug

It is still a bug whether you like my solution or not.

Please, let's not repeat the mistakes of previous tickets like #3262 which was sidetracked by a tangental discussion about the use of the word "game" or #3243 where a lot of time was wasted arguing whether the request for an .indent.pro file was a "bug" or "enhancement."

Astara, in this ticket *you* described your approach as a "suggestion" in the description. livings was using the same terminology you'd already used.

If you don't like the words you use, then choose them more carefully.

Still, the question of reappearing torrents from the watchdir may be worth looking into. Astara, you said that you used uTorrent before Transmission. How do other BitTorrent? clients address this issue?

comment:9 Changed 11 years ago by charles

  • Component changed from libtransmission to Transmission
  • Summary changed from removed torrents keep coming back from the dead! to watchdir torrents keep being readded

comment:10 Changed 11 years ago by charles

Okay, thanks to the magic of IRC I've talked to people associated with Deluge, Vuze, and uTorrent over the last 15 minutes. Here's how it works:

  • Deluge deletes the original file unconditionally
  • By default, Vuze deletes the file. However it has an option to append a ".imported" suffix.
  • By default, uTorrent adds ".loaded" to the file. However, it has an option to delete the file.

We've already got an option to delete .torrent files that are added, so this ticket is specifically about adding .torrents from a watchdir without deleting them. In that specific case, we ought to follow Vuze and uTorrent's existing solutions and append some suffix to the .torrent file. I suggest ".added" to add to the general confusion between clients. :)

I've reclassified this ticket as Transmission instead of libtransmission since all the clients would need to handle their own watchdir code. :/

comment:11 Changed 11 years ago by charles

  • Milestone changed from None Set to 2.10
  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:12 Changed 11 years ago by charles

20:13:11 <@charles> The_8472: ping
20:16:17 <@charles> also
20:16:19 <@charles> Firon: ping
20:21:32 < The_8472> pong
20:22:31 <@charles> The_8472: I have a question about Vuze's watchdir feature
20:22:39 <@charles> if a .torrent gets added from the watchdir, what happens to the .torrent file that's in the watchdir?
20:22:48 <@charles> does it just stay there, or is it removed, or is it moved to some 'processed' dir?
20:23:04 < The_8472> options 1 and 2 are available i think. let me check about 3
20:23:10 <@charles> what's the default?
20:24:05 <@charles> Firon: this is what I wanted to ask you about µTorrent, too
20:24:50 < Firon> about autoload?
20:25:13 <@charles> yeah, about what happens (by default) to the .torrent file in the watchdir after it's been added
20:25:24 < Firon> we rename by default to .loaded, but there's an option to delete instead
20:25:39 <@charles> that's all I needed to know.  Thanks
20:28:17 < The_8472> actually, it either deletes the torrent or appends .imported
20:28:35 < The_8472> Az i mean
20:28:38 <@charles> sounds like Transmission is late to the party with that feature
20:28:41 <@charles> *nod*
20:29:15 < The_8472> default is delete, since we keep internal copies of the .torrents
20:29:28 <@charles> okay, so everyone else has already hit the torrent-keeps-being-added issue and has already worked around it by adding some .loaded or .imported suffix to the file :)
20:30:25 < The_8472> pretty much
20:35:37 <@charles> The_8472: thanks

comment:13 follow-up: Changed 11 years ago by Astara

What transmission does is 1 thing -- that should be "enhanced" -- If my primary concern was to have transmission 'do something' I would have regarded it as an RFE...

BUT, I'd be "fine" with it's behavior to do "nothing" with the file after it is moved into the 'watchdir', _IF_ it didn't cause a bug.

My initial symptom (before I reported it here), was that after a reboot, I noticed several old torrents had come back to life.

This didn't happen with ALL of my removed torrents -- just 'some' AT the time, it appeared random. Not only that, but some of the torrents that came back to life had been deleted months ago -- so it looked very weird!

Finally I tracked it down to the fact that the ones that were restarted were coming out of the watchdir.

That was the nature of the bug I reported. Even though they were removed, they came back to life on the next startup.

As a way to deal with this, I made a suggestion. This bug report wasn't filed as a suggestion -- it was filed as a bug report. To deal with the bug, I tried to be helpful and come up with some ideas.

As a result, of trying to make some suggestions for possible work-arounds, people people focused on the suggestions and forgot they were only made because of some original problem (bug).

I didn't care if you took the suggestions or not -- how the problem was solved was less important to me than getting it solved. I just didn't want torrents that I thought I had 'removed', coming back to life days or weeks later whenever I restarted the daemon.

I'm sorry that my attempt to offer suggestions on how to deal with the problem resulted in so much confusion.

As a suggestion, I said, in lieu of deleting the torrent, one could rename them: either add a suffix or a new directory prefix. This seemed like a reasonable workaround for the bug.

Then everything that followed seemed like a big mess.

If I am reporting a bug, how do I make suggestions for possible workarounds so that it won't get mistakenly re-classified as an RFE?

From your last comment, it appears that after much bashing on me, you have arrived at the workaround I originally suggested. So why is it that it took all this harshing on me to get to this point? Do people like arguing with me that much?

Please stop assuming that I'm a blithering idiot that doesn't know what they are talking about. While I do make mistakes -- and will admit to them when I do, I usually tend to have a pretty good idea about what I am talking about (though I'll admit to being "communicationally" challenged, often!)

Cheers(?) :-?

comment:14 in reply to: ↑ 13 Changed 11 years ago by charles

Replying to Astara:

[wall off text summarizing the history of this 24-hour-old ticket, plus thoughts on the words "bug" and "suggestion", cheerfully ignored]

I don't care. Neither should you. Seriously. I mean that completely honestly and am not "harshing" you. Obsessing over one or two words has been a nonproductive pattern in the past that should be avoided.

While I do make mistakes -- and will admit to them when I do

Then you should apologise to livings for treating him as you did over terminology when you'd used the same terms. After that, let's drop it and move on.

comment:15 Changed 11 years ago by livings124

  • Milestone changed from 2.10 to None Set
  • Resolution set to invalid
  • Status changed from reopened to closed

The developers are in agreement that this enhancement falls outside the scope of the application. The option already exists to delete the torrent file on adding, and renaming these files falls under torrent file management, which we don't want to do. Users do not need torrent files once added, and they can be recovered through the app anyway; adding an option to rename the extension (to an invalid value, since it still is technically a torrent file) would just lead to people wanting the ability to auto move those files as well. We are drawing the line at auto-deleting them.

comment:16 Changed 11 years ago by howl

I'm not affected by this one by I think there is an option that doesn't involve Transmission managing torrents or renaming torrent files to an ugly extension.

I think that could be possible get rid of previously added torrents from watchdir having an internal array of the hashes of the torrents added from watchdir. So when a new torrent is seen by Transmission in watchdir if his hash is in the array do nothing, but if not add it. Also if there is a hash in the array but there is no torrent in watchdir with that hash, remove the hash from the array.

Last edited 11 years ago by howl (previous) (diff)

comment:17 Changed 11 years ago by charles

Ticket #3824 has been marked as a duplicate of this ticket.

comment:18 Changed 11 years ago by lecbee

My ticket was set as a duplicate of this one. What I want to know is what should do the "Trash Data & Remove From List" feature (I don't know if it's the correct words in english package). In my package, when I do a double-click on a torrent, I have (among others) 2 possibilities :

  • Remove
  • Delete the files and remove

What is the normal behavior of these features ? In my case the first one only deletes the .torrent file, the second one deletes only the data. So my conclusion is :

  • either the feature n° 2 is buggy for me
  • either the label is not correct
  • either it's the (in my case) french translation which is wrong (what is the original label ?)

comment:19 Changed 11 years ago by howl

Remove - Remove the torrent for the transmission's list. Delete files and remove - Delete the downloaded files and remove torrent from the transmission's list.

Neither of the options say that the torrent file is going to be removed even in French translation, so if you don't remove yourself (manage yourself) your torrent files Transmission will act as expected.

comment:20 Changed 11 years ago by lecbee

Ok I understand this point of view (even if from user point of view this seems strange), but in my case "Remove" deletes the .torrent files from my watch-directory. So if I follow you, it's a bug ?

comment:21 Changed 11 years ago by lecbee

Sorry I was wrong, the .torrent file is not actually deleted from my watchdir, you're right.

Note: See TracTickets for help on using tickets.