transmission "moves to trash" instead of promised "delete" without any warning / notice.

Bug #1162820 reported by MMlosh
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
transmission (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Release: 13.04 Raring
Package: transmission-gtk 2.77 (14031)
Package: ecryptfs-utils 103-0ubuntu2
Kernel: 3.8.0-14-generic x86_64
apport: 2.9.2-0ubuntu5, does not work
Using ecryptfs = Yes
ext4 mount options: rw,nodiratime,relatime,discard,errors=remount-ro

This used to happen on 12.10 Quantal as well.

download something.

Check the used disk space "df -h" or "du -s /home/.ecryptfs"
Select your torrent, Right click, select "Delete files and remove", confirm.
Check your disk space again.

Expected: appropriate amount of space immediately freed up.
Got: No space was freed, not even after closing transmission

Apport is still broken on Raring, see #1150335

Tags: quantal raring
MMlosh (mmlosh)
summary: - [ecryptfs] "Delete files and Remove" leaks HDD space
+ [eCryptfs] "Delete files and Remove" leaks HDD space
description: updated
MMlosh (mmlosh)
affects: ecryptfs → ecryptfs-utils (Ubuntu)
description: updated
MMlosh (mmlosh)
summary: - [eCryptfs] "Delete files and Remove" leaks HDD space
+ [eCryptfs on ext4] "Delete files and Remove" leaks HDD space
Revision history for this message
MMlosh (mmlosh) wrote : Re: [eCryptfs on ext4] "Delete files and Remove" leaks HDD space

The HDD space leak makes it hard to debug..

I tried with a more precise approach this time and installed no updates between downloading and removal.
The file I removed had 30MB, Free space before removal: 47M, Free space after removal: 47M

Is there anything in particular that I should try?
I don't like wasting my precious HDD space on random attempts.
removing transmission-downloaded files with "rm" restores the free space as one would expect.

System info:
Using 13.04.
Kernel 3.8.0-14-generic x86_64
Transmission 2.77-0ubuntu1
ecryptfs-utils 103-0ubuntu2
ext4 mount options: rw,nodiratime,relatime,discard,errors=remount-ro
apport 2.9.2-0ubuntu5, does not work

Steps I executed (full experiment log)

$path denotes the directory that contains the file to be deleted
$cryptopath denotes the same directory in encrypted version of the home directory.

The file was present both in $path and $cryptopath (checked by ls -lSrh and comparing timestamps and sizes)
df -h reported 47M of free space
Started transmission-gtk and selected "Delete files and Remove", confirmed
The file was gone from both directories,
BUT df -h still reported 47M of free space
Terminated transmission.. 47M of free space
shutdown and new startup.. 47M of free space
forced fsck.. discovered that the free space and free inode counters were wrong, I actually have only 46MB of free space.

description: updated
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1162820

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
MMlosh (mmlosh) wrote : Re: [eCryptfs on ext4] "Delete files and Remove" leaks HDD space

Apport is still broken, see #1150335

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
MMlosh (mmlosh) wrote :

I managed to reproduce on another box I don't care about.
The issue exists with the mainline kernel "mainline/v3.9-rc2-raring"

tags: added: kernel-bug-exists-upstream
Revision history for this message
MMlosh (mmlosh) wrote :

I am not sure that the tag "kernel-bug-exists-upstream" is correct (This might not be a kernel bug)

The issue lies somewhere in the chain transmission-ecryptfs-ext4(nodiratime,relatime,discard)

Changed in linux (Ubuntu):
status: Confirmed → Invalid
Changed in ecryptfs-utils (Ubuntu):
status: New → Invalid
Revision history for this message
MMlosh (mmlosh) wrote :

OOPS.. I just found out what is happening.

Transmission established a folder called "~/.local/share/trash" and moved the file there instead of deletion!

This is a serious issue. How was I supposed to know that one application decided that I want to keep my garbage?
The button should be renamed from "Delete" to something else to indicate that.

Or there should be an explanation like "(the file will be moved into trash)" in the confirmation dialog.
Why was I even confirming an operation that can be undone??

tags: removed: ecryptfs kernel-bug-exists-upstream
summary: - [eCryptfs on ext4] "Delete files and Remove" leaks HDD space
+ transmission "moves to trash" instead of promised "delete" without any
+ warning / notice.
no longer affects: ecryptfs-utils (Ubuntu)
no longer affects: linux (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in transmission (Ubuntu):
status: New → Confirmed
Revision history for this message
Michael N (michael-1234) wrote :

It seems that transmission-qt does delete the files when selecting "delete files & remove"; but transmission-gtk (the default) moves the "deleted" files to the trash. Note: this is using magnet links (if it matters), so there is no ".torrent" file. Some other forums suggest there should be an option in "preferences->desktop" to control this behaviour, but I don't see this option in the GUI. (Ubuntu 14.10, Transmission 2.82 14160)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.