Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#3419 closed Enhancement (duplicate)

Cleaning .part and not selected files

Reported by: k0sh Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.01
Severity: Normal Keywords:


A very useful feature of Transmission is the possibilty of selecting just the files you want to donwload from a torrent.

I understand that is impossible for Transmission to download just the exact selected files due to the way the bitTorrent protocol works.

The problem with this is if you select just part of a torrent for download, you'll get unwanted files/folders and ".part files" scattered all over the place.

If you're downloading a torrent with a large number of files and folders it's really a pain to clean all those files and to be sure you're not deleting anything you're not supposed to.

It would be very useful if Transmission could automatically clean all these files and folders after downloading/seeding. Think this would be very easy to implement.

Sorry if my english sucks.

Keep up the good work.

Change History (18)

comment:1 Changed 13 years ago by livings124

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

This appears to be covered by #532

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

comment:2 Changed 11 years ago by porg

  • Resolution duplicate deleted
  • Status changed from closed to reopened

I'm missing the same functionality: The possibility to easily differentiate wanted from unwanted files, if you have selected a few (i.e. 20) files from a torrent with very many (i.e. 1000) files, and get many by-product files (due to overlapping)!

It is then a hard manual labour to find out which files are indeed desired files, and which not.

  • Either you still know your selected files by heart,
  • or you took notes on your selected files and use this for picking the needles out of the haystack,
  • or you open all files with a hex-editor and see which ones are just blank files (0x00 …),
  • or on OSes which differentiate between sparse/normal files, you can maybe filter by that in your file browser.

Is it possible that Transmission uses the filesystem API to label wanted and unwanted files as such, i.e. using Finder labels? Would be fine if the user could set which label for what kind. By default I'd say to use "green" for "wanted", "grey" for "just an unwanted by-product file".

Have the patches from #532 been included into the normal distribution?

The only user exposed feature, which I encountered so far, which covers the topic, is the option to suffix ".part" to partially downloaded files. But this alone would not help me to differentiate wanted from unwanted files. We would need:

  • ".part" for wanted files, which are yet only partially downloaded,
  • ".overlap" (or a similar naming), for the undesired but necessary by-product files,
  • No suffix for wanted and already finished files.

But as written before, I'd prefer to put the file's type/state into its metadata (Finder label on Mac OS X, respective flags/tags on other OSes), instead of the filename.

comment:3 Changed 11 years ago by livings124

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

Using Finder labels for this seems less obvious, not more obvious. It also isn't compatible with other operating systems, and won't make people that use labels for other reasons happy. Plus I don't believe differentiating files that are wanted but incomplete to overlap files is important.

comment:4 Changed 11 years ago by porg

1) I understand your reasoning for not introducing metadata flagging, but rather to rely on filename, as this is much easier to implement and available for all OSes. Conservative approach, but ok.

2) If the download of all files is finished: How can I differentiate overlap from wanted files? Please tell me, I do not see a way with the current featureset of Transmission 2.42! This is definitely a use case.

comment:5 Changed 11 years ago by livings124

Files that finished downloading don't have .part at the end, assuming you have the feature enabled. #532 would also take care of this.

comment:6 Changed 11 years ago by porg

From observing this in practise I can now tell:

Even if I use the function "append .part to unfinished downloads":

  • When downloads are finished I have no way to differentiate desired files from undesired overlap files (if 100% of an overlap file was contained in a torrent piece overlapping with one of your desired files)!
  • One has to use manual labor to sort that out! To avoid this, it would be desire-able option:
    • to have a certain suffix for overlap files (i.e. ".overlap")
    • or to have all overlap files at once place (as suggested in #532).

comment:7 Changed 11 years ago by livings124

Once a file is downloaded, it's downloaded. I'd rather Transmission not differentiate downloaded and desired and downloaded and not desired - at that point, it's downloaded anyway.

comment:8 Changed 11 years ago by porg

And thus it needs manual labor, to separate content you want from that you don't want, as described in comment:2! This is not much trouble in torrents with <10 files, but a horror in torrent with >100 files. I would love that the software could spare me this task, and support me (user centered), rather than bothering me with circumstances, which originate from technical necessities.

@livings124: I think Transmission is a great software, and I respect and adore what great functionality you achieved with it so far! Nevertheless, reasoning with you over the last years mostly felt hard to me, almost frustrating at some time, to a degree that I decide: Hmm, that aspect could be better, but forget about it and don't report it, as livings124 is very likely to reject it anyhow.

comment:9 Changed 11 years ago by livings124

If a second extension is added in (.overlap), then it would reason that Transmission would have to allow you to select and deselect selected files, and append the extension. #532 is the better option.

porg: Just because I don't agree with you doesn't mean I'm being contrarian. I'm not turning down ideas just because I like turning down ideas. I'm just trying to make Transmission the best application possible.

comment:10 Changed 11 years ago by porg

Ad paragraph 1: I do not understand your explanation, both by grammar and meaning (=semantically). Please try it again. Or you could write me in German, if that helps.

Ad paragraph 2: If I continue your thought, it must conclude, that most of my contributions so far must have been of bad quality from your point of view. Sad, but I have to accept it.

comment:11 Changed 11 years ago by livings124

To clarify paragraph one, we don't want to have to keep track of which files are selected/deselected. It'd be more confusing to select/deselect a file and have the file extension change as a result.

comment:12 Changed 11 years ago by porg

I understand that now. And using metadata (like file labels) you already rejected. So what other means to we have to quickly find all files, which one has deliberately selected?

I have a related idea, which would help to get an overview for this purpose as well:

Inspector 'Files' Tab: Offer sorting/filtering your file list (as tabular data)

Either leave the filter input field as is, and enable it to understand a special filter syntax like "finished" or "selected".

Or make it a (multikey) sortable table with the columns:

Type | Name | Size | % | Selected | Priority

Then one could simply filter or sort by Selected or % and more easily recognize the desired/finished items, whereas now you have to keep notes, and then compare the download folder with your notes in order to segregate your wanted content.

Type is "Directory" or "File MIME type" (main-type/specific-type), this also would allows better filtering/sorting in large mixed content torrents. Folders on top would help.

comment:13 Changed 11 years ago by livings124

This is starting to get awfully complicated. I don't believe overlapping files is such a huge issue. #4262 might do what you want.

comment:14 Changed 11 years ago by porg

You say it's "awfully complicated". For a user of multi file torrents, it is also an "awful amount of work" to find his/her desired files. But ok, if it is too hard for you to code, then better leave it. In my research I already stumbled across #4262. I don't think that it discusses my raised issue.

However, regarding overlap, much speaks for trying #532. Is #532 already included in the main version, the binary executable file, which one downloads from the website? Or does one need to patch and compile on his/her own? And if one uses #532 and later on decides to select a new file, which is already (partially) at your harddisk within the overlap file cluster, does Transmission use that local data (for speed gain), or does it download it all over again?

comment:15 Changed 11 years ago by livings124

I'm not turning this down because it's difficult to code. I'm turning this down because I believe this adds a net negative amount of complexity to the app, and adds an extension to perfectly-usable files.

#532 has not been implemented. I'm pretty sure the patch in it doesn't work.

comment:16 Changed 11 years ago by x190

Hi porg: I have been using "piece_temp.7.patch" from #532 patched to r11889 from svn continuously since it was available 10 months ago. I never have to sort through .part files or worry about wasted disk space for unwanted files (a macosx issue). I believe most, or all, of the issues you raised are covered by #532 with #4262 being a very useful complement. Of course this patch needs updating to work with the current version.

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

comment:17 follow-up: Changed 11 years ago by porg

@admin: Sorry for the noise, but I have to post this publicly, as I did not find a way to contact x190 by private messaging.

@x190: Thanks for tuning in! You seem to understand my concerns! Could you please publish your working compiled app? Thanks! My attempt to download, patch, compile myself, failed.

comment:18 in reply to: ↑ 17 Changed 11 years ago by x190

Replying to porg:

@x190: Thanks for tuning in! You seem to understand my concerns! Could you please publish your working compiled app? Thanks! My attempt to download, patch, compile myself, failed.

You should be able to contact me by PM on the forum:

Note: See TracTickets for help on using tickets.