Bug 501063

Summary:	FAT32 partition is shrunk without resizing underlying filesystem
Product:	[Applications] partitionmanager	Reporter:	Rua <ruawhitepaw>
Component:	general	Assignee:	Andrius Štikonas <andrius>
Status:	REPORTED ---
Severity:	major
Priority:	NOR
Version First Reported In:	24.12.2
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Rua 2025-03-04 18:53:07 UTC

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

Please remove this comment after reading and before submitting - thanks!
***

SUMMARY
When resizing a FAT32 filesystem, KDE Partition Manager did not resize the underlying filesystem, which left the filesystem in a broken state.

STEPS TO REPRODUCE
1. Create a 1024 MiB FAT32 partition, and format it.
2. Using KDE Partition manager, resize it to 512 MiB.

OBSERVED RESULT
The partition is resized to 512 MiB. But when running `df -h`, the filesystem is still shown with its original size. Running `fsck.fat` on it returns an error and does not complete. KDE Partition Manager cannot resize the partition back to 1024 MiB.

EXPECTED RESULT
Either the filesystem should be resized in accordance with the partition size, or KDE Partition Manager should abort the operation with an error to tell the user that it cannot resize the filesystem to match.

SOFTWARE/OS VERSIONS
OS: Fedora 41 KDE
Linux: 6.13.5
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2

ADDITIONAL INFORMATION

Comment 1 Rua 2025-03-04 18:58:35 UTC

Perhaps worth mentioning, this was an EFI system partition. So it's a normal FAT32 filesystem, but the partition type would have been different. The partition table was the GPT type.

Comment 2 Andrius Štikonas 2025-03-04 19:26:58 UTC

Hmm, not sure how this happened. Since it absolutely should have resized underlying file system. And resizing of fs in shrinking case happens to be before resizing of partition, see the following 3 lines:

https://invent.kde.org/system/kpmcore/-/blob/master/src/ops/resizeoperation.cpp?ref_type=heads#L69