Not all .part files are removed

[Rolcol]

If I delete and remove a torrent while it's running, it will seemingly move everything to the trash as normal. What really happens, though, is that Transmission will make a copy of any file that is still incomplete and leave it in the Incomplete folder I've set and move one to the trash. If I stop the torrent before removing, everything will be moved to the trash as normal.

I've seen this bug in both the GTK and Mac versions of Transmission.

[Rolcol]

Here's a video of the Mac version behaving this way:

​http://roly.homelinux.com:10000/user/roly/transmission/partfiles.mov

[Rolcol]

I'm thinking it has to do with the cache writing out the contents of the torrent after the data has been trashed, thus causing Transmission to reallocate the files. I ran a sha2 checksum on the trash file and the incomplete one and saw that they differ.

[TeddyBeer]

I can confirm this bug. If i pause the torrent and then delete it with "delete file and torrent", all the part files get successfully removed from the incomplete directory.
If i apply "delete file and torrent" on a runnning torrent, part files and directory aren't deleted at all.

"rename-partial-files" true/false config doesn't change the issue.

Daemon Release: 2.10
RUNNING ON:
-OS: QNAP TS 119 firmware release 3.3.4
-CPU: arm (Marwell 1.2 GHz)
tried GUI: web-gui, qtr, transmission-remote-gui

[charles]

I haven't been able to trigger this yet but the video speaks for itself. The queue theory sounds promising too.

[starmoon]

i matter with this problem too.

[tstyblo]

This problem occurs even if you do not use the "Incomplete folder" feature, see #3778.

[charles]

r11537: possible fix

[charles]

Looks like the problem is from the stuff that gets downloaded in the second between the calls to tr_torrentDeleteLocalData() and tr_torrentRemove().

Removing the former, and adding a "deleteLocalData" flag to the argument list of the latter, seems to solve it. Attached is a patch that implements that for libtransmission and the GTK+ client... we'll need to get livings in on this too.

[charles]

r11538 /trunk/ (6 files in 2 dirs): (trunk) #3675 "Not all .part files are removed" -- added patch for libtransmission and GTK+ client

r11539 macosx/ (Controller.m Torrent.h Torrent.m): #3675 "Not all .part files are removed" - Mac patch

r11540 libtransmission/ (torrent.c transmission.h): (trunk libT) make tr_torrentDeleteLocalData() a private function

[tstyblo]

Replying to charles:

Unfortunately, this patch does not solve the problem described in #3778. I think there may be another problem related to the "Trash Data & Remove From List" feature.

[charles]

I'm not seeing this problem anymore post-r11539. how do I trigger this bug?

[tstyblo]

Replying to charles:

I'm not seeing this problem anymore post-r11539. how do I trigger this bug?

Just use the "Trash Data & Remove From List" context menu option in the web interface with any torrent that is not paused and is currently downloading data. The .part file is not removed. I've verified this with the 2.12 release and your patch.

[jordan]

confirmed... grumble :)

[jordan]

r11834

(trunk) #3675 "Not all .part files are removed" -- handle trashing files via RPC.

When libtransmission gets a "remove torrent" request from RPC, it tries to delegate the work. This is because the GTK+ and Mac clients don't want torrents disappearing in a different thread and causing possible thread issues. So the GTK+ and Mac clients get notification about this via libtransmission's RPC callback and remove the torrents themselves. Unfortunately, that notification doesn't include information about whether or not to delete local data.

This commit adds that information to the RPC callback so that the Mac and GTK+ clients will know whether or not to trash the local files when a third-party RPC client requests that at torrent and its files be deleted.

[livings124]

r11835 adds this for the Mac client