From 99e908f79b75cc69ad76c4db8548b3a3150cfc05 Mon Sep 17 00:00:00 2001 From: Mike Fleetwood Date: Thu, 10 Sep 2015 13:49:28 +0100 Subject: [PATCH] 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 --- src/Win_GParted.cc | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/Win_GParted.cc b/src/Win_GParted.cc index 72ec8a88..5fe4ccd4 100644 --- a/src/Win_GParted.cc +++ b/src/Win_GParted.cc @@ -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: