bug#33634: Strange behavior from gparted

[Curtis Gedak]

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
>