Opened 2 years ago

Closed 18 months ago

#2042 closed enhancement (wontfix)

Do not lose .torrent's

Reported by: Hosenduft Owned by: zzz
Priority: minor Milestone: undecided
Component: apps/i2psnark Version: 0.9.31
Keywords: privacy, usability Cc:
Parent Tickets: Sensitive: no

Description

Please, when "ejecting" a torrent, better move the .torrent file to a stale/Limbo directory instead of deleting it. This would make it easier to manage tasks on a busier system, without the need to find the associated torrent when wanting to re-activate.

Subtickets

Change History (6)

comment:1 Changed 2 years ago by zzz

Status: newinfoneeded_new

Never before requested. Would this be an option, or happen all the time, or somehow ask the user? How would this work?

comment:2 Changed 2 years ago by Reportage

Status: infoneeded_newnew

This seems like a good idea.

One way to implement this would be to provide an option on the configuration page:

  • "Preserve torrent files" which would then save the torrent files to a separate sub-dir in

the data dir, perhaps "ejected"?

In the event the user decides to delete torrent and data, a javascript popup might advise the user
that the torrent file has been preserved and needs to be deleted manually.

comment:3 Changed 2 years ago by zzz

I don't understand what the use case is.

If you just want to "re-activate" the torrent later, you stop it, and restart it later.

But OP wants to delete the data, but save the torrent file, and keep it in a separate directory. So when you "re-activate" it by moving the file back, you will be redownloading the whole thing. What's the point of that? I don't get it.

comment:4 Changed 2 years ago by Reportage

Maybe there's an alternative possibility to retain a record of downloaded torrents: an optional log (xml?) of all processed torrent hashes with the name of each individual torrent, without information that identifies the specific client. With some work, this log could be used as the foundation for automated download of multiple torrents, and as the foundation of an rss feed option (#2008 and #2009).

Last edited 2 years ago by Reportage (previous) (diff)

comment:5 Changed 21 months ago by str4d

Keywords: privacy usability added
Status: newopen

I suspect there is a UX issue here. Perhaps it is not obvious that the stop button is what should be used for managing system resources? Maybe there is a better way to handle the torrent list when there are a mix of stopped and running torrents? (What do we sort by in that case?)

I'm -0.5 on retaining a record of downloaded torrents by default, as that's a potential privacy issue.

comment:6 Changed 18 months ago by zzz

Resolution: wontfix
Status: openclosed

Not going to either keep a record or the files. Deleted should be deleted. Stop means stop only, not delete. Stopped torrents don't use any resources. Keeping the torrent file but not the data… we're really reaching to come up with a use case that anybody really needs. We haven't gotten any followups from the OP. Wontfix.

Note: See TracTickets for help on using tickets.