Opened 10 years ago

Closed 10 years ago

#3732 closed Enhancement (fixed)

Delete system files when removing torrent data.

Reported by: Rolcol Owned by: charles
Priority: Normal Milestone: 2.33
Component: libtransmission Version: 2.11
Severity: Normal Keywords:


Transmission keeps the folder when torrent data is removed if it contains items other than those specified. Finder, on OS X, sometimes creates .DS_Store. To the user, it appears completely empty.

Some files that can be deleted:

.DS_Store ._.Resource Forks desktop.ini (Windows) thumbs.db (Windows XP)


(Mac prompted this ticket but I think it applies to libtransmission)

Attachments (2)

system-files.diff (1.9 KB) - added by jordan 10 years ago.
system-files-2.diff (4.0 KB) - added by jordan 10 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 10 years ago by charles

well, it just goes to show no feature is ever complete. libtransmission already goes through ugly steps to only delete files that were actually downloaded, and to leave alone any files that came from the end user instead. :)

livings, do you have an opinion on this ticket?

comment:2 Changed 10 years ago by livings124

When deleting, if all that's left is .ds_store and similar files it should just dump the folder as if those files weren't there. If there are "real" files, it should only trash the files from the torrent file.

comment:3 Changed 10 years ago by charles

What similar files should we take into consideration?

comment:4 Changed 10 years ago by livings124

Invisible files, I would guess. Not sure if there are others.

comment:5 Changed 10 years ago by x190

My thoughts are that this needs more testing. As livings124 states, invisible (OS X files prefaced by a .) should not affect this operation unless the user deliberately creates a file with a leading '.'. (This is highly unlikely and can be ignored.) Folders with subfolders use the .DS_Store file.

So, in the following example, "Canyonlands.png" represents the downloaded Transmission data file, "/Users/Desktop/Canyonlands?"-- the enclosing folder created by Transmission, so those two and all the rest can go. "." and ".." are like softlinks (or aliases) and "Icon?" links to a custom icon (beats that basic blue :) ) Again, all can and should be deleted upon selecting "Remove Data File...", IMO. If subfolders were involved, then the associated .DS_Store files should be deleted as well.

-iMac:~ $ ls -la /Users/Desktop/Canyonlands 
total 1776
drwxr-xr-x@  4   staff     136 Dec  5 03:21 .
drwx------+ 13   staff     442 Dec  7 02:11 ..
-rw-r--r--   1   staff  477089 Dec  5 03:20 Canyonlands.png
-rw-r--r--@  1   staff       0 Dec  5 03:21 Icon?

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

comment:6 Changed 10 years ago by alexbepple

I would like to see this issue solved for .DS_Store files.

comment:7 Changed 10 years ago by tomxor

The apple double files (separated resource forks) as mentioned in Rolcol's post can also be created and left behind through normal interaction in the Finder if the data resides on a non HFS partition.

This would happen when copying a file with a resource fork from a HFS/+ partition to the torrent's directory on a different file-system and then deleting it.

Even though the resource fork could still be considered user data... it's very rarely anything useful is in these files, they are more of a legacy thing (even though some new apps still create them).

comment:8 Changed 10 years ago by oh_noes

I would like to confirm the same behavior on Windows 7. My "download-dir" and "incomplete-dir" directories are shared (writable) via CIFS (Samba). When a torrent directory has a video file, Windows 7 behind the scenes creates a "Thumbs.db" File. This stops libtranmission from being unable to delete the directory when the torrent is moved or deleted.

I would like to propose (if I may) this be handled in two ways:

  1. As livings124, mentioned, have an array of known files which don't stop the directly from being deleted.
  2. Create a new configuration parameter for "hard-delete" (or similar) which tells libtransmission to forcible delete the directory even if any other files exists (additional to the original torrent) exist.

Point 2 is beneficial for the additional use cases where some users have "script-torrent-done-filename" script's that may create additional files into the same directory (rar files they extract a video file). This will allow them to forcable clean up the directories 'properly'. At the moment, after deleting/moving a torrent the extracted video files are left over and hence the directory is not deleted.

comment:9 Changed 10 years ago by jordan

Well, the reason this ticket exists is because of #1029 ... Transmission only deletes the files listed in the .torrent file and leaves everything else.

I don't really like the idea of keeping a list of known system files, and I also don't like the idea of making this a configuration option... then the developer team would need to keep and maintain two separate implementations.

All in all, I'm thinking #1029 may have been a bad idea in the first place.

comment:10 Changed 10 years ago by oh_noes

I completely agree on both counts. Rolling back #1029 and just simply deleting the directory solves all these problems.

comment:11 Changed 10 years ago by jordan

...on the other hand, the current system handles more gracefully the situation where two torrents have overlapping directory names.

comment:12 Changed 10 years ago by jordan

Actually, I wonder if part of the problem is that we're deleting .DS_Store from the "clean" directories rather than the "dirty" ones in deleteLocalData(). In that functions scheme, "dirty" directories are the ones that contain non-torrent files in them.

Changed 10 years ago by jordan

comment:13 Changed 10 years ago by jordan

Does any brave soul want to try system-files.diff and see if it helps things?

Changed 10 years ago by jordan

comment:14 Changed 10 years ago by jordan

actually system-files-2.diff might be better.

comment:15 Changed 10 years ago by jordan

that patch has been applied in r12540 so you can test it in the nightly builds...

comment:16 Changed 10 years ago by jordan

  • Milestone changed from None Set to 2.33
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.