Bug 420716

Summary:	KDE Partitioner crashes should not stop the operation in the middle
Product:	[Applications] partitionmanager	Reporter:	David <david.cortes.rivera>
Component:	general	Assignee:	Andrius Štikonas <andrius>
Status:	RESOLVED FIXED
Severity:	critical
Priority:	NOR
Version First Reported In:	3.3
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:	4.0
Sentry Crash Report:

Description David 2020-04-28 18:06:06 UTC

SUMMARY
If I try to resize partitions - e.g.
****ntfs****|****ext4****
to
**ntfs**|*****ext4*******
using KDE partition manager, it might crash with some unspecified error, AND crash the underlying partitioner process along with it in the middle of an operation, leaving the partition unusable, and without leaving any trace of what went wrong or any resume point.


STEPS TO REPRODUCE
1. Try to resize some contiguous partitions.

OBSERVED RESULT
Crashes in the middle of an operation (segmentation fault), leaves the partition unusable, around 1/3 of the data unrecoverable, and in a state in which calling "mount" on that partition would produce a segfault - i.e. the worst possible thing it could do.

EXPECTED RESULT
Should not crash, and if it does, crashing the QT application should NEVER BY ANY MEANS crash the underlying partitioner process. If it crashes, it should have some operation resume method that would allow to leave the disk in an integral state.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Comment 1 Andrius Štikonas 2020-04-28 18:22:55 UTC

I think this is fixed in version 4.

Version 4 has a small helper daemon that runs as root while GUI runs as unprivileged user.

That helper daemon is quite small and extremely unlikely to crash. If GUI crashes, then daemon will still run until current job is completed. It might not finish current operation though (Operation is a collection of jobs) but if job finishes, disk should be in a reasonably good state with no data loss.

Most other distros upgraded from kpmcore 3 to kpmcore 4 some time ago (see https://repology.org/project/kpmcore/badges)