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

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.

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.

Apport is still broken, see #1150335

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

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)

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??

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

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)