Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#5156 closed Bug (invalid)

Changing torrent's Group after start doesn't respect new Group's Custom location folder once finished

Reported by: casemon Owned by:
Priority: Normal Milestone: None Set
Component: Mac Client Version: 2.73
Severity: Minor Keywords: group custom location start finish
Cc:

Description

MINOR: Changing torrent's Group after torrent has started doesn't respect the new Group's Custom location folder once finished.

STEPS TO REPRO; 1) create a group with the Custom location (folder) field set. 2) add any torrent as a non-grouped torrent. 3) after torrent from step #2 starts, change group to group created in step #1. 4) wait for torrent to finish.

RESULT: Torrent is not moved to it's group's Custom location on finish.

DESIRED: Group's Custom location field is respected even if group is changed after torrent is started in a different group.

Change History (10)

comment:1 follow-up: Changed 8 years ago by livings124

  • Component changed from Transmission to Mac Client
  • Resolution set to wontfix
  • Status changed from new to closed

That is actually by design. The location is only set when added to avoid excessive, undesired, and slow moves.

comment:2 in reply to: ↑ 1 Changed 8 years ago by casemon

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to livings124:

That is actually by design. The location is only set when added to avoid excessive, undesired, and slow moves.

Think this reason & decision is weak sauce, frankly, and shows poor design process.

Reasoning, the inconsistency of files selectively being placed in their appropriate folder depending on what group the torrent was in waaaay back at the start of transfer is much worse than behavior that is essentially files being moved to their expected folders for the user's desired and purposefully selected group. It's inconsistent and simply broken as is.

Adding, it ignores a very common workflow: adding magnet links that first appear as ungrouped depending on the file extensions, then changing them to another group, the files end up in the wrong folder because they were once in another group? It's silly.

Basically, don't over think it for the user; the current behavior is broken: files should go to the current group's folder once finished, not the first group the torrent was assigned to.

This is simply bad design.

comment:3 Changed 8 years ago by livings124

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

This would make it impossible to set a torrent's group without also changing it's location. Moving also isn't instantaneous, especially across volumes. Plus there are a ton of edge cases, such as if a custom location was set for a specific torrent. The annoyance of changing location when changing a group outweighs the benefit and potentially confusing behavior.

comment:4 Changed 8 years ago by casemon

  • Resolution invalid deleted
  • Status changed from closed to reopened

Sounds like you're replying to something else, different than this issue.

This issue is NOT about moving torrents to a new folder whenever changing groups; yeah that would be annoying.

The issue is making sure the torrent's files are moved to the assigned group's target folder (if any) when it finishes.

Right now, if you assign an unfinished torrent to another group after that torrent has started, it will be moved to the starting group's folder when it is finished. This is clearly a bug and fixing it does not involve any of the issues you mentioned.

The desired behavior again is that the torrent files should move to the assigned group's folder (if any) when it finishes, not the target group that it was assigned to when the torrent started.

See the difference?

comment:5 Changed 8 years ago by livings124

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

OK, that makes a lot more sense.

The issue is that the final download folder is still what's set when added. All the issues I brought up, besides the files moving and slowing things down when an incomplete folder is set, still exists. I see the benefits of this in a few cases, but the disadvantages definitely outweigh the advantages (especially when no incomplete directory is set).

comment:6 Changed 8 years ago by casemon

  • Resolution wontfix deleted
  • Status changed from closed to reopened

You mention "all the issues I brought up" but your replies only makes a single vague reference to "a ton of edge cases" then specifically mentions 1 non-issue: custom download folders.

Custom download folders is a non-issue as, reasonably, if user is resetting a torrent's group, user also reasonably expects it to reset the download folder (if group has one specified).

Otherwise, if such is really a big deal, code can simply check if torrent has custom download folder different from folder for new group and just not set the download folder in that case.

Such, it is a very simple problem to solve. Hence, having a different custom download folder is a non-issue.

What else is related to this? If none then...

Sorry, the original issue should be fixed.

comment:7 Changed 8 years ago by livings124

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

Setting a custom download folder is completely unrelated to group. A user should be able to change groups without worrying that their custom download location is going to be lost.

The main concern is for users not using an incomplete directory. In that scenario, the file would have to be moved each time the group is changed. Not doing that would be inconsistent with the behavior you want.

comment:8 Changed 8 years ago by casemon

  • Resolution invalid deleted
  • Status changed from closed to reopened

It is not difficult to set a priority here; one or the other. Basically if custom download folder is set, then the priority is changing groups doesn't move the file? Done.

re: user not using an incomplete directory It seems you're blocking a bug fix for an issue that practically never happens; if user changes a torrent to a group and the group has a location set (ostensibly that the user themselves specified), when do they NOT want it to move? Never. So why block this?

Not sure why you're fighting this so much, it's a very simple issue and currently broken, as-is.

From here, it looks that you're overthinking this one again.

comment:9 Changed 8 years ago by livings124

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

Once a torrent is added, its location is permanent. This is the intended behavior, and will not be changing for the reasons I have previously stated.

comment:10 Changed 8 years ago by casemon

Then it will remain a broken design, favoring one obscure, undesired workflow over a common, desired workflow.

Your call.

Note: See TracTickets for help on using tickets.