ZFS labels were not cleared by GParted when clearing old file system
signatures.
# wget https://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/zfs.img.bz2
# bzip2 -dc zfs.img.bz2 > /dev/sdb1
[In GParted format to cleared /dev/sdb1]
# blkid /dev/sdb1
/dev/sdb1: LABEL="tank" UUID="1782036546311300980" UUID_SUB="13179280127379850514" TYPE="zfs_member"
Update to also zero all 4 ZFS labels.
NOTE:
GParted now writes a little over 1 MiB when clearing old file system
signatures. As this is performed in the main thread the UI is not able
to respond during this action. Testing this on a range of USB flash
keys and hard drives found the slowest normal time to write this was
0.25 seconds, with an occasional outlier up to 2.8 seconds from a USB
flash key. This is considered acceptable.
Following the previous commit "Add erasing of SWRaid metadata 0.90 and
1.0 super blocks (#756829)" signature zeroing specified to write 4 KiB
of zeros at position end - 64 KiB, aligned to 64 KiB. Example operation
details from formatting a 1 GiB partition to cleared:
Format /dev/sdb8 as cleared
+ calibrate /dev/sdb8
+ clear old file system signatures in /dev/sdb8
+ write 68.00 KiB of zeros as byte offset 0
+ wite 4.00 KiB of zeros at byte offset 67108864
+ wite 64.00 KiB of zeros at byte offset 1073676288
+ write 8.00 KiB of zeros at byte offset 1073733632
+ flush operating system cache of /dev/sdb
However it actually wrote 64 KiB. This is because the rounding /
alignment was also applied to the zeroing length. Before this commit
rounding / alignment was always less than or equal to the length so this
wasn't seen before. Instead just apply device sector size rounding up
to the length.
Bug 756829 - SWRaid member detection enhancements
The super blocks for Linux Software RAID arrays using metadata types
0.90 and 1.0 are stored at the end of the partition and not currently
cleared by GParted.
Create a SWRaid array, stop it and format it to cleared using GParted.
The signature remains.
# mdadm --create /dev/md1 --level=linear --raid-devices=1 --force --metadata=1.0 /dev/sdb1
# mdadm --stop /dev/md1
[In GParted format to cleared /dev/sdb1]
# blkid /dev/sdb1
/dev/sdb1: UUID="8ac947a7-063f-2266-5f2a-e5d178198139" UUID_SUB="49bd51d4-4c54-fb16-a45e-bd795f783f59" LABEL="rockover:1" TYPE="linux_raid_member"
As fixed in other cases before [1][2] it is necessary to clear all
signatures before formatting as a new file system to prevent recognition
issues. For example now format the partition as a FAT32 file system.
Now there are two signatures and libparted reports one type and blkid
reports another.
# mkdosfs -F 32 /dev/sdb1
# blkid /dev/sdb1
/dev/sdb1: UUID="8ac947a7-063f-2266-5f2a-e5d178198139" UUID_SUB="49bd51d4-4c54-fb16-a45e-bd795f783f59" LABEL="rockover:1" TYPE="linux_raid_member"
# parted /dev/sdb print
Model: ATA SAMSUNG SSD UM41 (scsi)
Disk /dev/sdb: 8012MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 538MB 537MB primary fat32
(Deliberately avoided btrfs, ext2/3/4 and xfs as recent versions of
their mkfs tools clear other signatures first for the same reason).
[1] Bug 688882 - Improve clearing of file system signatures
[2] 3c75f3f5b1
Use wipefs to clear old signatures before creating new file systems (#688882)
Update erase_filesystem_signatures() to also zero the necessary sectors
to clear SWRaid metadata 0.90 and 1.0 super blocks.
Bug 756829 - SWRaid member detection enhancements
If the installation is unusual / broken such that the mdadm command is
not found but there are active SWRaid arrays, provide a fallback with
some of the information. In this case populate the cache with details
only available from /proc/mdstat. Information will be limited to active
arrays only and their members. No UUIDs or labels. There will be no
information about inactive arrays and GParted will use it's normal
libparted and blkid identification for those devices and partitions.
As mdadm has gained the capability to manage Fake/BIOS RAID arrays they
also appear in /proc/mdstat when mdadm is used to start them. Enhance
the parser of /proc/mdstat to only extract information for SWRaid arrays
with recognised metadata versions.
Bug 756829 - SWRaid member detection enhancements
Automatically load the cache of SWRaid information for the first time if
any of the querying methods are called before the first explicit
load_cache() call. Means we can't accidentally use the class and
incorrectly find no SWRaid members when they do exist.
Bug 756829 - SWRaid member detection enhancements
Busy file systems are accessed via a mount point, LVM Physical Volumes
are activated via the Volume Group name and busy SWRaid members are
accessed via the array device, /dev entry. Therefore choose to show the
array device in the mount point field for busy SWRaid members.
The kernel device name for an SWRaid array (without leading "/dev/") is
the same as used in /proc/mdstat and /proc/partitions. Therefore the
array device (with leading "/dev/") displayed in GParted will match
between the mount point for busy SWRaid members and the array itself as
used in the device combo box.
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda1[2] sdb1[3]
524224 blocks super 1.0 [2/2] [UU]
...
# cat /proc/partitions
major minor #blocks name
8 0 33554432 sda
8 1 524288 sda1
...
8 16 33554432 sdb
8 17 524288 sdb1
...
9 1 524224 md1
...
Bug 756829 - SWRaid member detection enhancements
In cases where blkid wrongly reports a file system instead of an SWRaid
member (sometimes confused by metadata 0.90/1.0 mirror array or old
version not recognising SWRaid members), the UUID and label are
obviously wrong too. Therefore have to use the UUID and label returned
by the mdadm query command and never anything reported by blkid or any
file system specific command.
Example of blkid reporting the wrong type, UUID and label for /dev/sda1
and the correct values for /dev/sdb1:
# blkid | egrep 'sd[ab]1'
/dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot"
/dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member"
# mdadm -E -s -v
ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1
devices=/dev/sda1,/dev/sdb1
...
ARRAY /dev/md127 level=raid1 num-devices=2 UUID=8dc7483c:d74ee0a8:b6a8dc3c:a57e43f8
devices=/dev/sdb6,/dev/sda6
...
NOTES:
* In mdadm terminology the label is called the array name, hence name=
parameter for array md/1 in the above output.
* Metadata 0.90 arrays don't support naming, hence the missing name=
parameter for array md127 in the above output.
Bug 756829 - SWRaid member detection enhancements
Add active attribute to the cache of SWRaid members. Move parsing of
/proc/mdstat to discover busy SWRaid members into the cache loading
code. New parsing code is a little different because it is finding all
members of active arrays rather than determining if a specific member is
active.
Bug 756829 - SWRaid member detection enhancements
Detection of Linux SWRaid members currently fails in a number of cases:
1) Arrays which use metadata type 0.90 or 1.0 store the super block at
the end of the partition. So file system signatures in at least
linear and mirrored arrays occur at the same offsets in the
underlying partitions. As libparted only recognises file systems
this is what is detected, rather than an SWRaid member.
# mdadm -E -s -v
ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1
devices=/dev/sda1,/dev/sdb1
...
# wipefs /dev/sda1
offset type
----------------------------------------------------------------
0x438 ext4 [filesystem]
LABEL: chimney-boot
UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501
0x1fffe000 linux_raid_member [raid]
LABEL: chimney:1
UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a
# parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 538MB 537MB primary ext4 boot, raid
...
2) Again with metadata type 0.90 or 1.0 arrays blkid may report the
contained file system instead of an SWRaid member. Have a single
example of this configuration with a mirrored array containing the
/boot file system. Blkid reports one member as ext4 and the other as
SWRaid!
# blkid | egrep 'sd[ab]1'
/dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot"
/dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member"
Bypassing the blkid cache gets the correct result.
# blkid -c /dev/null /dev/sda1
/dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member"
However this can't be used because if a user has a floppy configured
in the BIOS but no floppy attached, GParted will wait for minutes as
the kernel tries to access non-existent hardware on behalf of the
blkid query. See commit:
18f863151c
Fix long scan problem when BIOS floppy setting incorrect
3) Old versions of blkid don't recognise SWRaid members at all so always
report the file system when found. Occurs with blkid v1.0 on
RedHat / CentOS 5.
The only way I can see how to fix all these cases is to use the mdadm
command to query the configured arrays. Then use this information for
first choice when detecting partition content, making the order: SWRaid
members, libparted, blkid and internal.
GParted shell wrapper already creates temporary blank udev rules to
prevent Linux Software RAID arrays being automatically started when
GParted refreshes its device information[1]. However an administrator
could manually stop or start arrays or change their configuration
between refreshes so GParted must load this information every refresh.
On my desktop with 4 internal hard drives and 3 testing Linux Software
RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the
device refresh time.
[1] a255abf343
Prevent GParted starting stopped Linux Software RAID arrays (#709640)
Bug 756829 - SWRaid member detection enhancements
When multiple devices are named on the command line and (after sorting
and removing duplicates) the device following a non-existent or invalid
one is not checked for usability [1]. In most situations this isn't
noticed as the device gets skipped at the "Searching ... partitions"
step instead. However as seen in bug 755495 and commit [2]
checking usability matters.
For example (on CentOS 6.5) a large sector disk device can be edited
when it follows a non-existent or invalid device named on the command
line:
# modprobe scsi_debug dev_size_mb=128 sector_size=4096
# fgrep scsi_debug /sys/block/*/device/model
/sys/block/sdd/device/model:scsi_debug
# ./gpartedbin /dev/does-not-exist /dev/sdd
======================
libparted : 2.1
======================
Could not stat device /dev/does-not-exist - No such file or directory.
Device /dev/sdd has a logical sector size of 4096. Not all parts of GNU Parted support this at the moment, and the working code is HIGHLY EXPERIMENTAL.
/dev/sdd: unrecognised disk label
When erasing a device don't skip confirming the following device is
usable.
[1] Usable device as implemented by useable_device()
Must not have a large sector size when GParted is built with an old
version of libparted which doesn't support large sector sizes and
must be able to read the first sector.
[2] 362b2db331
Check disks named on the command line are safe to use too (#755495)
Bug 756434 - GParted dumps core when passing non-existent or invalid
device on the command line
A non-existent or invalid disk device named on the command line caused
two libparted dialogs to be displayed repeatedly on every refresh. This
was because the device was only removed from the 'device_paths' vector
when it wasn't usable [1]; not when it didn't exist or was invalid, when
the libparted ped_device_get() call failed. Fix this.
[1] Usable device as implemented by useable_device()
Must not have a large sector size when GParted is built with an old
version of libparted which doesn't support large sector sizes and
must be able to read the first sector.
Bug 756434 - GParted dumps core when passing non-existent or invalid
device on the command line
Naming a non-existent or invalid disk device on the command line causes
GParted to dump core. Non-existent device looks like this:
# ./gpartedbin /dev/does-not-exist
======================
libparted : 2.4
======================
Could not stat device /dev/does-not-exist - No such file or directory.
Could not stat device /dev/does-not-exist - No such file or directory.
Backtrace has 10 calls on stack:
10: /lib64/libparted.so.0(ped_assert+0x31) [0x7fcfd10b3e61]
9: /lib64/libparted.so.0(+0x3fdfc12a0c) [0x7fcfd10b4a0c]
8: /home/mike/bin/gpartedbin-0.23.0-master-63-g23b5ba4() [0x455028]
7: /home/mike/bin/gpartedbin-0.23.0-master-63-g23b5ba4() [0x455090]
6: /home/mike/bin/gpartedbin-0.23.0-master-63-g23b5ba4() [0x4550d5]
5: /home/mike/bin/gpartedbin-0.23.0-master-63-g23b5ba4() [0x46723f]
4: /usr/lib64/libglibmm-2.4.so.1() [0x3ff5834a8d]
3: /lib64/libglib-2.0.so.0() [0x3fe086a374]
2: /lib64/libpthread.so.0() [0x3fdf407a51]
1: /lib64/libc.so.6(clone+0x6d) [0x3fdf0e893d]
Assertion (dev != NULL) at device.c:227 in function ped_device_open() failed.
Aborted (core dumped)
And with an invalid device the output looks like this:
# ./gpartedbin /dev/zero
======================
libparted : 2.4
======================
The device /dev/zero is so small that it cannot possibly store a file system or partition table. Perhaps you selected the wrong device?
Error fsyncing/closing /dev/zero: Invalid argument
The device /dev/zero is so small that it cannot possibly store a file system or partition table. Perhaps you selected the wrong device?
Error fsyncing/closing /dev/zero: Invalid argument
Backtrace has 10 calls on stack:
...
[Same as above]
Bisected the cause to this commit from 2015-03-09 in GParted 0.22.0. It
claimed to make no functional change. That turned out not to be true.
51ac4d5648
Split get_device_and_disk() into two (#743181)
Fix by simply adding the missed if condition in get_device().
Bug 756434 - GParted dumps core when passing non-existent or invalid
device on the command line
For probed DMRaid devices (when not using libparted DMRaid support)
GParted waits up to 1 second for udev to have processed all events and
created the /dev entries after starting each DMRaid array. This was
added by this commit from 2009-09-02:
e7352a5000
Ensure /dev file system device entries created before adding device
Do the same for devices named on the command line too.
Order named disk devices so that they appear in the combo box in the
same order which they would when probed. Also remove duplicates so that
the same disk devices aren't scanned multiple times and appear
duplicated in the UI.
Try this; it used to take ages to load and looked weird:
# gparted /dev/sda /dev/sdb /dev/sda /dev/sdb /dev/sda /dev/sdb
Bug 755495 - GParted allowing partitioning of large sector devices
specified on the command line, when built with old
libparted which doesn't support it
When probing for disk devices GParted ensures that libparted is capable
of handling the sector size safely and that it is a real disk before it
is shown in the UI. However when disk devices are named on the command
line none of these checks are performed.
Libparted versions before v2.2 can only safely handle a sector size of
512 bytes. Therefore on old distributions with libparted < v2.2 GParted
allows unsafe editing of disk devices with larger sector sizes when they
are named on the command line. Known to affect these distributions:
RedHat/CentOS 5 (parted 1.8.1)
RedHat/CentOS 6 (parted 2.1)
For example (on CentOS 6.5) large sector disk device is ignored when
probing:
# modprobe scsi_debug dev_size_mb=128 sector_size=4096
# fgrep scsi_debug /sys/block/*/device/model
/sys/block/sdd/device/model:scsi_debug
# gparted
======================
libparted : 2.1
======================
Device /dev/sdd has a logical sector size of 4096. Not all parts of
GNU Parted support this at the moment, and the working code is
HIGHLY EXPERIMENTAL.
Ignoring device /dev/sdd with logical sector size of 4096 bytes.
GParted requires libparted version 2.2 or higher to support devices
with sector sizes larger than 512 bytes.
However when the device is named it is not ignored and can be edited:
# gparted /dev/sdd
======================
libparted : 2.1
======================
Device /dev/sdd has a logical sector size of 4096. Not all parts of
GNU Parted support this at the moment, and the working code is
HIGHLY EXPERIMENTAL.
/dev/sdd: unrecognised disk label
Apply the same validity checks to disk devices named on the command line
as to probed ones.
Bug 755495 - GParted allowing partitioning of large sector devices
specified on the command line, when built with old
libparted which doesn't support it
Abstract code checking sector size and ensuring the first sector of a
candidate disk device can be read into new
GParted_Core::useable_device() method.
Bug 755495 - GParted allowing partitioning of large sector devices
specified on the command line, when built with old
libparted which doesn't support it
I missed another case of 'index' may be used uninitialised warning in
OperationDelete::apply_to_visual(). Indent a code block within an if
clause so that the compiler can confirm that the 'index' local variable
isn't used uninitialised. Prevent this compiler warning:
OperationDelete.cc: In member function 'virtual void GParted::OperationDelete::apply_to_visual(std::vector<GParted::Partition, std::allocator<GParted::Partition> >&)':
OperationDelete.cc:34: warning: 'index' may be used uninitialized in this function
Bug 755214 - Refactor operation merging
Libsigc++2 version 2.5.2 and later removed header file
<sigc++/class_slot.h>. Quoting the NEWS file for version 2.5.2:
Remove useless headers: sigc++/class_slot.h ...
Libsigc++2 version 2.5.2 NEWS file:
https://git.gnome.org/browse/libsigc++2/tree/NEWS?id=2.5.2
Bug 756035 - GParted does not compile with newer gtkmm libraries in
Fedora 23
Glibmm 2.45.40 and later uses features in the ISO C++ 2011 standard.
The NEWS file [1] says:
Changes in 2.46 compared to 2.44:
General:
* Use, and require C++11, using features such as move operations,
noexcept auto, = delete, nulltpr, override.
(Murray Cumming, Kjell Ahlstedt)
Also found this by Murray Cumming [2]:
glibmm 2.45.40 requires C++11, both for its own build and by any
apps that use it. gtkmm also now requires C++11.
I think you are seeing a symptom of building the application without
C++11 support. For instance, using CXXFLAGS="--std=c++11", though
you'd be better of using an m4 macro such as
AX_CXX_COMPILE_STDCXX_11().
Without enabling C++11 compiler features, compilation of GParted with
the latest glibmm library fails with errors such as these:
/usr/include/glibmm-2.4/glibmm/ustring.h:267:14: error: expected ';' at end of member declaration
~ustring() noexcept;
^
/usr/include/glibmm-2.4/glibmm/ustring.h:267:14: error: 'noexcept' does not name a type
~ustring() noexcept;
^
/usr/include/glibmm-2.4/glibmm/ustring.h:267:14: note: C++11 'noexcept' only available with -std=c++11 or -std=gnu++11
[1] glibmm NEWS file
https://git.gnome.org/browse/glibmm/tree/NEWS?id=934e8290ce913b12e251ea617d0fc8ac53c385c6
[2] https://bugs.launchpad.net/ubuntu/+source/glibmm2.4/+bug/1478367
Bug 756035 - GParted does not compile with newer gtkmm libraries in
Fedora 23
Older distributions don't include Autoconf Archive at all and newer
distributions don't always include it. Therefore we have to have a
local copy of the AX_CXX_COMPILE_STDCXX_11 macro with GParted.
Bug 756035 - GParted does not compile with newer gtkmm libraries in
Fedora 23
Add recognition for work done by Albert Young to prevent a hang in
GParted labeling FAT16/32 if label contained illegal characters.
Bug 755608 - Labeling fat16/fat32 partitions hangs if certain
characters included in label
GParted waits forever when attempting to set a FAT16/32 file system
label which contains prohibited characters [1][2]. This is because
mlabel asks a question and is waiting for input. Force cancelling the
operation doesn't work either as GParted sends signal 2 (interrupt i.e.
[Ctrl-C]) but mtools commands specifically ignores this and a number of
other signals. Have to kill mlabel with signal 9 (kill) to regain
control of GParted.
Mlabel command with prohibited characters in the label:
# export MTOOLS_SKIP_CHECK=1
# mlabel ::"MYLABEL/ " -i /dev/sdb10
Long file name "MYLABEL/ " contains illegal character(s).
a)utorename A)utorename-all r)ename R)ename-all
s)kip S)kip-all q)uit (aArRsSq):
Remove prohibited characters from FAT16/32 file systems labels when
creating and labelling them. Also upper case the label to meet label
requirements [1][2]. This silently corrects the label and the actual
label applied will be displayed when GParted refreshes after applying
the operation.
[1] Microsoft TechNet: Label
https://technet.microsoft.com/en-us/library/bb490925.aspx
[2] Replicated in Wikikedia: label (command)
https://en.wikipedia.org/wiki/Label_%28command%29
Bug 755608 - Labeling fat16/fat32 partitions hangs if certain characters
included in label
These member variables store no Operation class information and were
being used as local variables. Replace with local variables.
Also indent a code block within an if clause so that the compiler can
confirm that the new local variable isn't used uninitialised. Prevents
this compiler warning:
OperationResizeMove.cc: In member function 'void GParted::OperationResizeMove::apply_normal_to_visual(std::vector<GParted::Partition, std::allocator<GParted::Partition> >&)':
OperationResizeMove.cc:125: warning: 'index' may be used uninitialized in this function
Bug 755214 - Refactor operation merging
Since this commit earlier in the patchset the second optional parameter
of method Win_GParted::Add_Operation() is no longer used. Remove it.
Replace open coded merge of resize/move into create operation
(#755214)
Bug 755214 - Refactor operation merging
This is the equivalent case fixed in the earlier commit, but now using
copy/paste to create the second new partition rather than plain new.
Fix visually re-apply create operation in create-create-grow-first
sequence (#755214)
Start with an existing partition as a copy source. Then this sequence
of operations will cause the copy partition to disappear from the disk
graphic:
1) create new #1,
2) copy existing / paste into unallocated leaving space preceding,
3) resize new #1 larger.
There are two different types of copy operation. The first is copy into
unallocated space creating a new partition which needs treating the same
as create new operation. The second is copy into existing partition
which needs treating the same as the other operations which don't change
the boundaries of the partition. Fix apply_to_visual() accordingly.
Bug 755214 - Refactor operation merging
Move the code from OperationCreate::apply_to_visual() into new method
Operation::insert_new() in the parent class. This is in preparation for
the following commit.
Bug 755214 - Refactor operation merging
The apply_to_visual() method for the change UUID, format, label file
system and name partition operations duplicated identical code. This
code was just substituting the partition in the disk graphic vector with
the new partition recorded in the operation, as none of these operations
change the partition boundaries. Move this duplicate code into the
parent class in new method Operation::substitute_new().
Bug 755214 - Refactor operation merging
After previous commit "Replace open coded merge of resize/move into
create operation (#755214)" the second created partition would disappear
from the disk graphic in the following sequence: create new #1, create
new #2 leaving space preceding, resize #1 larger. The create new #2
operation still existed and was shown in the operation list. It was
just that it disappeared from the disk graphic.
Remember that when each operation is created it records the partition,
or the unallocated space, to which the operation is applied at the time
the operation is created in the partition_original member variable. In
the above sequence the resize #1 larger operation was merged back into
the create new #1 operation. When visually re-applying the create
new #1 operation to the disk graphic, it left a smaller unallocated
partition following it. This was smaller than the unallocated partition
recorded in the create new #2 operation, hence it failed to visually
re-apply to the disk graphic.
The insight to fix this is that it doesn't matter what size the
unallocated space was when the create new operation was constructed. It
only matters that the new partition to be created fits in the available
unallocated space currently in the disk graphic.
Bug 755214 - Refactor operation merging
This information is already documented in the existing comments
associated with the calls to merge_operations() and assignments to the
mergetype variables. The table just summaries the rules together in one
place.
Bug 755214 - Refactor operation merging
For the case of resizing/moving a new, not yet created partition,
activate_resize() open coded the merge operation. Again this code has
existed in GParted since before version 0.0.5 and the current code
history in Git.
Replace the necessary code so that an explicit merge_operations() call
is used instead; along with the other case of resizing/moving an
existing partition.
NOTES:
This commit changes the merge direction. The old coded merged forward
by removing the old create operation and adding a new create operation
with the new size. This was bad because with multiple pending create
operations, each merged resize operation reordered those create
operations. Then when the operations were applied the partitions were
created and therefore numbered in a different order to that shown in
disk graphic.
The new code merges backwards by updating the initial create operation
with the new size. This maintains the create operation order so that
when applied the partitions are numbered in the same order as shown in
the disk graphic.
Bug 755214 - Refactor operation merging
For the case of formatting a new, not yet created partition,
activate_format() open coded the merge operation. This code has existed
in GParted since before version 0.0.5 and the current code history in
Git.
Replace the necessary code so that an explicit merge_operations() call
is used instead; along with the other case of formatting an existing
partition.
Bug 755214 - Refactor operation merging
Creation of the various operations involved various implicit rules about
how the different types of operations were merged in different cases.
This was open coded in each ::activate_*() method. Abstract this into
new merge_operations() method and make the merging rules explicitly
specified.
NOTE:
The removal of operation type checking in the MERGE_LAST_WITH_ANY cases
is not a problem because all the Operation*::merge_operations() methods
ensure the operation types match as part of the merge attempt.
Bug 755214 - Refactor operation merging
Rename Win_GParted::Merge_Operations() to merge_two_operations(). To
reflect what it does and in preparation for further refactoring of the
code.
Be more strict on the validation of the first and second indexes. The
first operation must also be before the second operation in the
operation[] vector. (It is actually a programming bug if first and
second fail validation. However so far g_assert() is only being used to
validate pointers, which if wrong would likely cause the program to
eventually crash when dereferenced later. In this case a bug would
merely cause the incorrectly specified pair of operations to not be
merged).
Move validate_display_partition_ptr() declaration in the header file to
be in the same ordering as it's definition in the source file.
Bug 755214 - Refactor operation merging
Win_GParted::Merge_Operations() method was modifying the internals of
Operation* objects; in particular the partition_new member variable.
This is breaking data hiding and encapsulation tenant of object oriented
programming.
Implement exactly the same operation merge semantics, but hide the
manipulation of the internals of the Operation* objects within the
Operation* classes themselves.
Bug 755214 - Refactor operation merging
... before refactoring the code.
See the commit message from 2011-10-05 for details of what operations,
available at that time, on the same partition can be merged and in what
cases:
b10349ae37
Merge overlapping operations (#438573)
Bug 755214 - Refactor operation merging
Mike Fleetwood