Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3387 closed Bug (invalid)

When restarting transmission, torrents "removed", from the library's monitoring randomly come back

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

Description

When restarting a client using transmission-lib, torrents previously removed from lib-torrent's list of torrents may come back randomly.

If one sets up a watch dir and uses it, the default is to leave those torrent files in the watch dir. However if one removes the torrent, libtransmission sees those previously added torrent files as new again -- when they are not -- they were removed. This is a bug. libtransmission needs to not see an added torrent file in the 'watchdir' as *multiple* additions of a torrent I.e. each time you delete and restart. libtorrent sees the old torrent file in the watchdir as "new" again. This is obviously wrong. It was not / is not a new entry. Transmission is forgetting that it previously saw those files -- thus the bug.

Note -- the above behavior is the default when one uses a watch dir. Other options may change this behavior, but in absence of other options, the default behavior is libtorrent trying to recreate removed torrents This is is the default state when one starts with transmission (the linux GUI) or transmission-daemon.

There may be options to work around this bug, but they are not the default and are not fixes for the bug.

I'm told that other torrent programs don't have this bug. It seems to be unique to programs using 'libtransmission'.

So there is no confusion, I offer no ideas on how to fix this bug. Just the observation that it is undocumented behavior that violates normal behavior of torrent programs.

Change History (9)

comment:1 Changed 12 years ago by livings124

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

Now you're just trolling. #3378

Just enable the delete-torrent-file option.

comment:2 follow-up: Changed 12 years ago by Astara

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Please don't take a honest attempt to resubmit a real error in form that won't confuse some people as trolling. It was obvious that adding suggestions for possible ways to fix the problem in my earlier submission completely derailed the bug being addressed, as the previous *bug* was closed with "your suggested fix is invalid [so we are closing the bug]".

Just because they didn't like my suggestion was no reason to close the bug. The bug is still unaddressed. So I refiled it w/o suggestions so as not to cause confusion.

Since this bug is obviously NOT a suggestion, it cannot be a duplicate of one that was closed because "we don't like this suggestion'.

Here, in the comments, I can propose a solution, but these are not in the original statement of the bug. They are just 'comments'. Hopefully suggestions in the comments can be kept separate from the bug.

If you want to keep the current behaviors, then two things I would see to make it acceptable. 1) Don't make the 'random behavior' the default as it is now. In the absence of options, torrent files are kept in the watch dir. Just document that if a watch dir is used, by default, the torrent file will be deleted after being processed.

2) under the 'notrash/nodelete' (are you renaming it?), note the consequences: that undeleted torrent files in the 'watchdir' will cause them to be restarted even after they have been 'removed/deleted' from the 'all torrents' list, AFTER a restart of transmission.

Does that sound reasonable? It keeps the current behavior, but makes the 'confusing behavior' non default, and it documents the consequence of changing the default.

It's not, IMO, a good choice -- we should follow the actions of the norm and rename them after completion OR -- a better choice:

Another option (which I like best) -- in the same vein as having alt dirs for 'working/complete' torrents, allow a '--archive-dir' that "processed torrent files" from the watch dir would move moved to." Then users who want to keep them get that option.

comment:3 in reply to: ↑ 2 Changed 12 years ago by charles

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

Replying to Astara:

Please don't take a honest attempt to resubmit a real error in form that won't confuse some people as trolling. It was obvious that adding suggestions for possible ways to fix the problem in my earlier submission completely derailed the bug being addressed, as the previous *bug* was closed with "your suggested fix is invalid [so we are closing the bug]".

Are we reading the same ticket? The previous ticket was closed with "the developers are in agreement that this enhancement falls outside the scope of the application."

I don't know where the quote you're citing came from.

The previous ticket's issue was "watchdir torrents keep being readded." This ticket's issue is "When restarting transmission, torrents removed from the library's monitoring randomly come back." They are clearly the same issue.

comment:4 follow-up: Changed 12 years ago by Astara

  • Resolution duplicate deleted
  • Status changed from closed to reopened

The quote came from the first two closures. When you came back that all the other torrent programs do something with files in the watch dir, then some group of people 'developers'? (I wasn't there)...I was just on the channel and asked if anyone wanted it this way -- no one was in favor of the random behavior that now exists -- and dealing with the issue in some manner rather than just ignoring it is far favorable.

It's not documented behavior -- as I have said before. In the programming world, non-deterministic behavior means it is a bug -- unless you are implementing a random number generator -- but that's not what is being implemented here. Users want predictable behavior. Why would 'developers want to screw over users? What's the point here? What are you trying to achieve by harming users?

You are causing users harm by doing this. Yet you don't seem to care -- are you deliberately trying to write a program that causes disruption? or bad behavior? Having things starting randomly when I don't tell them to start is BAD behavior. How can you justify it?

This Isn't an enhancement or a request for an enhancement. It's a fix for malicious behavior. I call it malicious -- because at this point, it seems you are intentionally designing the program to do this. Not fixing this means you are designing in malicious behavior that could cause users problems later on.

That should not be the behavior of any program. As I mentioned, this could easily byte someone who belongs to any one of a number of private torrents -- where if you violate their allowed numbers of torrents or hit their site with bogus torrent requests, they may ban you. I've personally seen sites with that policy and heard from people that it happened to. In there case it wasn't because of random torrents restarting -- it was another mistake on their part. But this BUG could easily cause the same behaviors. It's irresponsible not to take any action - even if it is as simple as changing the default and documenting the behavior with strong warnings NOT to change the default from 'delete-torrent'.

Worse -- suppose someone is downloading a torrent that is legal, but then becomes licensed in their legality whereby uploading it, it would be illegal -- then transmission would be causing some copyright crime. You aren't thinking about the ramifications of this.

I'm surprised. You opened the bug because it was 'normal' for torrent programs to handle this.

Why wouldn't I want transmission to handle this? What guiding principle am I missing that I wouldn't want transmission to act sanely in this circumstance?

As a developer, I DO want to see this in there.

So I disagree with your assertion that we don't want to see this fixed and don't want to see transmission handle this.

I would like to see transmission become a full featured file-manager...why not? Are there any otherS? strip down clients are dime a dozen. What's the point of doing another if you don't want to do it right?

comment:5 Changed 12 years ago by livings124

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

Transmission will not become a full featured file manager. It is a torrent downloader/seeder - that's it. This is getting annoying. Turn on auto-delete torrent files and be done with it.

You're getting awfully close to a ban. Please, stop this ranting and trolling.

Last edited 12 years ago by livings124 (previous) (diff)

comment:6 Changed 12 years ago by howl

Replying to Astara:

...then transmission would be causing some copyright crime.

I quote this to remember you just in case you reply again you are not trolling. As a developer, you should know some concepts about the legality of some type of programas like P2P ones, if not, no prob, just try to read the first run message in Transmission that you should have reed.

comment:7 Changed 12 years ago by charles

I was just on the channel and asked if anyone wanted it this way -- no one was in favor of the random behavior that now exists

That's an interesting way of describing the conversation. Here's the transcript:

11:32:08 -!- Astara [~chatzilla@ishtar.tlinx.org] has joined #transmission
11:33:02 < Astara> so does anyone want to discuss why transmission shouldn't do something with torrent files in the watch directory?
11:34:08 < Astara> is everyone in agreement that transmission should do something with files in the watch directory?  If not, raise your hand?
11:34:23 < Astara> ....going once
11:34:30 < Astara> going twice
11:34:37 < Astara> ok...it passes.
11:34:49 < Astara> just what I thought.
11:43:49 < fow> Was that your clever way of saying "Transmission isn't doing anything with torrent files in the watch dir I've set. Can anyone help?"
12:01:16 < maru> yes?
12:28:39 < geirha> FYI. Transmission *does* do something with torrents in the watch dir...
13:35:43 -!- Astara [~chatzilla@ishtar.tlinx.org] has quit [Remote host closed the connection]

comment:8 in reply to: ↑ 4 Changed 12 years ago by charles

Replying to Astara:

I'm surprised. You opened the bug because it was 'normal' for torrent programs to handle this.

Wait, what?

You opened this ticket. livings closed it as a dupe. You reopened it. I closed it as a dupe. You reopened it. livings reclosed it.

Also, you use the word "normal" in quotes, but the only person to use that word so far is you.

You are the only person who opened this ticket. You are the only person to use the word "normal". Who are you talking to?

comment:9 Changed 12 years ago by charles

As a developer, I DO want to see this in there.

So I disagree with your assertion that we don't want to see this fixed and don't want to see transmission handle this.

What is this "as a developer" and "we" talk? Your status in Transmission is currently somewhere between "ticket creator" and "resident troll." Regardless of your prior credentials, I do not recognize you as a Transmission developer until your patches-to-flamewars ratio improves dramatically.

I'm now wondering whether you are who you claim to be, or whether you picked her name at random off an LKML archive as a devious form of indirect social engineering.

Note: See TracTickets for help on using tickets.