SUMMARY I have 2 HDDs, drive A and drive B. Drive A is close to full (only 50GB left). Drive A also contains a 60GB file (file_1). I create a symlink to this file on drive B. I select the symlink, hit "delete" and I see a message "There is not enough space on the disk to write file:///mnt/driveB/file_1". The only way I can delete the symlink is to drop to a console (or unplug drive A, that seems to work too, since this makes the symlink invalid -> 0B). Short of that available space problem, the symlink gets deleted normally, on the same drive's trash as the symlink (no cross-filesystem move), so that part works fine. It's only the pre-delete check that seem to make weird assumptions. STEPS TO REPRODUCE 1. Have two drives, one close to full (drive A), the other not (drive B) 2. Find a file on drive A with a size greater than the remaining space available on A (create it if necessary). 3. Create a symlink to that file on drive B. 4. Select the symlink, hit delete. OBSERVED RESULT A message "There is not enough space on the disk to write file:///path/to/driveB/big_file" appears. EXPECTED RESULT The symlink should be in drive B's trash. SOFTWARE/OS VERSIONS Linux: Linux kernel 6.1.71-1-MANJARO (64-bit) KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.12
The issue is the trash used is not on the correct drive. Trash are supposed to be per-drive. As a workaround, you can directly delete it using SHIFT+DELETE. Could detail you mount configuration, for instance with the output of `mount` command? Are you file-system using btrfs?
(In reply to Méven Car from comment #1) > The issue is the trash used is not on the correct drive. > Trash are supposed to be per-drive. > > As a workaround, you can directly delete it using SHIFT+DELETE. > > Could detail you mount configuration, for instance with the output of > `mount` command? > Are you file-system using btrfs? No, this is definitely not a trash issue. Both drives are ext4 with their own ".Trash" folder that woks flawlessly otherwise. Have you tried reproducing on your end ? It's pretty easy to reproduce (see steps above). I've just done it again. Different drives, same fs type (ext4), and again both drives have a working ".Trash" with correct permissions (if I go to either drive and trash a file from that drive, the file goes in the correct drive's trash). Thanks for the workaround, though.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
It seems the size calculation takes into account the symlink destination size when it should'nt. It is around this line, we don't check if the file is a symlink. https://invent.kde.org/frameworks/kio/-/blob/master/src/core/copyjob.cpp#L834 But most importantly we should not resolve the symlink when stat() is called() when moving the file. (copy should still copy symlink destinations). https://invent.kde.org/frameworks/kio/-/blob/master/src/core/copyjob.cpp#L1051 This bug could also affect moving such symlink anywhere on a drive that has less space than the file it points to' size in some (rare) circumstances, since `CopyJobPrivate::startRenameJob` does not check file size. I wonder if we handle properly moving symlinks to trash:/ that would need a unit-test.