Bug 480111 - Deleting a symlink is impossible if the disk of the target is close to full
Summary: Deleting a symlink is impossible if the disk of the target is close to full
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 6.5.0
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-20 22:55 UTC by sasori.nami
Modified: 2024-09-19 12:00 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.