Created attachment 147031 [details] KDE Partition Manager Logs & Results from fsck SUMMARY Backing up 465 GiB ext4 partition with built-in backup feature resulted in creating a file that when viewed with hex editor is devoid of data but is reported to be 465 GiB in Dolphin. Attempting to restore with this backup leads to an unknown filesystem on the partition which cannot be repaired with fsck, resulting in a loss of all data in said partition. STEPS TO REPRODUCE 1. Backup ext4 partition with KDE Partition Manager 2. View created file with hex editor and observe empty file 3. Restore said partition with KDE Partition Manager OBSERVED RESULT Restored partition is unusable and data is lost EXPECTED RESULT Partition is backed up with all data intact, and restoration creates a usable filesystem with all data intact SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.7-1-MANJARO (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION This may not be limited to ext4 partitions, but I can only report ext4 partition as that is all I tested. Included logs from backup, restore, and results from attempted fsck.
Created attachment 147032 [details] fsck results Forgot to input on other attachment.
Hmm, I can't reproduce this. Just tried backing up 8 GB partition from my USB stick and it worked $ sudo blkid test test: LABEL="test" UUID="03a4ba3c-058f-4b46-9e6d-99a21d9407d4" UUID_SUB="7bfe210b-b6e1-4896-99bf-0cf0467bd1ec" BLOCK_SIZE="4096" TYPE="btrfs"
Can you try running it on some other partition and see if you can reproduce it on your system?
(In reply to Andrius Štikonas from comment #3) > Can you try running it on some other partition and see if you can reproduce > it on your system? My previous test was on a HDD so I tried with a 28 GiB pen drive and had the same result. This was also an ext4 partition. I just noticed yours was btrfs so I will test with a btrfs partition.
So I tested twice with btrfs partition. On first test I told KDE Partition Manager to restore the backup overwriting the existing backed-up partition. When running the btrfs check --repair command after closing device it returned "Error". KDE partition manager again saw this as an unknown partition. Second test I deleted the existing partition and told it to restore the same backup, this time the check file system returned success, but did not appear to run the btrfs check --repair command. Then it attempted to resize the file system from 31 million sectors to 60 million sectors and failed with "The file system on partition 'dev/sde1' cannot be resized because there is no support for it." and the same generic "Error" below that. KDE Partition Manager still sees the restored partition as an unknown partition and if I remove and reinsert the USB drive I do not get asked to mount it as I usually would.
(In reply to morashon from comment #5) > So I tested twice with btrfs partition. On first test I told KDE Partition > Manager to restore the backup overwriting the existing backed-up partition. > When running the btrfs check --repair command after closing device it > returned "Error". KDE partition manager again saw this as an unknown > partition. Well, partition type shouldn't matter and it looks like your backup file is already corrupted, so it's not restore process either. That's why I was just testing with running backing up and checking partition signature with blkid (that should be sufficient to tell whether backup is empty file or not). Would you be willing to try to compile the latest version of kpmcore and partitionmanager (and probably with some diagnostic patches later to see where things go wrong)? Right now I have no idea what's going wrong. The latest version from git does have some changes but I can't tell whether they'll help or not (when copying disk data now we open and close files just once rather for each 10 MiB chunk that we copy). By the way, copying happens here: https://invent.kde.org/system/kpmcore/-/blob/master/src/util/externalcommandhelper.cpp#L239
> Well, partition type shouldn't matter and it looks like your backup file is > already corrupted, so it's not restore process either. > > That's why I was just testing with running backing up and checking partition > signature with blkid (that should be sufficient to tell whether backup is > empty file or not). > > Would you be willing to try to compile the latest version of kpmcore and > partitionmanager (and probably with some diagnostic patches later to see > where things go wrong)? > > Right now I have no idea what's going wrong. The latest version from git > does have some changes but I can't tell whether they'll help or not (when > copying disk data now we open and close files just once rather for each 10 > MiB chunk that we copy). > > By the way, copying happens here: > https://invent.kde.org/system/kpmcore/-/blob/master/src/util/ > externalcommandhelper.cpp#L239 (In reply to Andrius Štikonas from comment #6) > (In reply to morashon from comment #5) > > So I tested twice with btrfs partition. On first test I told KDE Partition > > Manager to restore the backup overwriting the existing backed-up partition. > > When running the btrfs check --repair command after closing device it > > returned "Error". KDE partition manager again saw this as an unknown > > partition. > Well, partition type shouldn't matter and it looks like your backup file is > already corrupted, so it's not restore process either. > > That's why I was just testing with running backing up and checking partition > signature with blkid (that should be sufficient to tell whether backup is > empty file or not). > > Would you be willing to try to compile the latest version of kpmcore and > partitionmanager (and probably with some diagnostic patches later to see > where things go wrong)? > > Right now I have no idea what's going wrong. The latest version from git > does have some changes but I can't tell whether they'll help or not (when > copying disk data now we open and close files just once rather for each 10 > MiB chunk that we copy). > > By the way, copying happens here: > https://invent.kde.org/system/kpmcore/-/blob/master/src/util/ > externalcommandhelper.cpp#L239 I am willing to do so. I'll get the latest and do a test and report back.
Sorry for my previous comment, unfamiliar with how this system works with the replying. After compiling and installing the latest build I was able to successfully backup and restore a partition twice from my pen drive. So this issue seems to be resolved in latest build with the changes you mentioned.
Since latest build has incidentally fixed this I will close this bug out.