| Summary: | Broken NTFS after moving partition | ||
|---|---|---|---|
| Product: | [Applications] partitionmanager | Reporter: | Kochi <menteleecn> |
| Component: | general | Assignee: | Andrius Štikonas <andrius> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | irik77587, tbertels |
| Priority: | NOR | ||
| Version First Reported In: | 23.04.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Kochi
2023-06-05 16:36:39 UTC
Implementation of update boot sector code is at https://invent.kde.org/system/kpmcore/-/blob/master/src/fs/ntfs.cpp#L180 I.e it just writes it to position 28 of the first and last sectors. Does *partitionmanager* use *parted* under the hood? If so, I recently found that parted would fail to format disk.img but gparted will work. I think I messed up the start of the first partition in parted but *gparted* just did automatically. Does *partitionmanager* use *parted* under the hood? If so, I recently found that parted would fail to format disk.img but gparted will work. I think I messed up the START of the first partition in parted but *gparted* just did automatically. (In reply to Ishrak from comment #3) > Does *partitionmanager* use *parted* under the hood? If so, I recently found > that parted would fail to format disk.img but gparted will work. I think I > messed up the START of the first partition in parted but *gparted* just did > automatically. No, it doesn't use parted, it uses fdisk. The noti mails of the new replies remind me of this after a whole year. Luckily I didn't end up with data recovery service because I came across this writeup of The InfoSecurity Challenge contest and the level 3 challenge was exactly this problem, and its solution worked like a charm for me. Thanks the author for the great writings. In conclusion somehow after re-partitioning the byte at `0x20` was `01`, which caused the mounting error. Ref: https://ctf.zeyu2001.com/2022/tisc-2022/level-3-patient0 I can reproduce both this and bug 424045 (moving Btrfs partition) both on Manjaro (with an SSD and a HDD) and in a VM with openSUSE TW. For some reason, it's harder to reproduce with ext4. Steps: - Create a 300 MB partition (Btrfs, FAT32 or NTFS) at the start of the free space, apply - Move it to the end of the free space, apply Result (on VM): Command: btrfs check /dev/sda4 Check file system on partition ‘/dev/sda4’: Error Checking partition ‘/dev/sda4’ after resize/move failed. The partition is then shown as unknown. I've noticed that gparted resizes the partition when moving it: it grows it to use all the space, then moves the data and finally shrinks the partition to its original size. Shouldn't KDE Partition Manager do the same ? (In reply to Thomas Bertels from comment #7) > I've noticed that gparted resizes the partition when moving it: it grows it > to use all the space, then moves the data and finally shrinks the partition > to its original size. > Shouldn't KDE Partition Manager do the same ? Yes, I think KDE Partition Manager does exactly the same (see https://invent.kde.org/system/kpmcore/-/blob/master/src/ops/resizeoperation.cpp?ref_type=heads#L69). So I'm a bit confused what exactly causes this. (In reply to Andrius Štikonas from comment #8) > (In reply to Thomas Bertels from comment #7) > > I've noticed that gparted resizes the partition when moving it: it grows it > > to use all the space, then moves the data and finally shrinks the partition > > to its original size. > > Shouldn't KDE Partition Manager do the same ? > > Yes, I think KDE Partition Manager does exactly the same (see > https://invent.kde.org/system/kpmcore/-/blob/master/src/ops/resizeoperation. > cpp?ref_type=heads#L69). So I'm a bit confused what exactly causes this. As I understand it, resizeAction() (https://invent.kde.org/system/kpmcore/-/blob/master/src/ops/resizeoperation.cpp?ref_type=heads#L232) finds out based on start and end sector if KDE Partition Manager needs to move, grow, shrink (or a combination) the partition and only one of those operations happen. The bitwise & operator may make it seem like Shrink and Grow always happen (note that it would be in the wrong order as gparted grows it then shrinks it), but I don't think that's the case based on enum ResizeAction (https://invent.kde.org/system/kpmcore/-/blob/master/src/ops/resizeoperation.h?ref_type=heads#L51). (In reply to Thomas Bertels from comment #9) > The bitwise & operator may make it seem like Shrink and Grow always happen > (note that it would be in the wrong order as gparted grows it then shrinks > it), but I don't think that's the case based on enum ResizeAction > (https://invent.kde.org/system/kpmcore/-/blob/master/src/ops/resizeoperation. > h?ref_type=heads#L51). Indeed, there is either growth or shrink operation or keep the same size... Never both growth and shrink. There is a non-trivial interaction between growth/shrink and left/right moves but I doubt that it is wrong. Still we need to understand what is going on. I don't think I ever saw data loss when moving/resizing partition myself. I guess the first thing is I should try to reproduce it somehow. |