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.
CVS commit by faure: Implemented "trashing-in-same-partition" ($topdir/.Trash/$uid where .Trash was created by root, or $topdir/.Trash-$uid if the user can create it, as per the XDG trash specification) CCMAIL: 76380-done@bugs.kde.org, 56821-done@bugs.kde.org M +1 -0 trash.protocol 1.5 M +136 -18 trashimpl.cpp 1.20 M +8 -4 trashimpl.h 1.14
Bug closed. Kdesktop is no more mantained.
This bug is KDE-wide, not just KDesktop anyway. Still holds true for KDE 4.1.
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)
Looks like a trigger-happy script closing everything KDesktop-related. Presumably this bug is in the trash KIO thing.
Moved to kio/trash.
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.
Or you could rename /mnt/foo/bar/baz to /mnt/foo/bar/.trashed_baz and index it all somewhere in $HOME Obviously you can always write to the directory you're trashing from.
Good idea, but this is not how the trash spec works. http://www.freedesktop.org/wiki/Specifications/trash-spec If you want to push for a change in the spec, the mailing-list to discuss it is xdg@freedesktop.org (http://lists.freedesktop.org/mailman/listinfo/xdg).
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/disk/.Trash/1000/files/foo.bar and a description is created /media/disk/.Trash/1000/info/foo.bar.trashinfo 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/.local/share/Trash Ideally it should ask the user what to do if it refuses to use $topdir/.Trash (Delete or $HOME?)
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...
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.
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/share/Trash 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/share/Trash This also applies to NFS4 mounts, since there are always multiple remounts from the main NFS4 mount point.
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/some-mount/.Trash file ended in /home/myuser/.local/share/Trash 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/share/Trash, too. 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/share/Trash was recreated (I've deleted it before the experiment). Owner was my user and permissions were drwx------. It had two subdirs ("info" and "files") and one file in it - "metadata". Subdir "files" had "readme.txt" file in it, and subdir "info" had "readme.txt.trashinfo" file in it. 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/share/Trash/files Both of these kinds of trashing behaviour should be considered as a bug.
(In reply to comment #14) just to add link to related mailing list thread: http://lists.kde.org/?t=128370856900010&r=1&w=2
I can confirm that situation is the same with KDE 4.5.1 built by Gentoo.
This still happens with kde 4.5.4 compiled from source.
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?
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.
(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.
KDE 4.7.3, this seems like fixed to me. Can I close this?
*** Bug 100669 has been marked as a duplicate of this bug. ***
*** Bug 213037 has been marked as a duplicate of this bug. ***
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/.local/share/Trash, just like expected. deleting file from /home/user/nfs dir makes /home/user/nfs/.Trash-1000 folder with 'files' and 'info' subfolders owned by my user (no permission conflicts), but puts the file in /home/user/.local/share/Trash instead of newly-created /home/user/nfs/.Trash-1000 :( so far, no good.
(In reply to comment #24) > unfortunately, this is still present for me: > gentoo built kde-4.7.3 I can reproduce as described, reopening.
*** Bug 258720 has been marked as a duplicate of this bug. ***
works ok in 4.7.4
have you also tested it with NFS mount points?
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,nodev,user,nosuid,async" On the "data" partition that i have. I cannot test this on NFS though..
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)
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=USERNUMBER,GID=USERNUMBERGROUP,FMASK=177,DMASK=077... 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,DMASK=077), the system cannot create the path .TRASH-UID as well as the files inside it (the trashed files)... 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.
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.
Thank you André! It was a relief to fix this.
still present with NFS: gentoo built kde-4.9.2
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.
KDE does follow the spec. See comment #7 (or the spec) for more details about setting up a trash dir on /data.
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.
Now it worked. After a reboot. Although I rebooted before. Probably another problem right then.
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)?
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
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/share/Trash/. User also has full read/write access on the CIFS mount.
I can't believe this bug has 9 years and still going... Dolphin/Konqueror insist in moving deleted files to /home/user/.local/share/Trash instead of deleting to $topdir/.Trash/$uid. I am using Debian Wheezy and KDE 4.8.4. I have no problems when using an USB flash drive, it correctly creates a .Trash-1000 folder and moves deleted files there. 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/.Trash-$uid. Even with a fresh installation, when I mount my NFS shares the trash icon on the desktop changes to the "full" icon. Nautilus, PCmanFM, Thunar, even xfe handle the trash thing beautifully.
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...
This affects my ZFS volume too. Took me a bit to figure out why deletes were so slow :-)
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 :-)
This also affects sshfs and cifs for me. Noticed it with dolphin, but konqueror behaves the same. Details: https://forum.kde.org/viewtopic.php?f=224&t=125486 I'd rather not have huge files moved to "Trash" on my SSD.
Seems to affect ntfs volumes as well, maybe it's FUSE-related?
*** Bug 347384 has been marked as a duplicate of this bug. ***
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!)
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.
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/share/Trash/. 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/share/Trash/. The location should be made at top location of partition where the files to-be-deleted existed. So, it would be a matter of moving file between folder in the same partition. FYI, I've tried other file managers (Thunar, Nautilus/Nemo/Caja, PCmanFM, Double Commander), no similar problem happened.
Bug is still present in latest version of kde. When recycling across partitions and different hdds, all files are moved into local trash.
Using Opensuse Tumbleweed with Plasma 5.8.4, Frameworks 5.29.0 the bug is still present. And quite annoying.
(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?
*** Bug 357041 has been marked as a duplicate of this bug. ***
*** Bug 352803 has been marked as a duplicate of this bug. ***
*** Bug 320986 has been marked as a duplicate of this bug. ***
Still present in 5.13 with Solus distro. This behavior is pointless and definitely unwanted.
tl;dr change fstab to defaults,uid=1000,umask=077 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/.Trash" exists but didn't pass the security checks, can't use it` 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://code.woboq.org/qt5/kf5/kio/src/ioslaves/trash/trashimpl.cpp.html#1185 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 ?
*** Bug 403572 has been marked as a duplicate of this bug. ***
*** Bug 148454 has been marked as a duplicate of this bug. ***
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://specifications.freedesktop.org/trash-spec/trashspec-latest.html "(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://gitlab.gnome.org/GNOME/glib/blob/glib-2-56/gio/glocalfile.c#L2083 And here's KDE's (thanks Fikri Muhammad Iqbal): https://code.woboq.org/qt5/kf5/kio/src/ioslaves/trash/trashimpl.cpp.html#1190 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 assume you're using a Debian/Ubuntu based distro, unfortunately): I. Using the terminal: sudo nano /etc/fstab Then add something like this to the file (edited of course to fit your particular system, so you will need the Label or the UUID of your partition) LABEL=LG /mnt/LG auto nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=1000,umask=077,noauto 0 0 or UUID=cea8b9a9-9fd9-4e38-842c-57b9bdbdffdc /mnt/LG auto nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=1000,umask=077,noauto 0 0 Then press Ctrl-o - to save the file Enter - to confirm the file name Ctrl-x - to exit the editing session For those not familiar with the terminal, there's GNOME Disks. sudo apt install gnome-disk-utility Once installed, look for the "Disks" app. Find the partition you need to operate on, click on the button that says "Additional Partition Options" when you hover over it, disable "User Session defaults" then add "uid=1000,gid=1000,umask=077,noauto" to the mount options.
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/user/sharename is a Windows share mounted using the following /etc/fstab entry: //windowspc/sharename /media/user/sharename cifs dir_mode=0700,file_mode=0700,uid=1000,credentials=/home/user/smbpwd,noauto,user 0 0 /media/user/sharename contains a folder called .Trash-1000 (my uid is 1000): 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/user/sharename using Dolphin the file is copied across the network from the network share to ~/.local/share/Trash/ on my local drive. The expected behaviour is for the file to be moved to /media/user/sharename/.Trash-1000/files. I've tried using a folder called .Trash on /media/user/sharename but that didn't work either. I've tried manually adding an entry for /media/user/sharename/.Trash-1000 to ~/config/trashrc without success. 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
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.
*** Bug 391656 has been marked as a duplicate of this bug. ***
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 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://code.woboq.org/qt5/kf5/kio/src/ioslaves/trash/trashimpl.cpp.html#1190 there seem to be a check of permissions for the trash folder. This check seems to be there for security concerns. From my understanding it is checked whether only (!) the user can access the files in that folder (meaning access rights of the trash folder set to 0700). This seems to be checked out of security reasons (probably to make sure trashing sensitive files will not expose them suddenly), while it can be debated whether this is necessary. 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 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://specifications.freedesktop.org/trash-spec/trashspec-latest.html) I am wondering what is the case currently. It might have been the case back then (when the comment was written) that the $topdir was not user-writable and $topdir/.Trash-$uid could not be created. In that case of course there would have been a problem since there would be no trash folder on the drive to trash files to. However, I read users here stating the in fact the $topdir/.Trash-$uid dir seems to have been created for them, but afterwards the files still got moved to the "root drive" trash. So I assume that at least now (don't know about the situation back then), we are actually rather facing the problem that a security check is blocking the trashing. Since the spec does not seem to talk about security or permissions in this context. So from the spec side it should be ok to change the relevant code.
*** Bug 248222 has been marked as a duplicate of this bug. ***
One last remark for now: Reading the umask article on Wikipedia (https://en.wikipedia.org/wiki/Umask#Mask_effect) it acts as some kind of filter after the normal permissions. Assuming dmask is behaving in a similar way, that would mean that dmask=077 actually filters out broader set permissions only leaving permissions for the user intact. If this actually makes trashing work in the expected way this is a strong indicator that permissions set to broadly are currently the reason preventing the expected behaviour. So probably the check whether the permissions are set to 0700 is to blame (https://code.woboq.org/qt5/kf5/kio/src/ioslaves/trash/trashimpl.cpp.html#1190). 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?
*** Bug 188032 has been marked as a duplicate of this bug. ***
*** Bug 208606 has been marked as a duplicate of this bug. ***
Thanks, I will follow up and also see if I can wrangle in David Faure. :)
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.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/125
(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!
Git commit 03bcb3d3ff89074a68839b6ebeb8030ef0ee4fd1 by Ahmad Samir, on behalf of David Faure. 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,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2). After kio_trash creates .Trash-1000 it complained about a "strange filesystem", and while this is still true :), the removal of the code in TrashImpl::initTrashDirectory makes the trash dir on the USB key usable. FIXED-IN: 5.74 M +4 -21 src/ioslaves/trash/trashimpl.cpp https://invent.kde.org/frameworks/kio/commit/03bcb3d3ff89074a68839b6ebeb8030ef0ee4fd1
Thanks for fixing this to all people involved! That really means a lot to me, this one has really annoyed me for some time.
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/myusername/.local/share/Trash/
Interesting. I have not tested on internal drives before. Maybe they require a different approach.
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
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/.Trash-1000 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
Bind mounts should be fixed by: https://invent.kde.org/frameworks/kio/-/merge_requests/550
(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,nodev,seclabel,size=32563000k,nr_inodes=1048576,inode64) $ ls ~/.local/share/Trash/files/testdel ls: cannot access '/home/andrew/.local/share/Trash/files/testdel': No such file or directory $ touch testdel $ dolphin # delete `testdel` file to trash in Dolphin $ ls ~/.local/share/Trash/files/testdel /home/andrew/.local/share/Trash/files/testdel SW versions: kde-baseapps-common-16.12.2-14.fc38.noarch kde-runtime-libs-17.08.3-26.fc38.x86_64 kde-workspace-common-4.11.22-37.fc38.noarch kdelibs-4.14.38-37.fc38.x86_64 kf5-plasma-5.105.0-1.fc38.x86_64 plasma-workspace-libs-5.27.4.1-2.fc38.x86_64
(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/.Trash-1000 > 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
> 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 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.
Issues with Btrfs specifically are Bug 395023. Let's continue there.