Kubuntu - Trash is not Drive Specific
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kdelibs |
Fix Released
|
Medium
|
|||
ntfs-3g |
New
|
Undecided
|
Unassigned |
Bug Description
Hello,
What I want to Do: I know KDE default trash location is /home/USER/
Objective: At this way I will be able to delete files faster than I do with Dolphin File Manager (I know I can use the Shift + Del to permanently delete files, but I really don't want them to be permanently deleted)...
PS: Actually I delete files only with Nautilus (Gnome) because it gives me that function (Dolphin can see these deleted files under the trash:/ folder too) by saving my deleted files in the path /media/
PS²: I really liked the KDE, but I need to say that the way it manages the trash is terrible compared to the GNOME in terms of speed of the deletion... Is this caused by the movement of the files between partitions (My data partition (/media/Dados) to Linux partition (/home/
PS³: I send the bug to the KDE Bugs report too: https:/
System Info: Kubuntu 10.10 (Maverick) installed via package "kubuntu-desktop" ; Linux Kernel *.23-generic-pak ; KDE 4.5.1 ;
Thanks for your Attention,
André M.
In KDE Bug Tracking System #76380, Luke-jr+kdebugs (luke-jr+kdebugs) wrote : | #3 |
In KDE Bug Tracking System #76380, David Faure (faure) wrote : | #4 |
CVS commit by faure:
Implemented "trashing-
created by root, or $topdir/.Trash-$uid if the user can create it,
as per the XDG trash specification)
CCMAIL: <email address hidden>, <email address hidden>
M +1 -0 trash.protocol 1.5
M +136 -18 trashimpl.cpp 1.20
M +8 -4 trashimpl.h 1.14
In KDE Bug Tracking System #76380, FiNeX (finex) wrote : | #5 |
Bug closed. Kdesktop is no more mantained.
In KDE Bug Tracking System #76380, Luke-jr+kdebugs (luke-jr+kdebugs) wrote : | #6 |
This bug is KDE-wide, not just KDesktop anyway. Still holds true for KDE 4.1.
In KDE Bug Tracking System #76380, FiNeX (finex) wrote : | #7 |
Why was this closed as "FIXED" ? It should have been left opened!!!!!
Moreover, if still valid for KDE4, probably it is not a "kdesktop" bug. It should be moved to a more appropriate component, otherwise developers will not find it (and so it will remain unfixed)
In KDE Bug Tracking System #76380, Luke-jr+kdebugs (luke-jr+kdebugs) wrote : | #8 |
Looks like a trigger-happy script closing everything KDesktop-related. Presumably this bug is in the trash KIO thing.
In KDE Bug Tracking System #76380, FiNeX (finex) wrote : | #9 |
Moved to kio/trash.
In KDE Bug Tracking System #76380, David Faure (faure) wrote : | #10 |
Unless you can create a $topdir/.Trash/$uid (where .Trash was
created by root), or you have a user-writable $topdir so that $topdir/.Trash-$uid can be autocreated, there is no other way to trash into the same partition. When that is the case (and yes, this is the most common case since mountpoints are usually not user-writable and admins don't create a .Trash subdir), then we have two choices:
- trashing to $HOME, so that you can restore trashed items, as expected.
- disabling trashing and only offering real deletion. Faster, but no going back.
Gnome does the latter AFAIK, while I chose the former. I think it's better to offer a solution that doesn't lose data, even if it's a bit slower, than going for the fast-and-dangerous solution.
I'm closing this bug; please read the trash spec for more details about $topdir/.Trash and $topdir/.Trash-$uid if necessary, to set one of them up in order to make it possible to trash on the same dir.
In KDE Bug Tracking System #76380, Luke-jr+kdebugs (luke-jr+kdebugs) wrote : | #11 |
Or you could rename /mnt/foo/bar/baz to /mnt/foo/
Obviously you can always write to the directory you're trashing from.
In KDE Bug Tracking System #76380, David Faure (faure) wrote : | #12 |
Good idea, but this is not how the trash spec works.
http://
If you want to push for a change in the spec, the mailing-list to discuss it is <email address hidden> (http://
In KDE Bug Tracking System #76380, quantumphaze (quantumphazor) wrote : | #13 |
This is still a problem. I'll try to give a better description of the problem to help searchers, feel free to change the original bug decription.
When user with $uid=1000 trashes the file /media/disk/foo.bar where /media/disk doesn't support *NIX permissions, it should be moved to /media/
When the $topdir/.Trash folder can't be made then it should use $topdir/.Trash-$uid
It works fine on a ReiserFS external HDD partition. But for FAT32 kio_trash puts everything that the user trashes into $HOME/.
Ideally it should ask the user what to do if it refuses to use $topdir/.Trash (Delete or $HOME?)
In KDE Bug Tracking System #76380, David Faure (faure) wrote : | #14 |
On Friday 16 October 2009, Andrew M wrote:
> Ideally it should ask the user what to do if it refuses to use
> $topdir/.Trash (Delete or $HOME?)
Well, both options _are_ available (Delete, and Trash).
So rather than asking the user every time (that would become really
annoying!) we just let the user choose, based on the action
he/she selected...
In KDE Bug Tracking System #76380, quantumphaze (quantumphazor) wrote : | #15 |
This thing is completely broken. At one point it made a .Trash-1000 folder on my usb stick (with files and info folders inside), but still moved it across partitions. I can't reproduce that exact behaviour again unfortunately, it doesn't make the .Trash-1000 folder and still moves across partitions.
This is definitely a bug. KDE refuses to make or use (if already there) a partition's Trash folder when the partition in question is a 100% user writeable FAT32.
Think if a user wanted to trash 20GB from a USB HDD on a old computer with USB1.1 and has only 5 GB of free space in $HOME. If KDE refuses to make a .Trash folder because of this bug it should inform the user that a sane trash operation can't be performed the way it is expected and defined by the Freedesktop spec with a dialog box with the options of Continue, Delete permanently and Cancel instead of defaulting to wasting an hour of the USB1.1 users time. Even with USB2.0 the lack of free space point still stands.
In KDE Bug Tracking System #76380, TrReardon (tr-reardon) wrote : | #16 |
It appears that this is working properly for _regular_ mounts now, but not for bind mounts. My /etc/fstab:
/dev/sda2 /mnt/disk2 ext4 noatime 0 2
/mnt/disk2/data /media/backup none bind 0 2
Anything deleted from /mnt/disk2 is properly put into a .Trash folder on /mnt/disk2 (or .Trash-1000 if .Trash does not already exist). However, when I delete anything from /media/backup it is wrongly placed into ~/.local/
Oddly, sometimes the .Trash-1000 folder structure is created by Dolphin on /media/backup, but then the deleted files themselves are not placed there, but instead into ~/.local/
This also applies to NFS4 mounts, since there are always multiple remounts from the main NFS4 mount point.
In KDE Bug Tracking System #76380, tnttrx (trx-lists) wrote : | #17 |
I can confirm that this problem is still present in KDE 4.4.5.
I have OS installed on SSD.
My /home directory is on SSD, too.
I use KDE 4.4.5.
Everything big is on NFS mounted inside my home dir.
Deleting (without holding shift-key) some file from NFS moves that file to SSD as there is trash bin.
That's not good.
I've tried to remove .Trash dir from top level of mounted NFS partition and first file moved to trash recreated that dir.
So, my user had sufficient permissions to create .Trash dir, but
(and that's sad part of the story)
instead of ending in
/home/myuser/
file ended in
/home/myuser/
So, after kde-lists kind suggestion to set "sticky bit" on .Trash, I've removed ".Trash" in topdir of my NFS partition, created new one as a root, changed permissions to my user, set sticky bit by chmod a+t and then chmod ga+w to get something like 1777. It was empty. I removed ~/.local/
Then I've deleted (moved to the trash bin) one small file (readme.txt) form NFS partition. After that, I inspected Trash dirs:
1. .Trash on NFS partiton got the subdir named "1000" owned by my user and with drwx------ permissions. Subdir "1000" had two subdirs: "files" and "info" and "files" with the same owner/permissions. These subdirs were empty.
2. ~/.local/
So, as far as I can tell, KDE makes right separate trash bin on my NFS partition, then KDE populates it with right subdir-structure, but at the end it doesn't use it.
USB behaviour is somewhat different: if I delete file from FAT32 formatted USB automatically mounted by KDE to /media/MYFLASH, no dirs are created on USB itself and file is moved to ~/.local/
Both of these kinds of trashing behaviour should be considered as a bug.
In KDE Bug Tracking System #76380, tnttrx (trx-lists) wrote : | #18 |
(In reply to comment #14)
just to add link to related mailing list thread:
http://
In KDE Bug Tracking System #76380, tnttrx (trx-lists) wrote : | #19 |
I can confirm that situation is the same with KDE 4.5.1 built by Gentoo.
description: | updated |
affects: | ubuntu → kubuntu-kde4-meta (Ubuntu) |
In KDE Bug Tracking System #76380, Tuxpoweruser (tuxpoweruser) wrote : | #20 |
This still happens with kde 4.5.4 compiled from source.
In KDE Bug Tracking System #76380, quantumphaze (quantumphazor) wrote : | #21 |
I think it's fixed. I trashed a file on a FAT32 USB stick on KDE 4.6 RC1 and it created the .Trash-1000 folder and put the file in there (with correct file and info dirs).
Can anyone confirm this works on their system for FAT32 or other filesystems without Unix permissions?
In KDE Bug Tracking System #76380, TrReardon (tr-reardon) wrote : | #22 |
Nope, I tried on 4.6RC1 and the problem persists. This is silly. Why have trash at all with an implementation this broken?
It does the wrong thing across multiple locally mounted file systems, across NFS mounts, across SMB/CIFS mounts. Anything deleted on ANY media is moved to the users home .local/Trash folder.
Changed in kdelibs: | |
status: | Unknown → Confirmed |
In KDE Bug Tracking System #76380, TrReardon (tr-reardon) wrote : | #23 |
(In reply to comment #7)
> Unless you can create a $topdir/.Trash/$uid (where .Trash was
> created by root), or you have a user-writable $topdir so that
> $topdir/.Trash-$uid can be autocreated, there is no other way to trash into the
> same partition.
David, you are simply wrong about how your implementation currently works. The $topdir/.Trash/$uid mechanism doesn't work at all anymore (4.5, 4.6RC1). The $topdir/.Trash-$uid autocreation does work, but only for first level mounts. Bind-mounts, anything which has been remounted, and network mount (CIFS or NFS4) all fail.
Gnome/Nautilus continue to work nicely and correctly.
Changed in kdelibs: | |
importance: | Unknown → Medium |
André Madureira (andreluizromano) wrote : | #1 |
This problem is KDE specific, so it's nor KUBUNTU specific... Therefore, it should be related only with the "kdelibs" package...
Changed in kubuntu-kde4-meta (Ubuntu): | |
status: | New → Invalid |
In KDE Bug Tracking System #76380, Matěj Laitl (f-matej) wrote : | #24 |
KDE 4.7.3, this seems like fixed to me. Can I close this?
In KDE Bug Tracking System #76380, Matěj Laitl (f-matej) wrote : | #25 |
*** Bug 100669 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Matěj Laitl (f-matej) wrote : | #26 |
*** Bug 213037 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, tnttrx (trx-lists) wrote : | #27 |
unfortunately, this is still present for me:
gentoo built kde-4.7.3
my home dir is on SSD, and inside that home dir I have mounted NFS dir (let's call it /home/user/nfs).
deleting file from my home dir puts it in the trash located at /home/user/
deleting file from /home/user/nfs dir makes /home/user/
but puts the file in /home/user/
:(
so far, no good.
In KDE Bug Tracking System #76380, Matěj Laitl (f-matej) wrote : | #28 |
(In reply to comment #24)
> unfortunately, this is still present for me:
> gentoo built kde-4.7.3
I can reproduce as described, reopening.
In KDE Bug Tracking System #76380, adaptee (adaptee) wrote : | #29 |
*** Bug 258720 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Quamis+kde (quamis+kde) wrote : | #30 |
works ok in 4.7.4
In KDE Bug Tracking System #76380, tnttrx (trx-lists) wrote : | #31 |
have you also tested it with NFS mount points?
In KDE Bug Tracking System #76380, Quamis+kde (quamis+kde) wrote : | #32 |
Didnt test with NFS. I tested with a local partition(the original report seems to refer to local partitions).
I had the same problem (when deleting on a different partition it would stay alot simply moving files between partitions) and came across this bug report. I fixed my problem by setting the mout options to "noexec,
I cannot test this on NFS though..
In KDE Bug Tracking System #76380, tomas (tomas-datasupporten-deactivatedaccount) wrote : | #33 |
Does not work with nfs. Not with encfs- or tmpfs-mounts either.
It works on a vfat-formatted usb-stick though.
(KDE 4.8.2)
André Madureira (andreluizromano) wrote : | #2 |
I recently found out what is causing the problem (so, we can now use a workaround until the fix be available)...
The problem happens in NTFS-3G program (when mount NTFS filesystem)... It seems that when Nautilus or Dolphin try to mount a partition (as the user clicks in the partition icon), HAL calls MOUNT.NTFS (that is linked to NTFS-3G) with the options RW,UID=
So I verified every options listed to exactly identify which one is causing of the problem...
It seams that when a partition is mounted by NTFS-3G without the options UID=,GID=,UMASK=077 (or FMASK=177,
For me this don't make sense, because if I use the option UMASK=000 (that is more permissive than UMASK=077), the trash folder is not created (this don't make sense)...
Therefore, I think this problem is a BUG and shall be solved as soon as possible, since it limitates the user preferences related to UMASK...
PS: The UID and GID options are exclusive necessary to the correct opening of the files inside the folder... Without this option, the trash folder is created, but the user cannot access the files inside the mounted point (mounted partition, etc)... What do cause the trash problem is the UMASK option (or FMASK together with DMASK)...
This problem may be associated with other filesystems as well as NTFS-3G, because it seams (I did not test the problem with other filesystems, because I only work with EXT4 and NTFS filesystems) that the creation of the trash folder is done by another program inside LINUX that works both inside KDE and GNOME (so, it's an independent program that works with Nautilus and Dolphin)... Therefore, the filesystems that have the options UMASK,FMASK,DMASK may be affected by this bug...
I hope I could help,
André M.
no longer affects: | kubuntu-kde4-meta (Ubuntu) |
In KDE Bug Tracking System #76380, André Madureira (andreluizromano) wrote : | #34 |
I recently found out what is causing the problem (tested in NTFS-3G filesystems) (so, we can now use a workaround until the fix be available)...
The problem happens in NTFS-3G program (when mount NTFS filesystem)... It seems that when Nautilus or Dolphin try to mount a partition (as the user clicks in the partition icon), HAL calls MOUNT.NTFS (that is linked to NTFS-3G) with the options RW,UID=
So I verified every options listed to exactly identify which one is causing of the problem...
It seams that when a partition is mounted by NTFS-3G without the options UID=,GID=,UMASK=077 (or FMASK=177,
For me this don't make sense, because if I use the option UMASK=000 (that is more permissive than UMASK=077), the trash folder is not created (this don't make sense)...
Therefore, I think this problem is a BUG and shall be solved as soon as possible, since it limitates the user preferences related to UMASK...
PS: The UID and GID options are exclusive necessary to the correct opening of the files inside the folder... Without this option, the trash folder is created, but the user cannot access the files inside the mounted point (mounted partition, etc)... What do cause the trash problem is the UMASK option (or FMASK together with DMASK)...
This problem may be associated with other filesystems as well as NTFS-3G, because it seams (I did not test the problem with other filesystems, because I only work with EXT4 and NTFS filesystems) that the creation of the trash folder is done by another program inside LINUX that works both inside KDE and GNOME (so, it's an independent program that works with Nautilus and Dolphin)... Therefore, the filesystems that have the options UMASK,FMASK,DMASK may be affected by this bug...
I hope I could help,
André M.
In KDE Bug Tracking System #76380, André Madureira (andreluizromano) wrote : | #35 |
WORKAROUND (for NTFS-3G filesystem mount procedure):
Use options UID=USERID, GID=USERGROUPID, FMASK=177, DMASK=077 (or use the options UID=USERID, GID=USERGROUPID, UMASK=077)
This may "solve" the problem for NTFS partitions mounted by NTFS-3G program...
PS: This works well with the command line MOUNT.NTFS and the command NTFS-3G... This also works with FSTAB (/etc/fstab) for auto mounting partitions...
I hope I could help,
André M.
In KDE Bug Tracking System #76380, L22087 (l22087) wrote : | #36 |
Thank you André! It was a relief to fix this.
In KDE Bug Tracking System #76380, tnttrx (trx-lists) wrote : | #37 |
still present with NFS:
gentoo built kde-4.9.2
In KDE Bug Tracking System #76380, Jsvrp-gw (jsvrp-gw) wrote : | #38 |
Still present in KDE 4.9.5 for local mounts. I have a local partition on /data, but all deleted files goes to my /home trash.
I really don't understand why KDE doesn't follow the opendesktop specs. GNOME does.
In KDE Bug Tracking System #76380, David Faure (faure) wrote : | #39 |
KDE does follow the spec. See comment #7 (or the spec) for more details about setting up a trash dir on /data.
In KDE Bug Tracking System #76380, Jsvrp-gw (jsvrp-gw) wrote : | #40 |
Actually I created exactly the .Trash directory in the topdir of the /data partition:
drwxrwxrwt 2 root root 4096 jan 13 00:01 .Trash
But still it doesn't work. Even if I created a 1000 directory as the user or a .Trash-1000 with the right user permissions. Still the home-trash is used.
In KDE Bug Tracking System #76380, Jsvrp-gw (jsvrp-gw) wrote : | #41 |
Now it worked. After a reboot. Although I rebooted before. Probably another problem right then.
In KDE Bug Tracking System #76380, Jsvrp-gw (jsvrp-gw) wrote : | #42 |
But it would be still a good idea if KDE could create a .Trash folder as root with a sticky bit, when a user wants to trash an item in a non-home partition. Maybe it should just ask the user what to do, like this:
- Do you want to use the trash on this partition (faster, but root password required once)?
- Do you want to use the trash on your home partition for this partition (slower)?
- Do you want to disable trash for this partition (faster, but deleted files cannot be restored)?
In KDE Bug Tracking System #76380, Luke-jr+kdebugs (luke-jr+kdebugs) wrote : | #43 |
If a user can delete/move a file, they can always write to the directory containing it (AFAIK), so could make a trash in that directory, if not the partition root. Then KDE just needs to remember the new trash directory.
There's also a possibility of a setuid trash maker
In KDE Bug Tracking System #76380, zang3tsu (klangga) wrote : | #44 |
This still happens with KDE 4.10 on Gentoo using a CIFS mount. The Trash-1000 folder is auto-created on CIFS mount however the trashed file is still moved to ~/.local/
In KDE Bug Tracking System #76380, Sglway (sglway) wrote : | #45 |
I can't believe this bug has 9 years and still going... Dolphin/Konqueror insist in moving deleted files to /home/user/
But my OS is installed on a 30GB SSD, and I store all my files (small and big) on a Freenas NAS with ZFS. I have used several distributions and several file managers and ALL them use $topdir/
In KDE Bug Tracking System #76380, DA (adawit) wrote : | #46 |
To comment #41 and comment #42 reporters: your problem is more like bug# 177023. If you can provide the information requested in comment #11 of that bug report, perhaps your issues would be resolved...
In KDE Bug Tracking System #76380, Crgridley-b (crgridley-b) wrote : | #47 |
This affects my ZFS volume too. Took me a bit to figure out why deletes were so slow :-)
In KDE Bug Tracking System #76380, Crgridley-b (crgridley-b) wrote : | #48 |
To elaborate; '.Trash-1000' is created, with the correct subfolders, but never used, and data is instead copied to my home directory.
I have tried adding the sticky bit as well as manually creating the folders instead, but the data is always copied.
Now, since the partition in question is storing my media files havig several GB of data flying to my SSD home directory is sub-optimal :-)
In KDE Bug Tracking System #76380, Crim Soukyuu (chrno-sphered) wrote : | #49 |
This also affects sshfs and cifs for me. Noticed it with dolphin, but konqueror behaves the same.
Details: https:/
I'd rather not have huge files moved to "Trash" on my SSD.
In KDE Bug Tracking System #76380, Crim Soukyuu (chrno-sphered) wrote : | #50 |
Seems to affect ntfs volumes as well, maybe it's FUSE-related?
In KDE Bug Tracking System #76380, Frank78ac (frank78ac) wrote : | #51 |
*** Bug 347384 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Audvare (audvare) wrote : | #52 |
I would prefer for some reason the Windows behaviour here. When you have a remote mount point (a remote drive), it just ignores the 'Recycle Bin' entirely. This may seem counterintuitive but I am used to it and I prefer not to have random .Trash-xxxx directories on my remote mounts (nor on my flash drives!)
In KDE Bug Tracking System #76380, Crim Soukyuu (chrno-sphered) wrote : | #53 |
I would definitely prefer no trash on unsupported locations (Move to trash = delete) over it moving stuff to my local SSD partition. Especially when deleting big files.
It's most annoying when there IS a trash folder created with correct permissions and all, but not used for some weird reason.
In KDE Bug Tracking System #76380, kalapacengkir (kalapacengkir) wrote : | #54 |
Bug still happening on Dolphin v15.04.0.
Deleted items (Move to Trash) files, no matter from which partition, they always ended up in ~/.local/
Therefore deleting big files (like *.iso) would take a long time because actually it moes files to home partition.
I expect Dolphin should not insist the Trash location in ~/.local/
FYI, I've tried other file managers (Thunar, Nautilus/Nemo/Caja, PCmanFM, Double Commander), no similar problem happened.
In KDE Bug Tracking System #76380, Cacciatoredisirene (cacciatoredisirene) wrote : | #55 |
Bug is still present in latest version of kde.
When recycling across partitions and different hdds, all files are moved into local trash.
In KDE Bug Tracking System #76380, Katonag (katonag) wrote : | #56 |
Using Opensuse Tumbleweed with Plasma 5.8.4, Frameworks 5.29.0 the bug is still present. And quite annoying.
In KDE Bug Tracking System #76380, Katonag (katonag) wrote : | #57 |
(In reply to andreluizromano from comment #32)
> WORKAROUND (for NTFS-3G filesystem mount procedure):
>
> Use options UID=USERID, GID=USERGROUPID, FMASK=177, DMASK=077 (or use the
> options UID=USERID, GID=USERGROUPID, UMASK=077)
>
How can I set this as default mount option with KDE device notifier for ALL devices?
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #58 |
*** Bug 357041 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #59 |
*** Bug 352803 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #60 |
*** Bug 320986 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Fabio0x (fabio0x) wrote : | #61 |
Still present in 5.13 with Solus distro. This behavior is pointless and definitely unwanted.
In KDE Bug Tracking System #76380, Fikri Muhammad Iqbal (gamer-fikri) wrote : | #62 |
tl;dr
change fstab to defaults,
Apparently I believe this is not a bug, but inteded behaviour ?
For some people who stumble upon on ntfs-3g filesystem and in my case, dolphin, doesn't seem to use the "intended" .Trash / .Trash-1000 partition, and after looking at journalctl, I see something
`Nov 11 23:13:15 ruby kdeinit5[23435]: kf5.kio.trash: Root trash dir "/mnt/Master/
and looking at the error in google doesn't get me anywhere rather then other logfile, but it also has the source code, this is where i get it
https:/
and according to that the .Trash and .Trash-1000 have some specification (differ on both), but generally
- it should be owned (.Trash-1000) or writeable by user (.Trash)
- it should be a dir
- its not a symlink
- it should have permission of 700 (.Trash-1000) OR have sticky bit (.Trash)
the last thing is probably constraining dolphin so it cant use the folder, and to my knowledge, we cant chmod the mounted fstab ntfs folder (?), so at least the workaround for now is to have permission of 700 on fstab.
I dont know why there's a little of this "error" in google, it seems today many people have dual drive like me with SSD main and data in HDD, and they didnt have the problem ? or is it just "us" with some special case ?
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #63 |
*** Bug 403572 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #64 |
*** Bug 148454 has been marked as a duplicate of this bug. ***
lencho (lencho) wrote : | #65 |
Hello,
I'm new to KDE and learning to get use to its particularities but for weeks I wondered why my home partition was getting full and why it took such a long time putting big files in the trash, whereas it had always been instant on any other OS / DE I ever used.
I seriously thought there was something wrong with my installation or there was a bug or something.
Then I found this thread and I'm falling off my chair.
This is actually expected? I see the logic, but it is so confusing and so unexpected from a user's perspective, it really seems strange to me.
How can the user be aware that deleting a file will have a different behaviour depending on where the file is? OK, there are specs, but not all users will read the specs before using a desktop environment.
I would be totally OK if in case of lack of "support" for a "local trash", a warning would tell me the file would be removed directly. But expecting the user to guess that is really not user-friendly.
This said, of course I would love to see it work on the various drives I have to use, and wondered if there was a solution for NTFS and exFAT systems.
And I can't help but wonder why is it not working with KDE and just working without issue on other desktop environments in the same conditions? (just tried a Debian with Cinnamon I have lying around and a deleted file on an external exFAT drive is put in the .Trash-1000 folder of the drive, no questions asked - same drive plugged into Manjaro KDE puts the deleted file in my home trash)
Thanks very much in advance for considering this issue and this user feedback.
In KDE Bug Tracking System #76380, Danlemnaru (danlemnaru) wrote : | #66 |
I took a look at the Freedestop specifications. I'm sorry David (Faure), but there's something in KDE code that isn't right.
To quote the freedesktop specifications for Trash, regarding the .Trash-userid folder:
https:/
"(2) If an $topdir/.Trash directory is absent, an $topdir/.Trash-$uid directory is to be used as the user's trash directory for this device/partition. $uid is the user's numeric identifier.
The following paragraph applies ONLY to the case when the implementation supports trashing in the top directory, and a $topdir/.Trash does not exist or has not passed the checks:
When trashing a file, if an $topdir/.Trash-$uid directory does not exist, the implementation MUST immediately create it, without any warnings or delays for the user.
When trashing a file, if this directory does not exist for the current user, the implementation MUST immediately create it, without any warnings or delays for the user."
There is no requirement there about certain restrictive folder permissions when it comes to .Trash-uid folders (unlike the .Trash), there is only an underlining of the immediacy of creating the necessary folder. Other DEs simply ensure that the folder will be fit to write into. That's it.
Your implementation is just stricter than necessary. I did a comparison with Gnome's approach.
See Gnome's relevant code here: https:/
And here's KDE's (thanks Fikri Muhammad Iqbal): https:/
While Gnome does try to make the folder 0700, they will still use it as long as the uid is correct as they will be able to write into the folder, being aware that for a FAT partition for example, permissions will not work. Even if you are particularly sensitive about the security implications of such a trash folder, you must admit that no major issue has arisen in more than 10 years since other DEs have implemented it.
I think this really should be moving forward after 10 years. If one searches online, there are many instances of users complaining about this issue, and trying to find some kind of workaround. Some use /etc/fstab, others stick to a straight delete policy (no moving to trash), which obviously is not ideal.
Keep in mind that most USB sticks and external HDDs, and even internal data disks/partitions will use windows compatible file systems by default. And many users will keep them that way because they dual boot or also use them with Windows systems. Copying every deleted file from "data" to their /home Trash is just the wrong approach, of which the freedesktop specifications seem well aware. Many will have hundreds of GBs of data, but limited size SSDs for their OS. An eventual HDD cleanup of old data will burn through their SSD writes, take ages to complete, and eventually result in "/" being filled, with possible stability consequences, because not everybody uses a separate /home partition.
In the mean time, for anyone bumping into this bug report, some workaround tips, based on what was said by others above (the instructions do assum...
In KDE Bug Tracking System #76380, H-login (h-login) wrote : | #67 |
Hi, I have the same experience and I've only recently experienced it because another kio change introduced in 20.04 caused me to change the way I mount Windows shares. That's why I'm 16 years late to this issue!
/media/
//windowspc/
/media/
drwx------ 2 user user 0 Jul 15 18:52 .Trash-1000
ls -alr .Trash-1000/
total 640
drwx------ 2 user user 0 Jul 24 06:42 info
drwx------ 2 user user 0 Jul 24 06:42 files
drwx------ 2 user user 655360 Jul 24 06:36 ..
drwx------ 2 user user 0 Jul 15 18:52 .
If I delete a file from /media/
The expected behaviour is for the file to be moved to /media/
I've tried using a folder called .Trash on /media/
I've tried manually adding an entry for /media/
I can't see any errors or messages about .Trash, Trash or trash in KSystemlog or any files in /var/log.
My versions:
Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-42-generic
OS Type: 64-bit
In KDE Bug Tracking System #76380, clel (clel) wrote : | #68 |
Just wanted to mention that this was one reason why I stopped using KDE after testing it a few years ago. Having an external HDD with many movie files of which I delete some regularly makes this a pretty bad experience.
In KDE Bug Tracking System #76380, clel (clel) wrote : | #69 |
*** Bug 391656 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #70 |
Claudius, maybe you can help us resolve this once and for all.
I admit I don't fully understand why problem is still happening for some people, but there appears to be a well-understood set of conditions under which this *does* work as folks expect.
Is the problem that these conditions are not present by default for all newly mounted volumes? Or only some? And the conditions themselves unnecessary specific and could be broadened, or do we need to work harder at mounting things in a way that satisfies those conditions?
In KDE Bug Tracking System #76380, clel (clel) wrote : | #71 |
(In reply to Nate Graham from comment #66)
> Claudius, maybe you can help us resolve this once and for all.
>
> I admit I don't fully understand why problem is still happening for some
> people, but there appears to be a well-understood set of conditions under
> which this *does* work as folks expect.
>
> Is the problem that these conditions are not present by default for all
> newly mounted volumes? Or only some? And the conditions themselves
> unnecessary specific and could be broadened, or do we need to work harder at
> mounting things in a way that satisfies those conditions?
I'd be glad if this could see some progress :)
I just skimmed through the comments again. My current understanding of the cause of the problem is the following:
According to comment #62 and https:/
Mounting with dmask or umask 077 is from my understanding equal to setting the whole drive's permissions to 0700, thus the "security check" passes for drives mounted that way.
So in order to fix this, I guess, we have to possible targets to modify. Either one could probably discuss mounting all drives with those options (which might lead to unwanted side effects), I don't know why the drives are currently mounted the way they are; or one could overthink that "security check". From my POV, I'd vote to pursue the latter option first. Maybe one can come up with some check that is "secure enough".
I'd really like to involve David Faure, if he is still involved into the development or the current maintainer of this project. There has been some discussion going on in this issue about the freedesktop spec which from David's view might be violated by this, but other replied here that this wouldn't be the case.
Also hopefully the other participants of this issue with competence in this region can support.
---
As a side note: I experienced this issue some days ago on a FAT32 USB stick, so that file system seems to also be still affected.
In KDE Bug Tracking System #76380, clel (clel) wrote : | #72 |
(In reply to David Faure from comment #7)
> Unless you can create a $topdir/.Trash/$uid (where .Trash was
> created by root), or you have a user-writable $topdir so that
> $topdir/.Trash-$uid can be autocreated, there is no other way to trash into
> the same partition. When that is the case (and yes, this is the most common
> case since mountpoints are usually not user-writable and admins don't create
> a .Trash subdir), then we have two choices:
> - trashing to $HOME, so that you can restore trashed items, as expected.
> - disabling trashing and only offering real deletion. Faster, but no going
> back.
>
> Gnome does the latter AFAIK, while I chose the former. I think it's better
> to offer a solution that doesn't lose data, even if it's a bit slower, than
> going for the fast-and-dangerous solution.
>
> I'm closing this bug; please read the trash spec for more details about
> $topdir/.Trash and $topdir/.Trash-$uid if necessary, to set one of them up
> in order to make it possible to trash on the same dir.
Reading this again and the spec it refers to (https:/
In KDE Bug Tracking System #76380, clel (clel) wrote : | #73 |
*** Bug 248222 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, clel (clel) wrote : | #74 |
One last remark for now: Reading the umask article on Wikipedia (https:/
I don't really have a save testing environment and am also a bit time constrained. Nate (or somebody else), if you can reproduce the general problem, could you maybe check if it still occurs with a kio version without that check?
In KDE Bug Tracking System #76380, clel (clel) wrote : | #75 |
*** Bug 188032 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, clel (clel) wrote : | #76 |
*** Bug 208606 has been marked as a duplicate of this bug. ***
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #77 |
Thanks, I will follow up and also see if I can wrangle in David Faure. :)
In KDE Bug Tracking System #76380, David Faure (faure) wrote : | #78 |
Ouch, sorry for not seeing this bug report.
My code tries to be too secure? That's a new one :-)
Interestingly USB-key-with-VFAT was the reason for the 0700 check according to very old git commits; but I guess that was because I tested with a 0700 mount option, maybe. That was in 2005, can't remember.
Indeed the spec has no such checks, let's remove that.
In KDE Bug Tracking System #76380, Bug-janitor (bug-janitor) wrote : | #79 |
A possibly relevant merge request was started @ https:/
Changed in kdelibs: | |
status: | Confirmed → In Progress |
In KDE Bug Tracking System #76380, Danlemnaru (danlemnaru) wrote : | #80 |
(In reply to David Faure from comment #74)
> Indeed the spec has no such checks, let's remove that.
That's wonderful news David! I'm looking forward to seeing Plasma based distros with Trash behaving as expected! Thank you!
In KDE Bug Tracking System #76380, A-samirh78 (a-samirh78) wrote : | #81 |
Git commit 03bcb3d3ff89074
Committed on 26/09/2020 at 13:34.
Pushed by ahmadsamir into branch 'master'.
kio_trash: remove unnecessarily strict permission check
Tested with `chmod 0770 /d/.Trash-1000` (where /d is a mount point),
kio_trash complained about security checks before this commit,
and works with it.
Also tested with a USB key which ends up mounted as
type vfat (rw,nosuid,
it complained about a "strange filesystem", and while this is still true :),
the removal of the code in TrashImpl:
the trash dir on the USB key usable.
FIXED-IN: 5.74
M +4 -21 src/ioslaves/
https:/
In KDE Bug Tracking System #76380, clel (clel) wrote : | #82 |
Thanks for fixing this to all people involved!
That really means a lot to me, this one has really annoyed me for some time.
Changed in kdelibs: | |
status: | In Progress → Fix Released |
In KDE Bug Tracking System #76380, Strangiato Xanadu (strangiato) wrote : | #83 |
Does this fix only affect external disks?
I can confirm that the bug is fixed with external disks on neon unstable,
but Dolphin is still sending files deleted from my internal ntfs partition to
/home/myusernam
In KDE Bug Tracking System #76380, clel (clel) wrote : | #84 |
Interesting. I have not tested on internal drives before. Maybe they require a different approach.
In KDE Bug Tracking System #76380, Eleanorhawk (eleanorhawk) wrote : | #85 |
I'm still having this issue on an ecryptfs mount point. I notice that KIO/Dolphin does create the d/.Trash-1000 directory but still moves the files to ~/.local/Trash (notably, this decrypts the files)
KDE Framework v 5.80.0
In KDE Bug Tracking System #76380, Mehanoid-ru (mehanoid-ru) wrote : | #86 |
The problem is reproducible on Arch Linux for a drive with BTRFS inside LUKS mounted at /mnt/hdd
Dolphin moves files from another drive to ~/.local/Trash
Everything works correctly when using trash-cli, files are moved to /mnt/hdd/
I can't say at what point it broke, but as far as I remember, on a previous laptop with a similar drives configuration, but without LUKS on the additional disk, everything worked. Perhaps the problem is with LUKS, but there could be something else.
Software versions:
Plasma v5.23.1
KDE Framework v5.87.0
In KDE Bug Tracking System #76380, A-samirh78 (a-samirh78) wrote : | #87 |
Bind mounts should be fixed by: https:/
In KDE Bug Tracking System #76380, Andrew Travneff (travneff) wrote : | #88 |
(In reply to Oleg Grigorev from comment #82)
> I can't say at what point it broke, but as far as I remember, on a previous
> laptop with a similar drives configuration, but without LUKS on the
> additional disk, everything worked. Perhaps the problem is with LUKS, but
> there could be something else.
Seems like I have a reversed case.
Is there any option / workaround to disable cross-partition moving for all trash operations?
Files deleted by Dolphin are moved from tmpfs to LUKS partition on SSD:
$ pwd
/tmp
$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,
$ ls ~/.local/
ls: cannot access '/home/
$ touch testdel
$ dolphin # delete `testdel` file to trash in Dolphin
$ ls ~/.local/
/home/
SW versions:
kde-baseapps-
kde-runtime-
kde-workspace-
kdelibs-
kf5-plasma-
plasma-
In KDE Bug Tracking System #76380, Calvinatorzcraft (calvinatorzcraft) wrote : | #89 |
(In reply to Oleg Grigorev from comment #82)
> The problem is reproducible on Arch Linux for a drive with BTRFS inside LUKS
> mounted at /mnt/hdd
> Dolphin moves files from another drive to ~/.local/Trash
> Everything works correctly when using trash-cli, files are moved to
> /mnt/hdd/
> I can't say at what point it broke, but as far as I remember, on a previous
> laptop with a similar drives configuration, but without LUKS on the
> additional disk, everything worked. Perhaps the problem is with LUKS, but
> there could be something else.
>
> Software versions:
> Plasma v5.23.1
> KDE Framework v5.87.0
have pretty much the exact same problem with an arch btrfs system on latest everything
In KDE Bug Tracking System #76380, Lcatinaud (lcatinaud) wrote : | #90 |
> have pretty much the exact same problem with an arch btrfs system on latest
> everything
So do I. Exact same problem on a BTRFS system, move to trash from USB exFAT disk is very slow because compression is set on /, but moving to trash on an USB drive should stay on the removable media, not use the main partition.
I don't know if the problem is due to Dolphin or kde framework. Using another file manager (ie Dolphin) results in an immediate trashing.
Whatever, this bug cannot be considered as resolved or ther's been a regression :(
In KDE Bug Tracking System #76380, Lcatinaud (lcatinaud) wrote : | #91 |
(In reply to Laurent from comment #86)
> I don't know if the problem is due to Dolphin or kde framework. Using
> another file manager (ie Dolphin) results in an immediate trashing.
>
Definitely not dolphin, but KDE framework : got the same result with krusader file manager.
Changed in kdelibs: | |
status: | Fix Released → Confirmed |
In KDE Bug Tracking System #76380, Nate-b (nate-b) wrote : | #92 |
Issues with Btrfs specifically are Bug 395023. Let's continue there.
Changed in kdelibs: | |
status: | Confirmed → Fix Released |
Version: (using KDE KDE 3.2.0)
Installed from: Gentoo Packages
When deleting (to trash) from ~/hdh1/ path/to/ file, KDE tries to actually move the file to my primary home partition. This is pointless, though I'm not sure how it should be handled. I hear GNOME does this properly and Mac OS X probably does too.