Bug 480111

Summary:	Deleting a symlink is impossible if the disk of the target is close to full
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	sasori.nami
Component:	general	Assignee:	KIO Bugs <kio-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	kdelibs-bugs, kfm-devel, meven29
Priority:	NOR
Version:	6.5.0
Target Milestone:	---
Platform:	Manjaro
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description sasori.nami 2024-01-20 22:55:18 UTC

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

Comment 1 Méven Car 2024-03-06 11:30:40 UTC

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?

Comment 2 sasori.nami 2024-03-06 13:15:20 UTC

(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.

Comment 3 Bug Janitor Service 2024-03-21 03:45:57 UTC

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!

Comment 4 Méven Car 2024-09-19 12:00:10 UTC

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.