Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#794 closed Bug (duplicate)

don't create files not being downloaded; wastes space

Reported by: wfaulk Owned by:
Priority: Normal Milestone: None Set
Component: libtransmission Version: 1.06
Severity: Major Keywords:


Transmission seems to create files that have been marked as do-not-download, apparently when a piece spans two files, one of which is set to be downloaded and the other is not. This causes two problems.

First, the existence of the file when you've asked for it not to be downloaded is irritating.

Second, and more importantly, the HFS filesystem doesn't support sparse files. This is relevant when the piece is the end of the do-not-download file. Even though Transmission has only saved a fairly small amount of data, it has saved it at the end of that file. Since HFS doesn't support sparse files, that means that the full size of the file gets allocated in the filesystem. So if the unwanted file is, for example, 500MB and the piece size is 512kB, notionally you've only saved at most 512kB of unwanted data, but the full 500MB gets allocated on the filesystem.

Change History (5)

comment:1 Changed 14 years ago by moof

What you describe is an effect not limited to Transmission but occurs in other Bittorrent clients also. It is a side-effect of a download block, which the torrent is split up into, spanning more than one file. From my understanding bittorrent clients must save this data, else they wouldn't be able to accurately verify the downloaded data as part would be missing; similarly this would cause the client to continuously re-download the block.

comment:2 Changed 14 years ago by livings124

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

moof is correct. Bittorrent requires data to be downloaded in blocks, meaning part of the previous file and next file must be downloaded. Refer to tickets #532 and #514.

comment:3 Changed 14 years ago by wfaulk

  • Resolution invalid deleted
  • Status changed from closed to reopened

I understand that BT requires data to be downloaded in blocks. I'm not suggesting that the extraneous data not be downloaded, only that it either not be saved (though it's a good point that that data needs to be saved in order to verify integrity), or saved in a cache file in a way that doesn't cause excessive space to be allocated on the filesystem.

The problem is not the fact that that data is getting downloaded, but that it's creating a file you didn't ask for, and, especially, that that file can eat up a lot of disk space.

comment:4 Changed 14 years ago by wfaulk

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

Oh, nevermind. I see now that this was discussed as part of #514. #532, when implemented, will solve this problem.

comment:5 Changed 14 years ago by charles

  • Component changed from Transmission to libtransmission
Note: See TracTickets for help on using tickets.