Opened 10 years ago

Closed 10 years ago

#3675 closed Bug (fixed)

Not all .part files are removed

Reported by: Rolcol Owned by: charles
Priority: Normal Milestone: 2.20
Component: libtransmission Version: 2.11
Severity: Normal Keywords:
Cc: tstyblo@…

Description

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.

Attachments (1)

delete-on-remove.diff (6.3 KB) - added by charles 10 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 10 years ago by Rolcol

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

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

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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

Last edited 10 years ago by TeddyBeer (previous) (diff)

comment:4 Changed 10 years ago by charles

  • Milestone changed from None Set to Sometime
  • Status changed from new to assigned

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

comment:5 Changed 10 years ago by starmoon

i matter with this problem too.

comment:6 Changed 10 years ago by tstyblo

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

comment:7 Changed 10 years ago by tstyblo

  • Cc tstyblo@… added

comment:8 Changed 10 years ago by charles

r11537: possible fix

comment:9 Changed 10 years ago by 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.

Changed 10 years ago by charles

comment:10 follow-up: Changed 10 years ago by 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

comment:11 Changed 10 years ago by charles

  • Milestone changed from Sometime to 2.20
  • Resolution set to fixed
  • Status changed from assigned to closed

comment:12 in reply to: ↑ 10 Changed 10 years ago by tstyblo

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:13 follow-up: Changed 10 years ago by charles

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

comment:14 in reply to: ↑ 13 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by jordan

  • Milestone changed from 2.20 to None Set

comment:16 Changed 10 years ago by jordan

confirmed... grumble :)

comment:17 Changed 10 years ago by jordan

  • Milestone changed from None Set to 2.20

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.

comment:18 Changed 10 years ago by livings124

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

r11835 adds this for the Mac client

Note: See TracTickets for help on using tickets.