SUMMARY When from dolphin I delete files located on devices other than rootfs, they are always moved to my trash can in ~/.local/share/Trash. This happens whether it is a disk in fstab mounted on mnt, a temporary one on media, or a virtual one in user. STEPS TO REPRODUCE 1. From dolphin, right click, delete. OBSERVED RESULT The files are moved to the trash on my system. EXPECTED RESULT The deleted content is moved to (external)/.Trash-1000; the folder is created if it does not exist. SOFTWARE/OS VERSIONS Linux: 6.9.2-arch1-1 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION It happens also in new clean users. I can reproduce it 100% of the time. Of course I have write permissions.
Please provide more comprehensive STEPS TO REPRODUCE. Thanks.
(In reply to Harald Sitter from comment #1) > Please provide more comprehensive STEPS TO REPRODUCE. Thanks. That will be a problem, those are all I need and know how to reproduce it, so I'm not sure what I should provide :-S I hope this video helps to rule some things out. It is made with a new user and a freshly formatted disk. https://mega.nz/file/DZEiARSZ#j1pGLuz3_MGDksjhZdUqC-kHpBXghdLwwUHyJIwtNHY I was also able to replicate it in virtualbox (with defaults of EndeavourOS_Gemini-2024.04.20.iso).
Please get the output of `cat /proc/self/mountinfo` then create a file on the drive and get the output of `stat "pathOfFile"` where pathOfFile needs to be the actual path to your file /run/media/ABC/File.txt or something. I have a suspicion that your filesystem may be having trouble holding a stable identifier (st_dev) so we don't manage to resolve that this is a mountpoint and fall back to the $HOME location. If that is so I am not sure we can do much about this, we are pretty much at the mercy of information coming out of the kernel here.
(In reply to Harald Sitter from comment #3) Thank you. Since I used btrfs in all cases, I just tried formatting the external drive in ext4 and now the trash works correctly; if I reformat it in btrfs the problem returns. I have also tried creating another VM but using ext4 on the system, and if the external is in btrfs the bug happens. This is the data you requested regarding my system (sorry for using an external link): https://privatebin.net/?8335f37a27944d8f#5jasgaWjQxpLSBycaNNqydWzRkDYq7FA3ozuBE521BKs I also have the virtualbox ones (with all btrfs), if it helps: 64 1 0:31 /@ / rw,noatime shared:1 - btrfs /dev/mapper/luks-39bd8004-e6e4-4fd4-9009-4f7310e7d24c rw,compress=zstd:3,space_cache=v2,subvolid=256,subvol=/@ 33 64 0:6 / /dev rw,nosuid shared:2 - devtmpfs devtmpfs rw,size=4096k,nr_inodes=246744,mode=755,inode64 34 33 0:23 / /dev/shm rw,nosuid,nodev shared:3 - tmpfs tmpfs rw,inode64 35 33 0:24 / /dev/pts rw,nosuid,noexec,relatime shared:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 36 64 0:22 / /sys rw,nosuid,nodev,noexec,relatime shared:5 - sysfs sysfs rw 37 36 0:7 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:6 - securityfs securityfs rw 38 36 0:26 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:7 - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot 39 36 0:27 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:8 - pstore pstore rw 40 36 0:28 / /sys/firmware/efi/efivars rw,nosuid,nodev,noexec,relatime shared:9 - efivarfs efivarfs rw 41 36 0:29 / /sys/fs/bpf rw,nosuid,nodev,noexec,relatime shared:10 - bpf bpf rw,mode=700 42 36 0:30 / /sys/kernel/config rw,nosuid,nodev,noexec,relatime shared:11 - configfs configfs rw 43 64 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:12 - proc proc rw 44 64 0:25 / /run rw,nosuid,nodev shared:13 - tmpfs tmpfs rw,size=399960k,nr_inodes=819200,mode=755,inode64 22 43 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:14 - autofs systemd-1 rw,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1940 23 33 0:35 / /dev/hugepages rw,nosuid,nodev,relatime shared:15 - hugetlbfs hugetlbfs rw,pagesize=2M 24 33 0:19 / /dev/mqueue rw,nosuid,nodev,noexec,relatime shared:16 - mqueue mqueue rw 25 36 0:8 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:17 - debugfs debugfs rw 26 36 0:13 / /sys/kernel/tracing rw,nosuid,nodev,noexec,relatime shared:18 - tracefs tracefs rw 27 64 0:36 / /tmp rw,nosuid,nodev shared:19 - tmpfs tmpfs rw,size=999896k,nr_inodes=1048576,inode64 29 36 0:37 / /sys/fs/fuse/connections rw,nosuid,nodev,noexec,relatime shared:20 - fusectl fusectl rw 31 64 0:31 /@home /home rw,noatime shared:35 - btrfs /dev/mapper/luks-39bd8004-e6e4-4fd4-9009-4f7310e7d24c rw,compress=zstd:3,space_cache=v2,subvolid=257,subvol=/@home 32 64 0:31 /@cache /var/cache rw,noatime shared:52 - btrfs /dev/mapper/luks-39bd8004-e6e4-4fd4-9009-4f7310e7d24c rw,compress=zstd:3,space_cache=v2,subvolid=258,subvol=/@cache 46 64 0:31 /@log /var/log rw,noatime shared:54 - btrfs /dev/mapper/luks-39bd8004-e6e4-4fd4-9009-4f7310e7d24c rw,compress=zstd:3,space_cache=v2,subvolid=259,subvol=/@log 50 64 8:1 / /boot/efi rw,relatime shared:78 - vfat /dev/sda1 rw,fmask=0137,dmask=0027,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 57 44 0:47 / /run/user/1000 rw,nosuid,nodev,relatime shared:224 - tmpfs tmpfs rw,size=199976k,nr_inodes=49994,mode=700,uid=1000,gid=1000,inode64 183 57 0:48 / /run/user/1000/doc rw,nosuid,nodev,relatime shared:245 - fuse.portal portal rw,user_id=1000,group_id=1000 # Before deleting it: Fichero: /run/media/usuario/a757a0f2-5e87-41c9-8ac4-15f7cf4a5017/TEST.txt Tamaño: 2 Bloques: 8 Bloque E/S: 4096 fichero regular Device: 0,55 Inode: 257 Links: 1 Acceso: (0644/-rw-r--r--) Uid: ( 1000/ usuario) Gid: ( 1000/ usuario) Acceso: 2024-06-04 01:11:15.108766371 +0200 Modificación: 2024-06-04 01:10:56.511382981 +0200 Cambio: 2024-06-04 01:10:56.511382981 +0200 Creación: 2024-06-04 01:10:56.511382981 +0200 # After deleting it: Fichero: /home/usuario/.local/share/Trash/files/TEST.txt Tamaño: 2 Bloques: 8 Bloque E/S: 4096 fichero regular Device: 0,40 Inode: 33757 Links: 1 Acceso: (0644/-rw-r--r--) Uid: ( 1000/ usuario) Gid: ( 1000/ usuario) Acceso: 2024-06-04 01:11:15.108766371 +0200 Modificación: 2024-06-04 01:10:56.511382981 +0200 Cambio: 2024-06-04 01:11:58.019013321 +0200 Creación: 2024-06-04 01:11:58.019013321 +0200
Simply put: the st_dev from mountinfo is inconsistent with the st_dev from stat despite the docs saying it should be consistent. Here's the relevant information mountinfo: > 59 45 0:53 / /run/media/usuario/0b60e126-5a13-47c3-a4dc-60b4f8f4b067 rw,nosuid,nodev,relatime shared:301 - btrfs /dev/sdd1 rw,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/ It says the st_dev should be 0:53 stat: > Device: 0,54 Inode: 260 Links: 1 It says the actual st_dev is 0:54 This looks entirely unexpected considering the docs explicitly say > (3) major:minor: value of st_dev for files on filesystem https://docs.kernel.org/filesystems/proc.html?highlight=mountinfo#proc-pid-mountinfo-information-about-mounts As suspected this then trips up our device detection logic because we can't tell which device (in mountinfo) relates to the file. I think it's best if you file a bug with your distro kernel so this can be taken upstream.
I checked again for duplicates and this time I found the bug 395023. I'm not sure if it's the same because I didn't make any subvol for externals, but at least it seems related. Anyway, in case it helps anyone who finds this, I think it's worth mentioning that “trash-cli” (mentioned in comment '5 of bug 395023) is working for me.