The details posted are as expected. This behaviour is not a bug. GParted performs the "move/resize" action internally as two separate steps: a move operation, and a grow operation.
For the move: GParted resizes the partition to be an all-encompassing partition, moves the file system within the partition, and then shrinks the partition to fit the file system. For the grow: GParted resizes the partition to be an all-encompassing partition, then grows the file system to fill the partition. These two separate steps are common to all file systems actions and are kept separate for simplicity and consistency in the code. The reason being that while some file systems like ext2/3/4 have file system specific commands for moving, such as e2image, others must rely on GParted to perform it's own internal move operation. 'Hope that helps explain what occurred and why. Regards, Curtis Gedak On 2018-12-05 12:52 p.m., Brent W. Baccala wrote: > Hi - > > I just using gparted 0.32.0 on Ubuntu Bionic 18.04 to move and resize a > partition. > > Initially, there was a 25 GB partition and a 100 GB partition followed by a > 574 GB partition. The operation was to remove the 25 GB and 100 GB > partitions, move the 574 GB partition backwards to align with the old > partition's start, and resize the new partition to approx 698 GB. > > Take a look at the attached gparted_details.htm. It looks like after the > old partitions were deleted, the 574 GB partition was moved and resized to > 698 GB in one step, then resized back to 574 GB, then resized again to 698 > GB. > > Everything worked out fine, but this looked to me like some kind of bug, so > I thought it was best to report it. > > agape > brent >
