Opened 12 years ago

Closed 12 years ago

#2440 closed Enhancement (wontfix)

New Tool: Hardlink selected torrent(s)

Reported by: porg Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.75
Severity: Normal Keywords: torrent, file, hardlink, tool, comfort, ease-of-use
Cc:

Description

FEATURE REQUEST:

I suggest a new tool, which would work like this:
1) The user selects one or multiple torrent(s) in the transfers window, and right-clicks on them.
2) The contextual menu item now shows an entry "Create hardlink(s) for selected torrent(s)".
3) When the user issues the command the following happens:

  • He chooses a directory into which the hardlink(s) shall be created, the program shall remember the last directory-path.
  • If a torrent consists of a single file, a hardlink is created for this file only.
  • If a torrent consists of folders (and subfolders), and files within those structures, the entire file/folder structure is recreated within the target directory, the folders being new filesystem entries and the files being hardlinks to the original torrent files.

BENEFITS:

This new feature encourages seeding by making the moving of torrent files for further resorting/renaming much more comfortable. The user can continue seeding, and at the same time already move and rename the files according to his particular taste/sorting system.

Currently many users will just quit the torrent, and then move its file(s). At best copy the torrent file(s), continue seeding, and then work with the copies. I personally often use the hardlink method by issuing "ln torrent-file1 torrent-file2 target-directory/" in the command line, and would appreciate the comfort improvement by the new feature.

LIMITATIONS:

It is important for the user to know that those hardlinked files shall only be renamed/moved within the filesystem, but not altered themselves, as this by the nature of hardlinks alters the torrent files, hence making the torrent invalid!

Example: A user creates hardlinks of a set of music files (album) and imports them to his/her iTunes library by moving (not by copying). iTunes creates a parenting folder structure and renames the files (if set in preferences). This would still not break the original torrents. But as soon as the file is altered, the original torrent breaks. This happens as soon as iTunes alters the metadata of an audio file (i.e. ID3 tag in a MP3 file) which happens i.e. if iTunes analyses the song loudness, and writes a note into its ID3 tag, or if you alter the metadata yourself (song, artist, album, remark, etc).

Hence the first time the user issues "Create hardlink(s) for selected torrent(s)" s/he should be warned that s/he must be aware that the files can be renamed and moved, but must not be altered as this destroys the torrent!

ALTERNATIVE IDEA:

A similar effect could also be achieved if transmission would address files via inode and not filepath. Then torrent parts could be moved freely on the filesystem. The same limitation as with the hardlink also applies here: file renaming and moving ok, but no file alteration!

Change History (3)

comment:1 Changed 12 years ago by livings124

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

This is not feasible,

comment:2 Changed 12 years ago by porg

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Your comment was brief and ambigious.

What do you mean by "not feasible"?

1) Not useful, no benefit for the user.
2) Can (technically) not be realised.

Depending on what you mean, please answer to this:

If 1) Please state at least some reasons!

If 2) My alternative suggestion to use inodes rather then filepaths is for sure hard to implement. But this was not my main request, just an alternative idea open for discussion.
The main idea "creating hardlinks for torrent files" is definetely realizible. And there is evidence that the Transmission project already seems to have the needed programming interfaces, because the contextual menu items "Show in Finder" and "Remove data file" are filesystem related functions, in the same realm as my suggestion.

comment:3 Changed 12 years ago by livings124

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

Sorry. I meant 2) technically cannot be realized without huge amounts rewriting. On top of that, however, once users move the data and change the name chances are they will change the data as well, corrupting the download and causing it to be redownloaded - definitely something not desired.

Of course a patch could persuade us, but this isn't something we'll be working on. Of course the data can still be moved using the in-app menu item for moving data.

Note: See TracTickets for help on using tickets.