Refresh copy source when its a logical partition too (#754827)

Perform a copy, reformat source and paste sequence in GParted.  When the
source is a primary partition everything works as expected, with the
newly pasted partition reflecting the reformatted source.  However when
the source is a logical partition GParted thinks it is pasting the
original source, rather than the reformatted source.  The same is also
true for other file system manipulation operations: resize, file system
label and new UUID.  It is just that reformatting the source to a
different file system type is the most obvious in the UI and causes the
most significantly wrong actions to be performed.

For example start with an ext4 logical partition, select it for copy,
format it to xfs and paste into a new partition.  GParted thinks the
second operation will create a copy of an ext4 file system instead of
the xfs file system.  When applied the operation details are:

    Format /dev/sdd5 as xfs
    + calibrate /dev/sdd5
    + clear old file system signatures in /dev/sdd5
    + set partition type on /dev/sdd5
    + create new xfs file system
      + mkfs.xfs -f -L "" /dev/sdd5
    Copy /dev/sdd5 to /dev/sdd (start at 131.00 MiB)
    + calibrate /dev/sdd5
    + check file system on /dev/sdd5 for errors and (if possible) fix them
      + e2fsck -f -y -v -C 0 /dev/sdd5
          e2fsck: Subperblock invalid, trying backup blocks...
          Resize inode not valid.  Recreate? yes
          ...
          /dev/sdd5: ***** FILE SYSTEM WAS MODIFIED *****
    + create empty partition
    + set partition type on /dev/sdd6
        new partition type: ext4
    + copy file system of /dev/sdd5 to /dev/sdd6
        using internal algorithm
        ...

GParted formatted sdd5 to xfs, but then the copy step ran e2fsck and
managed to resurrect the ext4 file system and then performed a block
copy of it to partition sdd6.  The copy step should have ran xfs_repair
and used xfsdump | xfsrestore to copy the xfs file system.  Afterwards
sdd5 contains both xfs and ext4 signatures.

    # wipefs /dev/sdd5
    offset               type
    ----------------------------------------------------------------
    0x438                ext4   [filesystem]
                         UUID:  f0ed4247-76db-4d93-b3bc-c7da4a70f95e

    0x0                  xfs   [filesystem]
                         UUID:  1ac8e7c3-0311-4c64-8e4a-b715a23ea0bd

This has been broken at least as far back as GParted 0.1.0.

Fix by simply refreshing the copy source partition object when it is a
logical partition too, as well as when it is a primary partition.

Bug 754827 - Copy, reformat source and paste a logical partition thinks
             it's pasting the original file system
This commit is contained in:
Mike Fleetwood 2015-09-10 13:49:28 +01:00 committed by Curtis Gedak
parent 0e32d39189
commit 99e908f79b
1 changed files with 6 additions and 3 deletions

View File

@ -929,9 +929,9 @@ void Win_GParted::Refresh_Visual()
if ( ! operations .size() )
allow_undo_clear_apply( false ) ;
//Count primary partitions for check in max_amount_prim_reached(),
// check for an extended partition and select the largest unallocated
// partition if there is one.
// Count primary partitions for check in max_amount_prim_reached(), check for an
// extended partition, refresh copy partition source as necessary and select the
// largest unallocated partition if there is one.
index_extended = -1 ;
primary_count = 0;
@ -956,6 +956,9 @@ void Win_GParted::Refresh_Visual()
for ( unsigned int u = 0 ; u < display_partitions[t].logicals.size() ; u ++ )
{
if ( display_partitions[t].logicals[u].get_path() == copied_partition.get_path() )
copied_partition = display_partitions[t].logicals[u];
switch ( display_partitions[t].logicals[u].type )
{
case TYPE_UNALLOCATED: