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
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
As previous commit, display_partitions is now a Win_GParted member
variable so checking for the existence of an extended partition can be
localised where it is used.
Remove index_extended member variable and localise the same checking in
activate_new().
Now that display_partitions is a Win_GParted member variable and
therefore available throughout the class, since commit [1], calculation
of primary_count can be localised in max_amount_prim_reached() where it
is used.
Implements a FIXME and removes primary_count as a member variable.
[1] 545b75d957
Move vector of partition objects to a Win_GParted class member (#750168)
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
Command exit status is a 1 byte value between 0 and 255. [1][2] However
at the Unix API level the value is encoded as documented in the
waitpid(2) manual page. This is true for the Glib API too. [3] This is
why, for example, the comment in ext2::check_repair() reported receiving
undocumented exit status 256. It was actually receiving exit status 1
encoded as per the waitpid(2) method.
Add shell style exit status decoding [2] to execution of all external
commands. Return value from Utils::execute_command() and
FileSystem::execute_command() functions are now:
0 - 125 - Exit status from the command
126 - Error executing the command
127 - Command not found
128+N - Command terminated by signal N
255 - Unexpected waitpid(2) condition
Also adjust checking of the returned statuses as necessary.
[1] Advanced Bash-Scripting Guide: Appendix D. Exit Codes With Special
Meanings
http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/exitcodes.html
[2] Quote from the bash(1) manual page:
EXIT STATUS
... Exit statuses fall between 0 and 255, though as
explained below, the shell may use values above 125
specially. ...
... When a command terminates on a fatal signal N, bash uses
the value of 128+N as the exit status.
If a command is not found, the child process created to
execute it returns a status of 127. If a command is found
but is not executable, the return status is 126.
[3] Quote from the Glib Reference Manual, Spawning Processes section,
for function g_spawn_check_exit_status():
https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-check-exit-status
The g_spawn_sync() and g_child_watch_add() family of APIs return
an exit status for subprocesses encoded in a platform-specific
way. On Unix, this is guaranteed to be in the same format
waitpid() returns, ...
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
Replace open coding of the creation of the operation details for the
mlabel command used to set the label and UUID with calls to
FileSystem::execute_command() which will do it all. This also results
in the commands getting a time and check mark displayed in the operation
details.
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
There has been an undocumented rule that external commands displayed in
the operation details, as part of file system manipulations, only get a
time and check mark displayed when multiple commands are needed, and not
otherwise. (GParted checks whether all commands are successful or not
regardless of whether a check mark is displayed in the operation details
or not).
EXCEPTION 1: btrfs resize
Since the following commit [1] from 2013-02-22, GParted stopped
displaying the timing for the btrfs resize command in the operation
details. It being part of a multi-command sequence to perform the step.
This is because FileSystem::execute_command() since the commit can only
check the exit status for zero / non-zero while timing and checking the
command status but btrfs resize needs to consider some non-zero statuses
as successful.
[1] 52a2a9b00a
Reduce threading (#685740)
EXCEPTION 2: ext2/3/4 move and copy using e2image
When use of e2image was added [2] the single command steps were timed
and check.
[2] 86111fe12a
Use e2image to move/copy ext[234] file systems (#721516)
EXCEPTION 3: fat16/32 write label and UUID
Uses Utils::execute_command() rather than FileSystem::execute_command()
so can be separately changed. See the following commit for resolution
of the final commands not yet timed and check mark displayed.
CHANGE:
Lets make a simpler rule of always displaying the time and a check mark
for all external commands displayed in the operation details. However
this makes several of the other single command actions need special exit
status handling because zero success, non-zero failure is not correct
for every case. Specifically affects resizing of reiserfs and check
repair of ext2/3/4, fat16/32, jfs and reiserfs.
After this change all external commands run as file system actions must
follow one of these two patterns of using the EXEC_CHECK_STATUS flag or
separately calling FileSystem::set_status() to register success or
failure of the command:
exit_status = execute_command(cmd, od, EXEC_CHECK_STATUS...);
or:
exit_status = execute_command(cmd, od, ...);
bool success = (exit_status == 0 || exit_status == OTHER_SUCCESS_VALUE...);
set_status(od, success );
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
Change the two optional boolean parameters into a single optional flags
parameter which uses symbolically defined names. Makes reading the
execute_command() calls much easier to understand. (Implemented as bit
field using the same technique as used for Glib::SpawnFlags [1]).
This changes the calls thus:
execute_command(cmd, od) -> (cmd, od)
execute_command(cmd, od, false) -> (cmd, od, EXEC_NONE) // [2]
execute_command(cmd, od, true ) -> (cmd, od, EXEC_CHECK_STATUS)
execute_command(cmd, od, false, true) -> (cmd, od, EXEC_CANCEL_SAFE)
execute_command(cmd, od, true , true) ->
(cmd, od, EXEC_CHECK_STATUS|EXEC_CANCEL_SAFE)
[1] SpawnFlags bitwise operators in
/usr/include/glibmm-2.4/glibmm/spawn.h.
[2] False and EXEC_NONE are the default values for the optional third
parameter before and after this change respectively and both mean
the same. This is being used in btrfs::resize() and being kept for
now despite it being the default.
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
Add a pattern to recognise Non-Volatile Memory Express devices as valid
devices to work with. Devices are named by the Linux kernel device
driver like /dev/nvme0n1 [1] with partitions named like /dev/nvme0n1p1
[2].
[1] linux 3.3 drivers/block/nvme.c nvme_alloc_ns()
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/nvme.c?id=v3.3#n1351
[2] Contents of /proc/partitions for a partitioned NVME device
$ grep nvme /proc/partitions
259 0 390711384 nvme0n1
259 1 977 nvme0n1p1
259 2 31250000 nvme0n1p2
259 3 328209496 nvme0n1p3
259 4 31249408 nvme0n1p4
Bug 755022 - gparted doesn't recognize nvme devices
The ntfs-3g package previously provided the FUSE based NTFS driver to
mount the file system and ntfsprogs provided the user space tools. In
April 2011 the packages have merged [1] forming ntfs-3g_ntfsprogs. Arch
Linux / Debian / Slackware / Ubuntu now just have an ntfs-3g package
with everything; where as CentOS / Fedora / openSUSE are sticking with
the original two package names. Reverse the order of the needed
packages to:
ntfs-3g / ntfsprogs
[1] Release: NTFS-3G + NTFSPROGS 2011.4.12
http://www.tuxera.com/release-ntfs-3g-ntfsprogs-2011-4-12/
For reiserfs the upstream package is named reiserfsprogs. Arch Linux /
Debian / Slackware / Ubuntu use this name; but CentOS / Fedora name it
reiserfs-utils and openSUSE names it just reiserfs. Update the README
file with all 3 package names.
reiserfsprogs / reiserfs-utils / reiserfs
In the File System Support dialog just use the first 2 package names as
we don't want to make the dialog too wide with all 3 names and hopefully
on openSUSE it is more obvious that the reiserfs package is needed to
support the reiserfs file system.
NOTE:
Again this slightly increases the width of the File System Support
dialog on my CentOS 6 desktop with default fonts, now from 676 to 707
pixels. Again still well within the 800 wide target and still narrower
than the main window.
Bug 753436 - Update documentation of GParted software dependencies
In Fedora bug report:
Bug 1176108 - Warning shown on BTRFS partition because of missing btrfs-tools package
https://bugzilla.redhat.com/show_bug.cgi?id=1176108#c0
The user said:
However there is no btrfs-tools package in the standard Fedora repo.
There is a btrfs-progs package, which is already installed. It's
unclear whether this is a real error or simply a mismatched package
name.
The upstream software is named btrfs-progs. Arch Linux / CentOS /
Fedora / Slackware use the upstream name. Debian / Ubuntu name it
btrfs-tools and openSUSE calls it btrfsprogs (no dash).
Rename the needed software to:
btrfs-progs / btrfs-tools
Upstream name first separated by slash from alternative names
distributions use.
NOTE:
This slightly increases the width of the File System Support dialog on
my CentOS 6 desktop with default fonts, from 655 to 676 pixels. Still
well within the 800 wide target and still narrower that the main window.
Bug 753436 - Update documentation of GParted software dependencies
This message would be displayed as part of the details for an operation
to create or format a partition as LVM2 PV on a disk using partition
table types dvh or pc98, which don't have an lvm flag.
v Format /dev/sdb1 as lvm2 pv
> calibrate /dev/sdb1
> clear old file system signatures in /dev/sdb1
> set partition type on /dev/sdb1
Skip setting unsupported partition flag: lvm
> create new lvm2 pv file system
Translators found this message difficult to translate, as reported in
bug 752901 - Add translator comment or fix string. It is also only
standard practice to set the lvm flag on partitions containing LVM2 PVs,
and not required. In hindsight reporting that an operation was skipped,
when the operation is not a necessity, is probably bad practice as it
could lead to uncertainty on behalf of the user and questions as to why
the flag isn't supported. Just remove the message.
Correct the colour name comment for NILFS2.
Colour for LVM2 PV was a Medium Brown. This is close to Face Skin Dark
from the GNOME colour palette. Use this instead.
Make colour for ReFS a bit darker so it is more distinct from the colour
for NTFS.
Add translation comments to improve the clarity of some translatable
text strings regarding setting partition flags.
Bug 752901 - Add translator comment or fix string
Opening the Resize/Move dialog on a logical partition causes GParted to
crash. This crash affects current GParted GIT HEAD, but does not affect
GParted 0.22.0. Git bisect identifies that it was broken with the
following commit:
Remove Set_Data() from the copy, resize/move and new dialog class APIs
7a4a375ed6
The problem was trying to treat the reference display_partitions_ref
like a pointer, and in particular on line 1732 trying to make it refer
to the a different vector of partitions, .logicals sub-vector.
1721 void Win_GParted::activate_resize()
1722 {
...
1726 std::vector<Partition> & display_partitions_ref = display_partitions;
1727 if ( selected_partition_ptr->type == TYPE_LOGICAL )
1728 {
1729 unsigned int ext = 0 ;
1730 while ( ext < display_partitions.size() && display_partitions[ext].type != TYPE_EXTENDED )
1731 ext++;
* 1732 display_partitions_ref = display_partitions[ext].logicals;
1733 }
1734
1735 Dialog_Partition_Resize_Move dialog( gparted_core.get_fs( selected_partition_ptr->filesystem ),
1736 *selected_partition_ptr,
1737 display_partitions_ref );
What was actually happening was that the .logicals sub-vector was being
copied, replacing the display_partitions vector and freeing the original
sub-vector. This left selected_partition_ptr pointing to the original
memory where the selected partition use to exist in the .logicals
sub-vector. At some point in the Dialog_Partition_Resize_Move class
*selected_partition_ptr was referenced, accessing the freed memory.
Crash soon followed.
Fix by using a pointer instead of a reference, which can be assigned to
point to a different object.
Bug 752587 - GParted crashing when opening Resize/Move dialog on
logical partition
Since GParted commit 52a2a9b "Reduce threading (#685740)", released in
GParted 0.15.0, application of operations occurs in the main thread
running the UI, therefore long running libparted actions such as
resizing a FAT16 or FAT32 file system hang the UI for as long as it take
to complete the operation.
https://git.gnome.org/browse/gparted/commit/?id=52a2a9b00a32996921ace055e71d0e09fb33c5fe
Though this problem exists for all libparted actions, it is particularly
noticeable when performing a large resize of fat16/fat32/hfs/hfs+ file
systems.
To address this significant cause of an unresponsive GUI, this
enhancement adds threading to the libparted ped_file_system_resize
function call.
Bug 737022 - UI hangs while running libparted operations such as
FAT16/FAT32 resizing
GParted was also searching the PATH for the availability of the udevadm
and udevsettle commands for every device with a busy partition during a
refresh and for every applied operation effecting a partition table. As
with hdparm previously this was wasteful.
Again, remember the result of searching the PATH at startup and refresh
when clicking on the [Rescan For Supported Actions] button in the File
System Support dialog.
Previously on every refresh for every device, GParted was searching the
PATH to discover if the hdparm command existed. Stracing GParted showed
that calling Glib::find_program_in_path("hdparm") made the following OS
calls:
access("/usr/lib64/qt-3.3/bin/hdparm", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/sbin/hdparm", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/bin/hdparm", X_OK) = -1 ENOENT (No such file or directory)
access("/sbin/hdparm", X_OK) = 0
getuid() = 0
stat("/sbin/hdparm", {st_mode=S_IFREG|0755, st_size=137, ...}) = 0
stat("/sbin/hdparm", {st_mode=S_IFREG|0755, st_size=137, ...}) = 0
The Linux VFS is very fast but repeatedly doing this is wasteful.
Remember the result of searching the PATH for the hdparm command at
startup and refresh this when the [Rescan For Supported Actions] button
is pressed in the File System Support dialog. This is the same as
GParted already does for file system specific commands and their
capabilities.
Bug 751251 - Show serial number in device information
With a Kobo Touch eReader connected via USB, GParted would hang when
scanning the device with this error written to the terminal:
$ sudo src/gpartedbin
======================
libparted : 2.3
======================
(gpartedbin:10261): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g_convert_error
code : 1
what : Invalid byte sequence in conversion input
The hdparm command was printing binary data as the serial number.
Fragment of the 'hdparm -I /dev/sdf' output:
# hdparm -I /dev/sdf
/dev/sdf:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATAPI Optical card reader/writer, with non-removable media
Model Number: {BINARY_DATA}
Serial Number: {BINARY_DATA}
Firmware Revision: {BINARY_DATA}
GParted reads command output using the Glib::IOChannel class. However
by default an IOChannel performs character set conversion on the data it
reads, so when it came across an invalid byte sequence in the binary
data the above exception was raised and the IOChannel::read() method
never returned. Hence GParted became stuck reportedly scanning the
same device forever. Code fragment:
src/PipeCapture.cc
49 bool PipeCapture::OnReadable( Glib::IOCondition condition )
50 {
...
58 Glib::ustring str;
>> 59 Glib::IOStatus status = channel->read( str, 512 );
60 if (status == Glib::IO_STATUS_NORMAL)
61 {
62 for( Glib::ustring::iterator s = str.begin(); s != str.end(); s++ )
Quote from the IOChannel class reference:
https://developer.gnome.org/glibmm/stable/classGlib_1_1IOChannel.html
Note that IOChannels implement an automatic implicit character set
conversion to the data stream, and usually will not pass by default
binary data unchanged. To set the encoding of the channel, use
e.g. set_encoding("ISO-8859-15"). To set the channel to no encoding,
use set_encoding() without any arguments.
Fix by disabling the automatic character set conversion in the IOChannel
used to read output from executed commands.
Bug 751251 - Show serial number in device information
Run "hdparm -I /dev/DISK" to get the hard drive serial number of
every device which has one and display it in the Device Information.
The displayed value can either be the actual serial number, "none" or
blank. "none" means the device doesn't have a hard drive serial number,
such as for Linux software RAID arrays, BIOS fake RAID arrays or USB
flash drives. Blank means something went wrong getting the serial
number. Either it couldn't be found in the hdparm output or the hdparm
command wasn't installed.
Example real hard drive:
# hdparm -I /dev/sda
...
ATA device, with non-removable media
Model Number: SAMSUNG HM500JI
Serial Number: S1WFJDSZ123732
...
Example Linux software RAID array:
# hdparm -I /dev/md127
/dev/md127:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
On my desktop with 4 internal hard drives 2 Linux software RAID arrays
on those hard drives, 2 USB flash drives and 1 USB hard drive attached,
running hdparm 9 times added 0.07 seconds to the device refresh time.
Bug 751251 - Show serial number in device information
Btrfs-progs 4.1, released June 2015, includes support for changing the
UUID of a btrfs file system using the btrfstune command. Check for
availability by looking for the -u option in the btrfstune help output.
Use btrfstune like this:
# umount /dev/sdb1
# btrfstune -f -u /dev/sdb1
Current fsid: e7ad5dba-d721-4f99-990b-1ba2901c8ad2
New fsid: 231563d9-e173-410d-b1da-d34c4319a423
Set superblock flag CHANGING_FSID
Change fsid in extents
Change fsid on devices
Clear superblock flag CHANGING_FSID
Fsid change finished
# echo $?
0
Bug 751337 - btrfstune in btrfs-progs 4.1 supports changing the file
system UUID
Explain why the implementation uses a clear_cache() call, rather than a
straight load_cache() call. This commit from 2014-02-17 implemented
incremental loading of the btrfs device cache:
76e64f2905
Detect busy status of multi-device btrfs file systems (#723842)
The lvm query commands were always run and the cache loaded even if
GParted, actually blkid, didn't identify any LVM2 PVs. (GParted uses
libparted and blkid to identify partition content and the lvm commands
to provide the needed configuration details).
Now implement complete lazy initialization of the cache. Never force
loading of the cache. The cache is only loaded when the first value is
accessed from it. When there are no LVM2 PVs, the cache is never
queried, so never loaded. All the needed infrastructure for delayed
loading was previously added by this commit from 2011-12-11:
ff8ad04120
Lazy initialize the cache from querying LVM2 PVs (#160787)
Every public member function which access values from the cache already
calls initialize_if_required(). Just need to replace force loading of
the cache with a function which just clears the cache.
On my desktop, only when there are no LVM2 PVs, not loading the cache
and therefore not executing these external commands in
load_lvm2_pv_info_cache() saves 1.0 seconds of the 3.7 seconds it takes
to perform the a refresh in GParted:
lvm vgscan
lvm pvs ... -o pv_name,...
lvm pvs ... -o vg_name,...
Bug 750582 - Refactor the LVM2_PV_Info module object interface and
internal cache representation
GParted used to cache the results of the "lvm pvs" commands used to query
the state of the Logical Volume Manager as a series of lines of text.
Then every time a particular value was queried GParted would split all
the lines of text into fields until the required value was found.
Stop this repeat splitting of cached lines of text. Instead parse the
lines of text into separate fields and store in structures of values of
the correct type in the cache.
Bug 750582 - Refactor the LVM2_PV_Info module object interface and
internal cache representation
The LVM2_PV_Info cache had a pretend multi-object interface, yet all the
data is static. An LVM2_PV_Info object doesn't contain any member
variables, yet was needed just to call the member functions.
Make all the member functions static removing the need to use any
LVM2_PV_Info objects.
Bug 750582 - Refactor the LVM2_PV_Info module object interface and
internal cache representation
An LVM2_PV_Info object contains no member variables as all the data is
static (exists once in the program and accessed by all objects). The
constructor did nothing, except when passed true to load the cache.
Provide a separate load_cache() member function and remove the
constructors and destructor which do nothing. The C++ compiler will
provide a default constructor and destructor, which don't do anything as
there are no member variables to initialise and finalise.
This makes the interface a little easier to understand. Mostly a step
along the way of refactoring how the LVM2_PV_Info cache module works.
Bug 750582 - Refactor the LVM2_PV_Info module object interface and
internal cache representation
The copy, resize/move and new dialog classes (Dialog_Partition_Copy,
Dialog_Partition_Resize_Move and Dialog_Partition_New respectively) had
to be used like this:
construct dialog object passing some parameters
call Set_Data() to pass more parameters
run() dialog
call Get_New_Partition()
There is nothing in the classes which forces Set_Data() to be called,
but it must be called for the dialogs to work and prevent GParted from
crashing.
Make these class APIs safer by making it impossible to program
incorrectly in this regard. Move all the additional parameters from
each Set_Data() method to each constructor. The constructors just call
the now private set_data() methods.
The member variable was named selected_partition. It is assigned from
Win_GParted::selected_partition_ptr (which is a pointer to a const
partition object so is never updated). This gives connotations that it
won't be modified.
However it is updated freely as the new resultant partition object is
prepared before being returned from the dialog, most notable in the
Get_New_Partition() methods.
Therefore rename from selected_partition to new_partition.
The code goes like this:
Dialog_Partition_Copy::Get_New_Partition()
call Dialog_Base_Partition::Get_New_Partition()
Update this->selected_partition with results from running
the dialog.
return this->selected_partition by value.
Save value back to this->selected_partition.
Update this->selected_partition some more.
return this->selected_partition by value.
So there is an unnecessary copy of the partition object returned from
the base class Get_New_Partition() function back to the same variable in
the derived copy class Get_New_Partition() function.
Need to keep the base class Get_New_Partition() function as derived
class Dialog_Partition_Resize_Move uses that implementation as it
doesn't override it, and it's part of the interface.
Avoid this unnecessary copy by moving base class Get_New_Partition()
code into a new private function, called prepare_new_partition(), which
doesn't return anything. Then have Get_New_Partition() in both classes
just return the required partition object. Like this:
Dialog_Base_Partition::Get_New_Partition()
call prepare_new_partition()
return this->selected_partition by value.
Dialog_Partition_Copy::Get_New_Partition()
call Dialog_Base_Partition::prepare_new_partition()
Update this->selected_partition some more.
return this->selected_partition by value.
Bug 750168 - Reduce the amount of copying of partition objects
When Operation objects are created they take a copy of the Device object
to which the operation is to be applied. The Device object includes a
vector of all the contained Partition objects currently on the device,
so these get copied too.
These additional deep copied Partition objects in the Operation object
are never accessed. Therefore don't copy the contained Partition
objects when copying the Device object into the Operation object.
Bug 750168 - Reduce the amount of copying of partition objects
When opening the Manage Flags dialog, creation of the dialog object was
creating a copy of the selected partition object. If this was an
extended partition it also included recursively constructing the
contained logical partitions too.
Instead, replace the partition object in the DialogManageFlags class
with a reference to it.
Bug 750168 - Reduce the amount of copying of partition objects
When opening the Partition Information dialog, creation of the dialog
object was creating a copy of the partition object to be displayed. If
this was an extended partition it also included recursively constructing
the contained logical partitions too.
Instead, replace the partition object in the Dialog_Partition_Info class
with a reference to it.
NOTE:
In C++ a reference is really just a pointer under the hood. As such,
dereferences of a pointer to an object in the context of needing a
reference to the object doesn't copy the object. It merely initialises
the reference from the pointer.
Specifically, with this prototype:
Dialog_Partition_Info( const Partition & partition );
and the dialog object being constructed in Win_GParted::activate_info():
Dialog_Partition_Info dialog( *selected_partition_ptr );
the partition object is not copy constructed. A reference (pointer) to
it is merely passed to the dialog constructor.
Bug 750168 - Reduce the amount of copying of partition objects
The first actions of Win_GParted::activate_resize() were to create a
copy of the vector of partitions for the currently displayed device and
visually apply any pending operations. Exactly this has already been
done in Win_GParted::Refresh_Visual() with the result now available in
the member variable display_partitions. Stop this unnecessary partition
object copying and processing by just using display_partitions member
variable instead.
Bug 750168 - Reduce the amount of copying of partition objects
Document how GParted displays partitions in the GUI and manages the
lifetime and ownership of that data.
Bug 750168 - Reduce the amount of copying of partition objects
Further ensure that a bug doesn't get introduced with the use of
selected_partition_ptr, by asserting that it points to a current
partition object in the vector of display partitions.
After deliberately breaking the code so that selected_partition_ptr
points to some other partition object, trying to display the Information
dialog causes this crash:
======================
libparted : 2.4
======================
**
ERROR:Win_GParted.cc:989:void GParted::Win_GParted::set_valid_operations(): assertion failed: (valid_display_partition_ptr( selected_partition_ptr ))
Aborted (core dumped)
At this point in the code:
973 void Win_GParted::set_valid_operations()
974 {
...
986 // No partition selected ...
987 if ( ! selected_partition_ptr )
988 return ;
>> 989 g_assert( valid_display_partition_ptr( selected_partition_ptr ) ); // Bug: Not pointing at a valid display partition object
Bug 750168 - Reduce the amount of copying of partition objects
Add Glib g_assert() to ensure that a bug doesn't get introduced which
allows a partition callback to be called without a partition being
selected first.
After deliberately breaking the code so that selected_partition_ptr is
not set, trying to display the Information dialog causes this crash:
# ./gpartedbin
======================
libparted : 2.4
======================
ERROR:Win_GParted.cc:1978:void GParted::Win_GParted::activate_info(): assertion failed: (selected_partition_ptr != NULL)
Aborted (core dumped)
At this point in the code:
1976 void Win_GParted::activate_info()
1977 {
>> 1978 g_assert( selected_partition_ptr != NULL ); // Bug: Partition callback without a selected partition
1979
Bug 750168 - Reduce the amount of copying of partition objects
Now that TreeView_Details and DrawingAreaVisualDisk classes store and
pass pointers to partition objects in the Gtk signal callbacks, change
the selected partition into a pointer too.
Bug 750168 - Reduce the amount of copying of partition objects
This stops copying of each displayed partition object into the
DrawingAreaVisualDisk class.
Bug 750168 - Reduce the amount of copying of partition objects
This stops copying of each displayed partition object into the
TreeView_Details class.
It also stops copy constructing lots of partition objects when just
clicking on a partition in the disk graphic. The disk graphic needs to
inform the main GUI and then the partition list which partition has been
selected. The call sequence goes like:
DrawingAreaVisualDisk::on_button_press_event(event)
Win_GParted::on_partition_selected(partition_ptr, src_is_treeview)
TreeView_Detail::set_selected(partition_ptr)
TreeView_Detail::set_selected(rows, partition_ptr,
inside_extended)
Relevant source and highlighted comparison line:
140 bool TreeView_Detail::set_selected( Gtk::TreeModel::Children rows,
141 const Partition * partition_ptr, bool inside_extended )
142 {
143 for ( unsigned int t = 0 ; t < rows .size() ; t++ )
144 {
>> 145 if ( static_cast<Partition>( rows[t][treeview_detail_columns.partition] ) == *partition_ptr )
146 {
147 if ( inside_extended )
148 expand_all() ;
149
150 set_cursor( static_cast<Gtk::TreePath>( rows[ t ] ) ) ;
151 return true ;
152 }
153
154 if ( set_selected( rows[t].children(), partition_ptr, true ) )
155 return true ;
156 }
157
158 return false ;
159 }
Then in this function the partition selected in the disk graphic
(partition_ptr parameter) is compared in turn with each partition object
stored in the Gtk::TreeView model to find the matching one to mark it as
selected. This mere act of accessing the partition object stored in a
row of the Gtk::TreeView model causes it to be copy constructed. So
clicking on the 5th partition in the disk graphic will copy construct
the first 5 partition objects just to do a compare to find the matching
one.
This is because it is not possible to get a reference from a
Gtk:TreeViewProxy in gtkmm. Merely accessing a value in a Gtk::TreeView
model takes a copy of that value.
Subject: get a reference from a Gtk::TreeValueProxy
http://comments.gmane.org/gmane.comp.gnome.gtkmm/2217http://marc.info/?t=104400417500001&r=1&w=4
Bug 750168 - Reduce the amount of copying of partition objects
Change from passing a reference to the selected partition, to passing a
pointer to the selected partition in the signal_partition_selected
callbacks between the disk graphic, partition list and core GUI modules.
This is an enabler for the following patches.
Bug 750168 - Reduce the amount of copying of partition objects
Win_GParted::Refresh_Visual() used a local variable containing a copy of
the vector of partitions in the current device to be displayed. After
visually applying pending operations it loaded copies of each partition
object into the GUI widgets to display the disk graphic and partition
list, DrawingAreaVisualDisk and TreeView_Details classes respectively.
When a partition is selected in the UI, again a partition object is
copied. Also several of the partition dialogs, including the
information dialog, take a copy of the partition object. All these are
copies of the same set of partition objects, those currently being
displayed in the UI.
Move the vector of displayed partitions from a local variable in
Refresh_Visual() to a Win_GParted member variable. This will allow for
the above cases to be changed to used pointers and references to the
same set of partition objects.
The valid lifetime of pointers to elements in this partition object
vector is from one refresh to the next, when the vector is cleared and
repopulated with a new set of partition objects. This is exactly what
is needed as the GUI widgets are reloaded on each refresh, the selected
partition is reset and none of the partition dialog objects exist.
Dialog objects being created and destroyed on each use.
On the other hand some copies of partition objects currently being
displayed, still need to be made because they have lifetimes which need
to last longer than the next call to Refresh_Visual(). Specifically the
source of the copy partition and the partition objects copied into the
in the list of pending operations.
Bug 750168 - Reduce the amount of copying of partition objects
BUF in the copy dialog class, Dialog_Partition_Copy, is use to adjust
limits in 2 cases:
1) Minimum size when copying an XFS file system
Minimum size was set to the used space + 2 * cylinder size (typically
plus ~16 MiB). This commit from 2004-12-20 added it:
a54b52ea33
xfs copy now uses xfsdump and xfsrestore. icw some hacks in the other 2
Issues:
* This is increasing the minimum XFS file system size when copying it,
which doesn't happen in the resize case for other file systems.
* It allows an XFS file system to be created which is smaller than the
minimum size allowed by GParted. Copying an empty XFS file system can
create a new file system as small as 26 MiB. This is smaller than the
minimum GParted allows of 32 MiB because that is the minimum
xfs_repair can handle.
Remove this addition when copying an XFS file system and enforce minimum
file system size.
2) Maximum size when copying a file system into empty space larger than
it's maximum size
Maximum size was set to maximum file system size - cylinder size
(typically minus ~8 MiB). Only applied to FAT16 which has a maximum
file system size set in and can be grown. Added by this commit from
2004-12-15:
10e8f3338d
:get_fs now returns a const reference. in copy and resizedialog
...
* in copy and resizedialog filesystems with MAX set now have a max size of MAX - one cylinder .
Issue:
* This is applying a lower maximum resize when copying the file system
compared to that when creating the file system.
NOTE:
GParted currently allows all file systems to be resize to any size,
regardless of the maximum file system size. This is probably an
oversight, but it does allow libparted to convert FAT16 to FAT32 file
system when resizing.
Remove this lower maximum file system size when copying and resizing,
compared to creating.
Bug 749867 - Some limits are adjusted by arcane cylinder size amount
when copying and resizing in a single operation
This commit from 2010-05-20 removed use of cylinder size increase in the
minimum, and cylinder size decrease in the maximum file system sizes
from the resize/move dialog.
e62a23b5b5
Add partition alignment option to align to MiB (#617409)
This cylinder size limit adjustments were being performed using the
Dialog_Base_Partition::BUF member variable. Now in the
Dialog_Partition_Resize_Move class it is never accessed, and only
unnecessarily set. Move BUF from the common base class into the
Dialog_Partition_Copy class where it is still used.
Bug 749867 - Some limits are adjusted by arcane cylinder size amount
when copying and resizing in a single operation
Avoid long lines, long statements and repeated calls to
gparted_core.get_filesystem_object( selected_partition.filesystem ) by
storing the returned pointer in a local variable.
Needs the previous commit so that the the local variable can be a
pointer to a const FileSystem object instead of a pointer to a
(modifiable) FileSystem object.
The function never modifies any member variables so make it a const
member function.
(FileSystem::get_custom_text() is a virtual function so can't be made
static).
Rename a couple of GParted_Core methods for consistency and to better
distinguish get_filesystem() from get_filesystems() which do completely
unrelated things.
get_filesystem() -> detect_filesystem()
recognise_filesystem_signature() -> detect_filesystem_internal()
Also make detect_filesystem() a static member method as it doesn't use
any member variables. Requirement cascades to get_partition_path().
These member functions are only used within the GParted_Core class and
only operate on the static member variable FILESYSTEM_MAP.
Make both functions private and also make init_filesystems() static.
The FileSystem objects stored in the FILESYSTEM_MAP are allocated once
using new in init_filesystems() but never deleted.
Valgrind output fragment:
# valgrind --leak-check=full ./gparted
==29314== 353 (72 direct, 281 indirect) bytes in 1 blocks are definitely lost in loss record 6,287 of 6,905
==29314== at 0x4A075FC: operator new(unsigned long) (vg_replace_malloc.c:298)
>> ==29314== by 0x46EDA5: GParted::GParted_Core::init_filesystems() (GParted_Core.cc:106)
==29314== by 0x46EC5F: GParted::GParted_Core::GParted_Core() (GParted_Core.cc:96)
==29314== by 0x4A74F4: GParted::Win_GParted::Win_GParted(std::vector<Glib::ustring, std::allocator<Glib::ustring> > const&) (Win_GParted.cc:51)
==29314== by 0x4D600A: main (main.cc:56)
...
==29314== 161 (72 direct, 89 indirect) bytes in 1 blocks are definitely lost in loss record 6,119 of 6,905
==29314== at 0x4A075FC: operator new(unsigned long) (vg_replace_malloc.c:298)
>> ==29314== by 0x46F50C: GParted::GParted_Core::init_filesystems() (GParted_Core.cc:124)
==29314== by 0x46EC5F: GParted::GParted_Core::GParted_Core() (GParted_Core.cc:96)
==29314== by 0x4A74F4: GParted::Win_GParted::Win_GParted(std::vector<Glib::ustring, std::allocator<Glib::ustring> > const&) (Win_GParted.cc:51)
==29314== by 0x4D600A: main (main.cc:56)
GParted_Core.cc source:
102 void GParted_Core::init_filesystems()
103 {
104 FILESYSTEM_MAP[ FS_UNKNOWN ] = NULL ;
105 FILESYSTEM_MAP[ FS_CLEARED ] = NULL ;
>> 106 FILESYSTEM_MAP[ FS_BTRFS ] = new btrfs() ;
...
>> 124 FILESYSTEM_MAP[ FS_XFS ] = new xfs() ;
125 FILESYSTEM_MAP[ FS_BITLOCKER ] = NULL ;
Fix by deleting all FILESYSTEM_MAP pointers. Note that delete on a NULL
pointer is defined by C++ as a safe do nothing operation.
C++ FAQ / Do I need to check for null before delete p?
https://isocpp.org/wiki/faq/freestore-mgmt#delete-handles-null
Fixing this reduces the valgrind reported definitely lost memory blocks
count from 25 down to 6. 19 FileSystem objects deleted and 19 memory
blocks no longer lost.
Bug 749036 - FileSystem objects are memory leaked in init_filesystems()
Background:
GParted_Core::calibrate_partition() reloads the partition path name and
boundary to ensure they are correct before the operation is performed.
(See comments in calibrate_partition() for the reasons why this is
necessary). This also displays details of the partition being modified
in the operation details to inform the user.
The operation object contains these relevant member objects:
* partition_original
Partition before the operation is applied.
* partition_new
Partition as it is intended to be after the operation has been
applied.
* partition_copied (for the copy operation only)
Source partition being copied.
Issues:
GParted_Core::apply_operation_to_disk() was always calibrating partition
object partition_original, but for about half the operations
partition_original was not used and partition_new is used, so should be
calibrated instead.
Copy into an existing partition calibrated three partitions, the source,
destination before and destination after the operation was applied.
This doesn't really make sense in the operation details to the user.
They would expect to only see the source and destination partitions and
don't care about the distinction between the before and after
representation of the destination.
Minor issues:
The previous fix had to copy the correct partition path from the
calibrated partition_original object to the used partition_new object
for the format, label file system, name partition and change uuid
operations.
Calibrate was called for the create operation too, even though the
partition didn't yet exist. It was a no-operation.
Fix:
Stop always calibrating the partition_original object and instead
calibrate the correct partition object in each operation case. For the
copy into existing partition operation only calibrate the right two
partition objects as the user would expect.
Bug 746559 - Various operations fail when following paste into existing
partition
Format, label file system and new UUID operations would fail when
applied in a sequence to the destination partition following a previous
copy-paste operation.
Giving the copy of a file system a new label and a new UUID are the sort
of actions which should be performed when the disk containing the copy
remains attached to the same computer. This really should work.
Fragment of the failing operation details for a copy and label operation
sequence:
+ Copy /dev/sdb1 to /dev/sdb2
+ calibrate /dev/sdb2
+ calibrate copy of /dev/sdb1
+ calibrate /dev/sdb1
+ check the file system on /dev/sdb1 for errors and (if possible fix them
+ copy file system of /dev/sdb1 to /dev/sdb2
+ Set file system label "small-dst" on copy of /dev/sdb1
+ calibrate copy of /dev/sdb1
path: /dev/sdb2 (partition)
...
+ set file system label to "small-dst" on copy of /dev/sdb1
+ e2label copy of /dev/sdb1 "small-dst"
Usage: e2label device [newlabel]
This is failing because the file system specific command is passed
"copy of /dev/sdb1" as the device name. Code sequence:
1) OperationCopy::OperationCopy() sets the real path name of the
partition_new object to "copy of /dev/SRC" for display purposes.
2) GParted_Core::apply_operation_to_disk() calls calibrate_partition()
on partition_original object, restoring the real path name for
object partition_original.
3) apply_operation_to_disk() calls format(), label_filesystem() or
change_uuid() on the partition_new object, which still has the real
path name set to "copy of /dev/SRC". File system specific commands
fail with this as a path name.
Fix by copying the real path name from object partition_original to
partition_new, as is already done for the resize/move operation. Also
apply this fix to the name partition operation, because it uses the
partition_new object and so that it displays the real path name in the
operation details.
Bug 746559 - Various operations fail when following paste into existing
partition
When the partition is named in the Create New Partition dialog, set the
partition name as part of the create partition operation. Currently
this is only supported for GPTs. See
Utils::get_max_partition_name_length() for details.
Bug 746214 - Partition naming enhancements
Add a partition name entry box to the Create New Partition dialog. The
entry box is greyed out (not sensitive) for partition table types which
don't support partition naming. Currently only supported for GPTs. See
Utils::get_max_partition_name_length() for details.
There was a slightly wider gap between the file system combobox row and
the label entry row when there were only three widgets on the right hand
side of the dialog. This has been removed now that there are four
widgets so that they are all evenly spaced and they line up with the
four widgets on the left hand side.
So far the partition name can be entered and previewed, but isn't yet
applied to the disk.
Bug 746214 - Partition naming enhancements
Adding a partition name entry to the Create New Partition dialog will
need access to these two Device methods: partition_naming_supported()
and get_max_partition_length(). The Set_Data() function already takes
two parameters, only_unformatted and disktype, taken from Device member
variables.
Rather than add two more parameters to the Set_Data() function pass the
Device object instead, replacing the current only_unformatted and
disktype parameters.
Bug 746214 - Partition name enhancements
This is a small tidy-up to remove Gtk::Entry method calls on the file
system label entry box in the Create New Partition dialog which serve no
purpose.
filesystem_label_entry.set_activates_default( true );
It trying to make the Create New Partition dialog automatically
close when Enter is pressed with focus in the label entry box.
However this doesn't work, presumably because the default widget for
the dialog is not the Add button. Remove.
filesystem_label_entry.set_text( partition.get_filesystem_label() );
Initialises the text in the entry box with the file system label
from the passed partition object. The label is blank and the entry
box defaults to blank. Achieves nothing. Remove.
filesystem_label_entry.select_region( 0, filesystem_label_entry.get_text_length() );
Highlights the empty text in the entry box. Achieves nothing.
Remove.
NOTE:
The same set of Gtk::Entry method calls in Dialog_FileSystem_Label() and
Dialog_Partition_Name, which are editing the existing file system label
and partition name respectively, do work and have a useful effect so
shouldn't be removed.
Rename Gtk::Entry object entry -> filesystem_label_entry in the
Dialog_Partition_New class. This is in preparation for the introduction
of the partition name entry box in the Create New Partition dialog.
Bug 746214 - Partition name enhancements
Preview of the format operation cleared the partition name, yet when
applied, the partition name reappeared. Fix the preview to reflect
reality.
Bug 746214 - Partition naming enhancements
Previously partition naming had only been implemented for gpt. Make the
code ready to support naming of the other partition table types for
which libparted supports naming. Specifically: amiga, dvh, mac and
pc98 in addition to gpt. Document issues found with some of these
partition table types, which can relatively easily been worked around.
Leave support of naming for partition table types other than gpt
disabled, mostly just to reduce ongoing testing effort, at least until
there is any user demand for it.
Bug 746214 - Partition naming enhancements
Allow partition names to be changed whether or not the partition is
busy, rather than only when not busy, because it doesn't effect the busy
file system or change the partition boundaries in any way.
Bug 746214 - Partition naming enhancements
Attempting to create a new partition on a pc98 partition table fails
with the following libparted error:
The flag 'lvm' is not available for pc98 disk labels.
This has been broken since LVM2 Physical Volume read-write support was
first added in this commit:
c3ab62591b
Add creation of LVM2 PVs (#670171)
Fix by only clearing and setting the lvm partition flag when the type of
the partition table supports it. When creating a partition to contain
an LVM2 PV and the lvm flag is not support add the following message to
the operation results to explain that setting the lvm partition flag was
skipped and why:
Skip setting unsupported partition flag: lvm
Bug 746204 - Creating partitions on pc98 table fails with lvm flag not
available
Refactor GParted_Core::set_partition_type().
1) Set lp_partition variable earlier and use a single if lp_partition
set condition, rather than in both if conditions for the normal file
system case and the LVM2 Physical Volume case.
2) Stop calling Utils::get_filesystem_string() multiple times, instead
save the result in a local variable.
Tidies the code a little and reorders it in preparation for the
following fix to only set the lvm partition flag when support, making
that code change simpler.
Bug 746204 - Creating partitions on pc98 table fails with lvm flag not
available
resize_move() and move() stopped using the device parameter in this
commit from 2006-07-23:
d663c3c277
removed cylindersize buffering during resize from the filesystems. It is
create() stopped using the device parameter in this commit from 2006-03-19:
ad9f2126e7
fixed issues with copying (see also #335004) cleanups + added FIXME added
For reference most other operation methods had the device parameter
removed in this earlier commit from 2005-12-07:
642f0a145b
from now on each partition has a reference to it's device. make use of new
When the following conditions were met GParted would fail to recognise a
newly created whole disk device file system, and instead show an unknown
file system filling the disk:
1) Disk was previously partitioned and contained at least one partition.
2) Using libparted version 2.0 to 3.0 inclusive.
Initial status:
# blkid | fgrep sdc
# fgrep sdc /proc/partitions
8 32 976762584 sdc
8 33 104857600 sdc1
# parted /dev/sdc
GNU Parted 2.4
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 107GB 107GB primary
When creating the loop partition table libparted would not inform the
kernel to delete the old partitions. /proc/partitions still contained
the details of the old partitions.
(parted) mktable loop
Warning: The existing disk label on /dev/sdc will be destroyed and
all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
(parted) print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Number Start End Size File system Flags
(parted) quit
# fgrep sdc /proc/partitions
8 32 976762584 sdc
8 33 104857600 sdc1
Creation of the whole disk device file system goes unnoticed by blkid
because the kernel and therefore blkid's cache have stale partition
information.
# mkfs.xfs -f /dev/sdc
# blkid | fgrep sdc
NOTE:
On a Linux Software RAID array, as opposed to a hard disk, blkid does
notice creation of the whole disk device file system. However the
kernel still has old partition details.
This was fixed in libparted 3.1 by commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=f5c909c0cd50ed52a48dae6d35907dc08b137e88
libparted: remove has_partitions check to allow loopback partitions
Fix by deleting old partitions before creating the loop table when
compiled with a broken version of libparted. The GParted UI provides
no feedback while a new partition table is created, and with some
versions of GTK the UI become unresponsive too, so it is important to be
as fast as possible. Evaluated three different methods, deleting 15 and
22 MSDOS partitions on a physical 5400 RPM hard drive using libparted
2.4:
M1) Delete and commit one partition at a time.
Takes up to 24 seconds to delete 15 partitions. With 22 partitions
libparted always reports finding some of the partitions busy and
unable to inform the kernel about the modifications.
Too slow and doesn't work.
M2) Delete all partitions in one go and commit once.
Takes up to 1.4 seconds to delete either 15 or 22 partitions. Never
removes partitions 17 and higher from the kernel.
Doesn't work.
M3) Write GPT table (letting libparted delete any old partitions).
Takes up to 0.8 seconds to delete either 15 or 22 partitions.
Fast and works.
Use method 3 - write a GPT table thus using libparted code to inform the
kernel of the old partition deletions.
Bug 743181 - Add unpartitioned drive read-write support
Older versions of blkid don't correctly distinguish between FAT16 and
FAT32 file systems when overwriting one with the other. This effects
GParted too with these file systems on whole disk devices where only
blkid is used to recognise the contents. See previous fix for why only
blkid is used in this case:
Avoid whole disk FAT being detected as MSDOS partition table
(#743181)
Example:
# blkid -v
blkid from util-linux 2.20.1 (liblkid 2.20.0, 19-Oct-2011)
# mkdosfs -F16 -I /dev/md1
# blkid | fgrep md1
/dev/md1: SEC_TYPE="msdos" UUID="7C23-95D9" TYPE="vfat"
# mkdosfs -F32 -I /dev/md1
# blkid | fgrep md1
/dev/md1: SEC_TYPE="msdos" UUID="7F93-98F4" TYPE="vfat"
So blkid recognised the UUID changed but didn't remove the SEC_TYPE for
the FAT32 file system. See FS_Info::get_fs_type() as it uses this to
distinguish between FAT16 and FAT32. This is a caching update bug in
blkid, because telling blkid not to use the cache gets the right
results:
# blkid -c /dev/null | fgrep md1
/dev/md1: UUID="7F93-98F4" TYPE="vfat"
With testing determined that blkid from util-linux 2.23 and later are
not affected and earlier versions are affected. Mostly recently known
affected distribution is Ubuntu 14.04 LTS with util-linux 2.20.1.
The straight forward fix would be to instruct blkid to not use its cache
with 'blkid -c /dev/null'. But using blkid's cache is needed to prevent
blkid hanging for minutes when trying to access a non-existent floppy
drive when the BIOS is set incorrectly. See commit:
18f863151c
Fix long scan problem when BIOS floppy setting incorrect
Instead, when using an older affected version of blkid and when blkid
cache reports a vfat file system, run blkid again bypassing the cache.
The device is known to exist and contain a vfat file system, just not
whether it is a FAT16 or FAT32 file system, so can't be a non-existent
floppy device and won't hang.
Bug 743181 - Add unpartitioned drive read-write support
Libparted 1.9.0 to 2.3 inclusive, recognises whole disk device FAT file
systems as MSDOS partition tables. This causes GParted to do the same.
# dd if=/dev/zero bs=1M of=/dev/md4
# mkdosfs -F32 -v -I /dev/md4
# blkid /dev/md4
/dev/md4: UUID="53FE-31F2" TYPE="vfat"
# parted /dev/md4
GNU Parted 2.1
Using /dev/md4
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Unknown (unknown)
Disk /dev/md4: 536MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
(parted) quit
# /tmp/parted24/bin/parted /dev/md4
GNU Parted 2.4
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Linux Software RAID Array (md)
Disk /dev/md4: 536MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 536MB 536MB fat32
(parted) quit
This was fixed in libparted 2.4 by commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=616a2a1659d89ff90f9834016a451da8722df509
libparted: avoid regression when processing a whole-disk FAT partition
Make GParted immune to this bug by moving blkid performed whole disk
device file system detection before libparted partition detection. Also
have to always erase old file system signatures on whole disk devices
when creating new partition tables to ensure that blkid doesn't detect
those old signatures before libparted has a chance to detect the new
partition table.
Bug 743181 - Add unpartitioned drive read-write support
When writing "loop" partition table over the top of some whole disk
device file system types GParted continued to show those whole disk
device file systems rather than the virtual unknown partition from the
"loop" partition table.
This affected btrfs, jfs, reiser4 and reiserfs. It occurred because of
several factors:
1) Libparted only zeroed the first and last 9.5 KiB (assuming 512 byte
sectors) of the device before writing a new partition table. See
ped_disk_clobber().
2) These file systems have their super blocks and therefore signatures
after the first 9.5 KiB.
3) Whole disk device file system detection is performed using blkid
before checking for a libparted "loop" partition table. See
GParted_Core::set_devices_thread().
Ref:
libparted 3.2: disk.c:ped_disk_clobber()
http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/disk.c?id=v3.2#n302
Fix by always erasing any possible file system signatures on the device
before creating a new "loop" partition table.
NOTE:
This is typically taking up to 0.5 seconds in my testing on a 5400 RPM
hard drive, during which time the GParted UI is hung and the create
partition table dialog shows the apply button pressed but no other
progress indication.
Bug 743181 - Add unpartitioned drive read-write support
Creating a new partition table was getting libparted to read any
existing partition table before creating a new partition table on the
device. This is an unnecessary step, and if the device didn't already
contain a partition table also printed this error from libparted:
/dev/sdb: unrecognised disk label
Since get_device_and_disk() has been split into two, just call
get_device() instead to just populate the PedDevice object representing
the disk device. Removes a small unnecessary step.
Bug 743181 - Add unpartitioned drive read-write support
The preview of clearing a whole disk device file system was previewing
the same as formatting to all other file system types; as a cleared file
system spanning the whole disk device. However when implemented this
removes all signatures on the disk so it actually becomes an unallocated
and unpartitioned device. Make the preview match what happens in when
implemented.
GParted previously used mydevice.max_prims = -1 to represent an
unpartitioned device. It is now represented as:
mydevice.max_prims = 1
mydevice.disktype = _("unrecognized")
mydevice.partitions[0].type = TYPE_UNALLOCATED
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_UNALLOCATED
and the check for an unpartitioned device in Win_GParted.cc becomes:
partitions[0].type == TYPE_UNALLOCATED && partitions[0].whole_device
Bug 743181 - Add unpartitioned drive read-write support
Previously GParted displayed a device containing the parted "loop"
partition table signature "GNU Parted Loopback 0" and nothing else, as
an unrecognised device.
Now make GParted display this as a virtual whole disk device partition
with unknown contents, complete with the unable to detect a file system
warning. This change then allows a whole disk device file system to be
created with the following two steps:
1) Create "loop" partition table on a device;
2) Format to required file system.
GParted represents a whole disk device file system as:
mydevice.max_prims = 1
mydevice.disktype = "none"
mydevice.partitions[0].type = TYPE_PRIMARY
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_EXT4 (example)
Now represents just Parted's "loop" signature as:
mydevice.max_prims = 1
mydevice.disktype = "loop"
mydevice.partitions[0].type = TYPE_PRIMARY
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_UNKNOWN
And as before, an unpartitioned device as:
mydevice.max_prims = -1
mydevice.disktype = _("unrecognized")
mydevice.partitions[0].type = TYPE_UNALLOCATED
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_UNALLOCATED
Bug 743181 - Add unpartitioned drive read-write support
Only allow resizing, not moving of a whole disk device file system.
There is no actual partition to move and moving a file system away from
the start of a disk only makes it unrecognisable.
Also don't perform the partition resize step as there's no actual
partition to be resized. Only the file system is being resized.
(Libparted actually allows the virtual partition spanning a whole disk
device to be resized, implementing it as a no-operation, but only for
recognised file systems. For unrecognised file systems it fails with
"unrecognised disk label").
Note that the existing resize dialog was designed for resizing partition
boundaries, and their contained file systems, not for resizing file
systems within a fixed boundary. The difference is noticeable when
there is unallocated space because the file system doesn't fill the
whole disk device. The dialog starts resizing a virtual partition the
size of the whole disk device, not the actual size of the file system.
Leave addressing this for a possible future update.
Bug 743181 - Add unpartitioned drive read-write support
First, copying into a whole disk device fails on the set partition type
step. Fails with either libparted error "The flag 'lvm' is not
available for loop disk labels" or "unrecognised disk label" depending
whether libparted recognised the content and created a virtual partition
or not. (This is with libparted 2.4).
Fix by just skipping setting the partition type on whole disk devices.
Second, if any file system specific tools are used during the copy, they
will fail because they are passed the device name as "copy of /dev/SRC"
instead of "/dev/DST". Occurs when either the destination whole disk
device is not an identical size to the source so the file system check
and grow steps are added, or when file system specific tools are used to
copy the file system as with XFS or recent EXT2/3/4 tools.
Fix by re-adding the real partition path from libparted for whole disk
devices, as is already done for partitioned device names in
GParted_Core::calibrate_partition().
Bug 743181 - Add unpartitioned drive read-write support
Creation of reiserfs file system fails in GParted with the this error.
# mkreiserfs -f --label "" /dev/sdb < /dev/null
mkreiserfs 3.6.24
/dev/sdb is entire device, not just one partition!
Continue (y/n):
# echo $?
1
Add second force flag, -f, to the mkreiserfs command to make it work.
Bug 743181 - Add unpartitioned drive read-write support
Creation of ext2/3/4 and ntfs file systems fails in GParted on whole
disk devices with these errors.
# mkfs.ext4 -L "" /dev/sdb < /dev/null
mke2fs 1.42.9 (4-Feb-2014)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n)
# echo $?
1
# mkntfs -Q -v -L "" /dev/sdc
/dev/sdc is entire device, not just one partition.
Refusing to make a filesystem here!
# echo $?
1
Add force flag, -F, to both mkfs commands to make them work.
Bug 683643 - Doesn't properly support partitionless drives.
Formatting a whole disk device fails on the set partition type step with
libparted error "unrecognised disk label". This is because the previous
step just cleared the old file system signatures leaving libparted with
nothing to recognise. Therefore libparted doesn't present a virtual
"loop" partition table.
As there is no partition table, there's no partition and no partition
type. Just skip setting the partition type on whole disk devices.
Bug 743181 - Add unpartitioned drive read-write support
This enables Format to Cleared operation to succeed on whole disk device
file systems even when libparted doesn't recognise the file system.
(Turns out that making calibrate work in the previous commit happened to
make Format to Cleared operation succeed, but only if libparted
recognised the file system on the whole disk device).
Bug 743181 - Add unpartitioned drive read-write support
In the operational results of the calibrate step include the type of the
path GParted is working with, either partition or whole disk device. Do
the same for the create empty partition step too for consistency, even
though it only ever creates partitions. Looks like:
create empty partition
path: /dev/sdb3 (partition)
start: 2099200
end: 4196351
size: 2097152 (1.00 GiB)
calibrate /dev/sdc
path: /dev/sdc (device)
start: 0
end: 1953525167
size: 1953525168 (931.51 GiB)
Makes it explicit to the users what GParted has detected. Helps the
developers when looking at saved results to understand what decisions
were made and why specific steps were performed or not.
Bug 743181 - Add unpartitioned drive read-write support
This enables the Check, Label and New UUID operations to succeed on
whole disk device file systems even when libparted doesn't recognise the
file system.
This benefits reiser4 and lvm2 pv file systems with all versions of
libparted, current version is 3.2, and for nilfs2 with libparted < 2.4.
Bug 743181 - Add unpartitioned drive read-write support
get_device_and_disk() basically calls libparted to get a PedDevice
object representing a disk device and a PedDisk object representing a
partition table. Re-implement get_device_and_disk() using two separate
functions, get_device() and get_disk(), to get one of these objects
each.
No functionality changes with this commit. It enables future commits to
incrementally add support for whole disk devices into GParted without
needing libparted to recognise the contents and create a virtual "loop"
partition table.
Bug 743181 - Add unpartitioned drive read-write support
Enable operations on whole disk devices containing any recognised file
system.
The new partition operation on an empty whole disk device continues to
display the "No partition table found on device /dev/DEVICE" information
dialog.
Specifically unsupported operations:
* Delete -
Deletion of a partition only involves removal of the entry in the
partition table leaving the file system intact on the disk. However
this doesn't work for a whole disk device file system. Instead the
file system signatures would have to be erased which is much more
destructive and virtually impossible to undo. Therefore don't
implement whole disk device file system deletion. Alternatives are
to format the file system to cleared or create a partition table on
the device. Both of these imply overwriting the existing data and
set the expectation that undo is not possible.
* Manage flags -
There's no partition table, so there's no partition, so there's no
flags.
Resize/Move operation is being supported so that a whole disk device
file system can be resized to handle devices which can be resize, such
as those from SANs or Linux Software RAID arrays. The start of the file
system must remain fixed so move won't be allowed.
So far only simple operations work if they don't need libparted support
at all [1], or only need libparted support for the calibrate step AND
the file system on the whole disk device is recognised by libparted [2].
(Needs libparted to provide a "loop" partition, hence the recognition
requirement, so that the calibrate step can successfully read the
virtual "loop" partition table. Doesn't matter whether it's an old
version of libparted and it gets the name of the device wrong as GParted
is already using the whole disk device name anyway).
[1] Operations not needing any libparted support:
Mount on, Unmount, Swapon, Swapoff, Activate and Deactivate
[2] Operations only needing libparted support for the calibrate step:
Check, Label, New UUID
Bug 743181 - Add unpartitioned drive read-write support
Need to be able to take different actions in the GParted_Core partition
manipulation methods and in Win_GParted UI methods to deal with
libparted supported partitions or whole disk devices without a partition
table. Add boolean whole_device to the partition object and set
appropriately to allow for this.
Bug 743181 - Add unpartitioned drive read-write support
As was done with a failed mount operation, include the failed activate/
deactivate command in the error dialog. Two example error dialogs now
look like this:
(-) Could not deactivate swap
# swapoff -v /dev/sdb7
swapoff: /dev/sdb7: swapoff failed: Invalid argument
[ OK ]
(-) Could not unmount /dev/sdb6
# umount -v "/mnt/6"
umount: /mnt/6: not mounted
[ OK ]
On RHEL/CentOS 6, GParted fails to mount nilfs2 file system like this:
# mkfs.nilfs2 /dev/sdb1
# mount /dev/sdb1 /mnt/1
mount: you must specify the filesystem type
This fails because mount internally uses libblkid to determine the file
system type when it is not specified on the command line. However on
RHEL/CentOS 6 libblkid is too old to recognise nilfs2.
GParted used libparted recognition first and blkid second. Mount only
uses libblkid. When there are multiple signatures on a partition
GParted may report a different result to blkid alone. Therefore fix by
first trying to mount the file system without specifying the type, as is
already done, and if that fails, trying specifying the file system type.
This allows GParted to mount nilfs2 file systems.
# mount -t nilfs2 /dev/sdb1 /mnt/1
# mount | fgrep sdb1
/dev/sdb1 on /mnt/1 type nilfs2 (rw,gcpid=30946)
And for unsupported file systems the error dialog from the failed mount
command shows both commands like this:
(-) Could not mount /dev/sdb3 on /mnt/3
# mount -v /dev/sdb3 "/mnt/3"
mount: unknown filesystem type 'reiser4'
# mount -v -t reiser4 /dev/sdb3 "/mnt/3"
mount: unknown filesystem type 'reiser4'
[ OK ]
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
Function Utils::get_filesystem_kernel_name() returns the name of the
file system as needed for use in the mount command:
mount -t TYPE DEVICE DIR
Needed because the kernel / mount name is 'hfsplus' where as libparted /
GParted, as reported by Utils::get_filesystem_string(), calls it 'hfs+'.
So far just added debugging when mounting a file system to test the
function works.
# ./gartedbin
======================
libparted : 2.1
======================
DEBUG: (hfsplus) # mount -v /dev/sdb5 "/mnt/5"
DEBUG: (nilfs2) # mount -v /dev/sdb1 "/mnt/1"
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
On RHEL/CentOS 6 GParted fails to mount nilfs2 file system. Include the
failing file system mount command in the error dialog so the user knows
what command failed. The error dialog now looks like:
(-) Could not mount /dev/sdc1 on /mnt/1
# mount -v /dev/sdc1 "/mnt/1"
mount: you must specify the filesystem type
[ OK ]
Also stop telling the dialog that the secondary text contains pango
markup as the command line and error message certainly isn't pango
markup text.
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
GParted can create a nilfs2 file system on RHEL/CentOS 6, yet both
libparted and blkid are too old to recognise it when created. Add
GParted internal detection of nilfs2 file systems.
Easy way to get the required signature needed to recognise nilfs2 is
using wipefs to report the signature bytes it erases, using a more up to
date distribution. So using CentOS 7:
# mkfs.nilfs2 /dev/sdb1
# wipefs -a /dev/sdb1
/dev/sdb1: 2 bytes were erased at offset 0x00000406 (nilfs2): 34 34
Also from util-linux source libblkid/src/superblocks/nilfs2.c
#define NILFS_SB_MAGIC 0x3434
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
For libparted recognised file systems covering the whole disk device,
libparted reports the partition table as "loop". With libparted 3.1 and
earlier, the partition device was reported wrongly as /dev/sdb1, instead
of /dev/sdb, by the ped_partition_get_path() call. This causes GParted
to fail to report file system usage, label and UUID, and busy status.
Also multiple file system tool command errors from using the wrong
device are displayed.
# mkfs.ext4 -L whole-ext4 /dev/sdb
# ./gpartedbin
Example partition errors:
e2label: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
tune2fs 1.42.8 (20-Jun-2013)
tune2fs: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
dumpe2fs 1.42.8 (20-Jun-2013)
dumpe2fs: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
Unable to read the contents of this file system!
Because of this some operations may be unavailable.
This cause might be a missing software package.
The following list of software packages is required for ext4 file
system support: e2fsprogs v1.41+.
This also breaks most of the manipulation operations, again because it
is using the wrong device name.
Fix by ignoring libparted's "loop" partition table and just let it get
displayed via the "none" partition table mechanism.
Doing this renders the direction taken in bug 683643 to make GParted
work with libparted "loop" partition tables mute, as GParted no longer
works with such partition tables. Instead they are replaced by "none"
partition tables within GParted.
Bug 683643 - Doesn't properly support partitionless drives
https://bugzilla.gnome.org/show_bug.cgi?id=683643
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
So that, even though the menu item is greyed out, it is correctly named
Activate or Deactivate for an LVM2 Physical Volume on a whole disk
device, rather than the default Mount or Unmount.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
At this time we are providing read-only support for file systems on
whole disk devices. Also all manipulation operations fail at the
calibrate step with libparted error "unrecognised disk label", and
manage flags is for real partitions only.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
For file systems which libparted recognises, when found on the whole
disk device, it reports with partition table "loop" and a partition
covering the whole disk. GParted duly displays this to the user.
For file systems which libparted doesn't recognise it reports
"unrecognised disk label". As of the latest libparted 3.2, these file
system aren't recognised and can't currently be shown when on the whole
disk device:
BitLocker, Crypt LUKS, exFAT, F2FS, LVM2 Physical Volume,
Linux Software RAID, ReFS, Reiser 4
So only when libparted doesn't recognise a file system on the whole disk
device and GParted does, either via blkid or it's internal code, display
this with partition table "none".
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Move code which queries the file system label and UUID of a partition
into a separate helper function.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Make GParted_Core::get_filesystem() capable of recognising file system
signatures on whole disk devices. Pass NULL for lp_partition to make it
read signatures from the whole disk rather than a specific partition.
Add debugging to test it works.
# fgrep sdb /proc/partitions
8 16 8388608 sdb
# lvm pvcreate /dev/sdb
Writing physical volume data to disk "/dev/sdb"
Physical volume "/dev/sdb" successfully created
# ./gpartedbin
======================
libparted : 1.8.1
======================
Unable to open /dev/sdb - unrecognised disk label.
DEBUG: /dev/sdb (lvm2 pv)
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Used 'fstype' as the name of local variable storing the FILESYSTEM
enumeration type.
'fs_type' was the name of the local variable storing the string with the
name of the file system type. Rename it to 'fsname' to distinguish it
from the aforementioned variable.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Refactor GParted internal file system signature detection to remove code
duplication. There were 5 separate copies of code to: allocate a
buffer, open, read and close the device, free the buffer and compare the
signature.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
(1) Add recognition of LUKS signatures detected by blkid command, via
the FS_Info cache.
(2) Relocate internal GParted detection of LUKS signature to back after
libparted and blkid identification. This reverses previous commit:
7695593d21
Improve crypt-luks detection (#578300)
Bug 578300 must have been caused by either: (1) reading stale data from
the whole disk device, or (2) formatting as LUKS over the top of ext3
leaving old signatures behind. Case (1) has been resolved by commit:
3bea067596
Flush devices when scanning to prevent reading stale signatures
(#723842)
Re-tested case (2) and find that no old signatures are left behind:
# mkfs.ext3 /dev/sda8
# wipefs /dev/sda8
offset type
----------------------------------------------------------------
0x438 ext3 [filesystem]
UUID: 756dcd5f-73c5-4881-81ee-dc88e8b18f42
# cryptsetup luksFormat /dev/sda8
# wipefs /dev/sda8
offset type
----------------------------------------------------------------
0x0 crypto_LUKS [crypto]
UUID: de15ed1a-f461-46b7-803b-d0fd3b4bd680
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Trying to create an XFS file system causes the following error and
the create new xfs file system step to never complete.
# ./gpartedbin
======================
libparted : 2.4
======================
(gpartedbin:15572): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-shell-error-quark
code : 0
what : Text ended before matching quote was found for ". (The text was 'mkfs.xfs -f -L "mylabel" " /dev/sdb8')
Creation of XFS file systems was broken by the extra stray double quote
added to the command before the device name, by commit:
63aeb150ac
Rename member variables and methods in Partition class (#741424)
Bug 744108 - Creating an XFS file system never completes
Encountered this dialog:
Libparted Bug Found!
(-) Invalid argument during seek for read on /dev/md1
[ Retry ] [ Cancel ] [ Ignore ]
After investigation found that GParted was asking libparted to read from
sector -1. Libparted was actually reporting an error but GParted was
incorrectly displaying this as a bug. This was because setting the
dialog title was falling through from the error case to the bug case.
Fix this.
Also provide unique titles for all libparted exception types so that
they can all be distinguished.
* List of exceptions from libparted: enum _PedExceptionType
http://www.gnu.org/software/parted/api/group__PedException.html
Bug 743825 - gparted displaying dialog: libparted bug found!
Provide credit for patch to add support for GPT partition names.
Also indicate significant effort by Sinlu Bes while we tried different
ideas for how GPT partition name support should work.
Embedded devices (Android) use GPT partition names to identify
partitions, instead of file system labels. Add support for viewing and
changing them.
As partition names are used to provide unique identification they are
never copied when copying the contents of one partition to another.
Note that GNU/Linux uses file system labels, UUIDs or device names for
identification during the boot process and afterwards so while partition
names can be used, they are optional and purely for user information.
Bug 741424 - Add support for GPT partition names
This and the following few commits rename variables, methods, classes,
etc from *label_partition* to *label_filesystem* so that the code also
reflects that it is the label of the file system that is being modified
and to separate it from the name partition operation about to be added.
enum OPERATION_LABEL_PARTITION -> OPERATION_LABEL_FILESYSTEM
Bug 741424 - Add support for GPT partition names
Rename the Partition Label concept to File System Label throughout the
GUI. This is to better reflect that it is the label of the file system
that is being modified and to separate it from the Partition Name
concept about to be added.
Bug 741424 - Add support for GPT partition names
GParted reports used figure of active swap space from 4 KiB upwards,
actually 1 page, where as 'swapon -s' reports figures from 0 upwards.
This is because GParted is counting the 1 page swap space overhead as
used space.
# sfdisk -s /dev/sdb1
262144
# mkswap /dev/sdb1
# swapon /dev/sdb1
# swapon -s
Filename Type Size Used Priority
/dev/sdb1 partition 262140 0 -1
For this case GParted reports used as 4 KiB.
(ptn size - swap size = 262144 - 262140 = 4)
Instead make GParted report used figure without any overhead from 0
upwards, matching what 'swapon -s' reports.
Bug 742647 - Swap usage doesn't match figures reported by swapon -s
GParted's internal block copy has an off by one sector bug when the
source is before the destination; and the copy is performed backwards
from high block to low block. It is as though the source and
destination partitions were both one sector earlier on the disk.
In ASCII art it it looks like this:
Initial layout: x<--SRC--><--DST-->
Actually wrote: x<--SRC--
Should have written: <--SRC-->
Affects moving partitions too.
This bug has existed since commit:
bd9e16f22f
Thread the internal copy algorithm (#685740)
Effectively the last sector of the partition is missed and one sector
before the start of the partition is corrupted. Most of the time file
systems don't get around to using the very last sector so didn't notice.
Bug 742920 - GParted internal copy is overstepping partition boundaries
With reiser4progs 1.0.7 and earlier mkfs specifically checks for Linux
kernel 2.5 or 2.6. On Linux 3.x it fails with the following warning:
# mkfs.reiser4 --yes --label "" /dev/sdb1
Warn : Linux 3.13.0-39-generic is detected. Reiser4 does not support
such a platform. Use -f to force over.
# echo $?
8
This is fixed in reiser4progs 1.0.8 and later. From the reiser4progs
SourceForce README.txt:
. Do not ask for confirmation to work under Linux-3.X;
Found on Ubuntu 12.04 LTS and Ubuntu 14.04 LTS both with reiser4progs
1.0.7 and a Linux 3.x kernel.
Fix by adding "--force" flag to the mkfs command line.
Bug 742511 - Creation of reiser4 file systems fails with unsupported
warning
Split the resizing file system and resizing partition calls in
GParted_Core::resize() into separate grow and shrink code paths.
Note that this also changes the degenerative case of calling resize()
when the partition isn't changing size, for non-swap partitions, from a
file system check step to a successful no-op. This doesn't matter as my
testing never found resize() to be called when the partition isn't
changing size.
Also correct spelling of local variable success.
Bug 741211 - Remove unnecessary duplicate actions when resizing a
partition
Shrinking swap partition operation performs these steps:
Shrink /dev/sdb2 from 2.00 GiB to 1.00 GiB
+ calibrate /dev/sdb2
+ check file system on /dev/sdb2 for errors and (if possible) fix them
checking is not available for this file system
+ shrink file system
+ create new linux-swap file system
+ mkswap -L "test-swap" -U "bd381eba-5df7-42e2-8e0e-411e9701c995" /dev/sdb2
+ shrink partition from 2.00 GiB to 1.00 GiB
+ create new linux-swap file system
+ mkswap -L "test-swap" -U "bd381eba-5df7-42e2-8e0e-411e9701c995" /dev/sdb2
Resizing a linux-swap partition was partially special cased in
GParted_Core::resize(). Make it fully special cased so that it just
does the following steps. No more skipped file system checks or extra
resizing.
1) Resize partition,
2) Recreate linux-swap.
This existing call chain recreates the linux-swap:
GParted_Core::resize_filesystem()
linux_swap::resize()
A compound move and resize operation still performs unnecessary checks
and recreates of linux-swap, but less than before.
Bug 741211 - Remove unnecessary duplicate actions when resizing a
partition
Shrinking a partition performs a single file system check step, but
growing a partition still performs two file system checks.
Grow /dev/sda8 from 1.00 GiB to 10.00 GiB
+ calibrate /dev/sda8
+ check file system on /dev/sda8 for errors and (if possible) fix them
+ grow partition from 1.00 GiB to 10.00 GiB
+ check file system on /dev/sda8 for errors and (if possible) fix them
+ grow file system to fill the partition
This is a leftover from the early days of GParted when resizing a
partition used cylinder buffering and performed three file system
checks. See prior to commit:
d663c3c277
removed cylindersize buffering during resize from the filesystems.
Remove the second file system check when growing a partition.
Bug 741211 - Remove unnecessary duplicate actions when resizing a
partition
Simplify how the list of file system types is populated in the Create
New Partition dialog. Change from copying everything and removing
unwanted items to only copying required items. Makes the code simpler
and therefore easier to understand.
Only recognises ReFS file system. No other actions are supported.
Requires blkid from util-linux >= 2.24.
Bug #738471 - ReFS file system is not recognised
Use GParted_Core::supported_filesystem() to remove the need to
explicitly list the growing number of recognised, but otherwise
unsupported, file system signatures in multiple places.
Bug #738471 - ReFS file system is not recognised
Helper to check whether a recognised file system type is supported by
GParted or not. Supported means there is an implementation class and
will appear in the File System Support dialog.
Make supported_filesystem() a static member function so that it can be
called without a class object so that GParted_Core::GParted_Core()
initialiser isn't called multiple times. This requires FILESYSTEM_MAP
to become a static member variable too.
Bug #738471 - ReFS file system is not recognised
get_filesystem_object() takes a constant reference to a FILESYSTEM, but
FILESYSTEM is just an enumeration. So that's a pointer to a constant
int. Just pass by value instead.
RHEL / CentOS 5.6 and later officially support ext4 file system [1].
From RHEL / CentOS 5.3 ext4 file system was included as a technology
preview. Ext4 file system tools are in a separate package e4fsprogs,
using uniquely named commands. The standard e2fsprogs commands only
support ext2 and ext3 file systems.
# mkfs.ext4 /dev/sdb3
# tune2fs -l /dev/sdb3
tune2fs 1.39 (29-May-2006)
tune2fs: Filesystem has unsupported feature(s) while trying to open /dev/sdb3
Couldn't find valid filesystem superblock.
# echo $?
1
# tune4fs -l /dev/sdb3
tune4fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: ba4a9d58-7728-4b47-8a90-80e772615637
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
...
For ext4 only, search for the e4fsprogs specific commands first and the
standard e2fsprogs commands second.
[1] RHEL 5.6 Release Notes, 5. Filesystems and Storage
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/5.6_Release_Notes/ar01s05.html
Bug #738706 - GParted doesn't support ext4 on RHEL/CentOS 5.x
Automatic selection of the largest unallocated partition caused flashing
redraw of the partition graphic and partition list. Both the partition
graphic and partition list were being drawn blank then redrawn fully
populated. This only happened on some distributions including:
CentOS 5.10, 6.5, 7.0, Debian 6, Fedora 14, 20, Xubuntu 14.04 LTS. Did
not happen on: Kubuntu 12.04 LTS.
This is a workaround, not a complete fix. It moves automatic selection
of the largest unallocated partition to after processing of the GTK
Event loop in Refresh_Visual() which redraws the partition graphic and
partition list. These visuals are now drawn only once, fully populated,
however this draws them without the selected partition. The partition
selection is then drawn afterwards which causes the selection to flash
instead. This is significant improvement to the whole partition graphic
and partition list flashing when redrawn.
Bug #696149 - Double refresh of display introduced with default
unallocated space
The device combobox was getting drawn blank, then getting drawn again
with the selected device. This was happening because at the start of
Win_GParted::refresh_combo_devices() the GTK model behind the combobox,
liststore_devices, was cleared, changing the active item, causing the
combobox to get redrawn empty. After the GTK model had been repopulated
the active item was reset causing the comboxbox to get redrawn again,
now showing the selected device. Call flow:
Win_GParted::refresh_combo_devices()
liststore_devices->clear()
//Gtk::Combobox emits signal_change. Registered callbacks
//called.
Win_GParted::combo_devices_changed()
Win_GParted::Refresh_Visual()
...
...
combo_devices.set_active(current_device);
//Gtk::Combobox emits signal_change. Registered callbacks
//called.
Win_GParted::combo_devices_changed()
Win_GParted::Refresh_Visual()
...
This has always been the case, since the device combobox was first added
to GParted before version 0.1 by commit:
3a4b43e0ad
replaced deprecated OptionMenu with ComboBox ...
Fix by temporarily blocking the devices comboxbox from emitting
signal_changed while the GTK model behind the combobox is recreated.
However, since automatic selection of the largest free space was added
[1] in GParted 0.15.0, a more noticeable flashing redraw issue was
caused in which the partition graphic and partition list were both drawn
blank then redrawn fully populated. Some distributions were not
affected by this at all, some only experienced a single flash and others
suffered from two or more flashing redraws. Some affected
distributions: CentOS 5.10, 6.5, 7.0, Debian 6, Fedora 14, 19, 20,
Ubuntu 13.10, Xubuntu 14.04 LTS. Did not occur on Kubuntu 12.04 LTS.
[1] 5b53c12f6e
Select largest unallocated partition by default (#667365)
Bug #696149 - Double refresh of display introduced with default
unallocated space
Automake 1.13 and later generates the following warning when building
GParted from git:
$ ./autogen.sh
...
checking for automake >= 1.9...
testing automake-1.13... found 1.13.4
...
Running automake-1.13...
src/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
...
INCLUDES name has been depreciated since automake 1.7. GParted's
autogen.sh and configure.ac require at least automake 1.9. Therefore
replace automake variable INCLUDES with AM_CPPFLAGS.
Bug #735742 - automake warns INCLUDES is deprecated
Use AC_ARG_ENABLE() and AS_HELP_STRING() macros to improve handling of
the --disable-doc option.
Change the names, and sence, of the Autoconf and Automake definitions
used to control building of the help documentation. Reasons are:
(1) Switch from negative to positive statements which are more natural
to comprehend.
(2) Insert HELP in the names from *_DOC to *_HELP_DOC as they control
building of the documentation in the help subdirectory, not the
manual page in the doc directory.
Autoconf: HAVE_DISABLE_DOC -> ENABLE_HELP_DOC
Automake: DISABLE_DOC -> BUILD_HELP_DOC
Bug #734076 - Autodetect parted online partition resizing capability
Currently -lparted is passed to the linker by being hard coded in the
gpartedbin_LDFLAGS variable in src/Makefile.am and -lparted-fs-resize
by conditionally being appended to the gpartedbin_LDFLAGS.
Add an Autoconf AC_CHECK_LIB check for the parted library using it's
default action-if-found to extend LIBS. Update the existing
AC_CHECK_LIB check for the parted-fs-resize library so that the
overridden action-if-found also extends LIBS with -lparted-fs-resize.
These libraries are then assigned via the LIBS variable in the
generated Makefiles.
This matches how the other libraries, dl and uuid, were found in the
configure script and passed to the Makefiles.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Remove HAVE_LIBPARTED_2_2_0_PLUS definition
Rename version specific #define HAVE_LIBPARTED_2_2_0_PLUS into two
separate feature specific names set as required:
Name Set when?
ENABLE_PT_REREAD_WORKAROUND (libparted < 2.2)
USE_LIBPARTED_LARGE_SECTOR_SUPPORT (libparted >= 2.2)
Using feature specific #defines is the standard Autoconf way and makes
the resultant conditional code easier to understand. Still have to
check the version of libparted though.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Remove HAVE_LIBPARTED_3_0_0_PLUS definition
The #define only controls whether fat16 and fat32 file systems are moved
by libparted (for versions <= 2.4) or the GParted internal algorithm
(for libparted versions >= 3.0). See this commit for more details:
0fda1d011d
Enable new fs resize library available with parted-3.1 (#668281)
As nearly all other file system are moved using the GParted internal
algorithm, just always use it to move fat16 and fat32 file systems too.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
This patch changes the reading of the btrfs multi-device membership to
resolve issue 1/2 by ignoring the exit status from the 'btrfs filesystem
show' command and relying on parsing the required information to
determine success or failure.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
Patch 3/4 - btrfs::read_label()
This patch changes the btrfs file system usage reading code to resolve
issue 1/2 by ignoring the exit status from the 'btrfs filesystem show'
command and relying on parsing the required information to determine
success or failure.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
Issue 2/2 - GParted doesn't show label for mounted btrfs file systems
'btrfs filesystem show /dev/PTN' command is used to query details of a
btrfs file system including reading the file system label. When the
file system is mounted the label is no longer enclosed in single quotes,
but only when using btrfs-progs v3.12. This causes GParted to think the
label is blank when the file system is mounted and therefore no longer
display it.
File system label not enclosed in single quotes when mounted:
# fgrep sdb1 /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,relatime,space_cache 0 0
# btrfs filesystem show /dev/sdb1
Label: test1-btrfs uuid: 1f78fa38-2f85-41d3-9be6-ae0356ae9469
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.12
File system label enclosed in single quotes when unmounted:
# umount /dev/sdb1
# btrfs filesystem show /dev/sdb1
Label: 'test1-btrfs' uuid: 1f78fa38-2f85-41d3-9be6-ae0356ae9469
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.12
Removing the single quotes enclosing the label makes the output
identical to that from the older 'btrfs-show' command.
Fix by using a common parser to extract the label from both the
'btrfs filesystem show' and 'btrfs-show' commands which can read the
label with and without enclosing single quotes.
Patch 2/4 - btrfs::read_label()
This patch changes the btrfs file system label parsing code to resolve
issue 1/2 by ignoring the exit status from the 'btrfs filesystem show'
command and relying on parsing the required information to determine
success or failure. Issue 2/2 is also resolved as described above.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
Issue 1/2 - GParted shows warnings for mounted btrfs file systems
'btrfs filesystem show /dev/PTN' command is used to query details of a
btrfs file system. When the file system is mounted the command reports
failed exit status 1, but only when using btrfs-progs v3.14 and v3.14.1.
This causes GParted to: (1) report warnings from the failed commands for
a mounted btrfs file system, (2) fail to determine file system usage
figures and (3) fail to display the mount point and busy indicator for
non-mounting devices in multi-device btrfs file systems. The label is
also read using the secondary blkid method via the FS_Info cache.
Failed exit status 1 when the btrfs file system is mounted:
# fgrep sdb1 /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,space_cache 0 0
# btrfs filesystem show /dev/sdb1
Label: 'test1-btrfs' uuid: 033e6b07-ee6a-4620-a585-8580a2b83275
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.14.1
# echo $?
1
Successful exit status 0 when the btrfs file system is unmounted:
# umount /dev/sdb1
# btrfs filesystem show /dev/sdb1
Label: 'test1-btrfs' uuid: 033e6b07-ee6a-4620-a585-8580a2b83275
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.14.1
# echo $?
0
Fix by ignoring the exit status of the 'btrfs filesystem show' command
and rely on parsing the required information to determine success or
failure. The output from the older 'btrfs-show' command is almost
identical so the same code will parse it in all cases.
Patch 1/4 - btrfs::read_uuid()
This patch changes the secondary method used to read the btrfs UUID to
resolve issue 1/2 as described above.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
While one partition is busy, reformat another partition from the command
line. Afterwards parted/libparted still detects the original file
system and GParted shows errors from the file system specific tools
reporting the new file system doesn't exist. Only limitation is that
the new new file system must be recognised by libparted (or by GParted's
fallback file system signature detection).
Case #1, File system reformatting:
# 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 2149MB 2147MB primary ext2
2 2149MB 4296MB 2147MB primary ext2
# mount | fgrep sdb
/dev/sdb1 on /mnt/1 type ext2 (rw)
# mkfs.xfs -f /dev/sdb2
# blkid /dev/sdb2
/dev/sdb2: UUID="c31823a2-b81b-46fa-8246-0a59695e4834" TYPE="xfs"
# 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 2149MB 2147MB primary ext2
2 2149MB 4296MB 2147MB primary ext2
# e2label /dev/sdb2
e2label: Bad magic number in super-block while trying to open /dev/sdb2
Couldn't find valid filesystem superblock.
# dumpe2fs /dev/sdb2
dumpe2fs 1.41.12 (17-May-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb2
Couldn't find valid filesystem superblock.
Case #2, Removing device from multi-device btrfs:
# btrfs filesystem show /dev/sdb1
Label: none uuid: a05db434-efd5-4e8c-902f-05f89a88b610
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
# mount /dev/sdb1 /mnt/1
# btrfs device delete /dev/sdb2
# btrfs filesystem show /dev/sdb1
Label: none uuid: a05db434-efd5-4e8c-902f-05f89a88b610
Total devices 1 FS bytes used 92.00KB
devid 1 size 2.00GB used 714.25MB path /dev/sdb1
# btrfs filesystem show /dev/sdb2
and GParted reports this error for partition /dev/sdb2:
Unable to read the contents of this file system!
Because of this some operations may be unavailable.
The cause might be a missing software package.
The following list of software packages is required for btrfs
file system support: btrfs-tools.
This is another case of libparted reading from the whole disk device
(/dev/sdb) yet the file system tools use the partition specific block
device (/dev/sdb2), and the Linux buffer cache not providing cache
coherency. Previous scenario was fixed with:
797f0b8eeb
Flush device after wiping a file system (#688882)
This affects libparted 2.0 to 3.1 inclusive and is fixed by:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=fb99ba5ebd0dc34204fc9f1014131d5d494805bc
Revert "linux-commit: do not unnecessarily open partition device nodes"
Fix by calling ped_device_sync() to guarantee cache coherency for each
device during scanning.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
With linux 3.5 and later, the device used to mount a btrfs file system
is updated in /proc/mounts when the previous mounting device is removed
from the file system. Most recent distributions make /etc/mtab a
symbolic link to /proc/mounts. However some still have /etc/mtab as a
plain file only updated by mount and umount, thus showing the old device
name which is no longer part of the file system.
On Ubuntu 13.10, which has /etc/mtab as a plain file managed by mount
and umount:
# mkfs.btrfs /dev/sdb1
# mount /dev/sdb1 /mnt/1
# btrfs device add /dev/sdb2 /mnt/1
# btrfs device delete /dev/sdb1 /mnt/1
# sync
# btrfs filesystem show /dev/sdb1
# btrfs filesystem show /dev/sdb2
Label: none uuid: e47775a6-e5ad-4fb4-9ea4-1570aa5b4009
Total devices 2 FS bytes used 28.00KB
devid 2 size 2.00GB used 272.00MB path /dev/sdb2
# fgrep btrfs /proc/mounts
/dev/sdb2 /mnt/1 btrfs rw,relatime,space_cache 0 0
# ls -l /etc/mtab
-rw-r--r-- 1 root root 842 Apr 15 19:41 /etc/mtab
# fgrep btrfs /etc/mtab
/dev/sdb1 /mnt/1 btrfs rw 0 0
This causes GParted to report /dev/sdb1 as busy and mounted at /mnt/1
when it is no longer mounted. This effects recent releases of Ubuntu,
13.04, 13.10 and 14.04.
Either /etc/mtab is a symlink and is identical to /proc/mounts or
/etc/mtab is a plain file with wrong information. Fix by not reading
mounted file systems from /etc/mtab.
However old distributions only contain 'rootfs' and '/dev/root' device
names for the / (root) file system with '/dev/root' being a block device
rather than a symlink to the true device. For example from CentOS 5.x:
# fgrep ' / ' /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
# ls -l /dev/root
brw------- 1 root root 8, 3 Jun 4 2013 /dev/root
This prevents identification, and therefore busy detection, of the
device containing the / (root) file system. Used to read /etc/mtab to
get the root file system device name.
# fgrep ' / ' /etc/mtab
/dev/sda3 / ext3 rw 0 0
# ls -l /dev/sda3
brw-r----- 1 root disk 8, 3 Jun 4 2013 /dev/sda3
As per commit:
409096f739
improved scanning for root mountpoint (/) ...
but, as discussed above, this contains an out of date device name after
the mounting device has been dynamically removed from a multi-device
btrfs, thus identifying the wrong device as busy. Instead fall back to
reading mounted file systems from the output of the mount command, but
only when required.
# mount | fgrep ' / '
/dev/sda3 on / type ext3 (rw)
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
In a number of cases there may be no btrfs device cache entry. Some of
the reasons why this can occur:
1) Mounting device removed from btrfs on linux <= 3.4 so old mount
point in /proc/mounts;
2) btrfs and btrfs-show commands don't exist;
3) btrfs or btrfs-show command returned non-zero exit status;
4) get_cache_entry() failed to parse output from btrfs filesystem show
or btrfs-show.
Without a valid btrfs device cache entry, busy detection for all member
devices fails. Search the GParted internal mounted partitions map as
the fallback busy detection method. This can only determine if the
mounting device is mounted or not, not any of the other members of a
multi-device btrfs file system.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
GParted doesn't specify the devid when resizing a btrfs file system, so
the kernel defaults to resizing devid 1. On a multi-device btrfs this
may not be the same partition which GParted is resizing. This will
result in file system truncation and corruption. Shrinking the wrong
partition example:
1) Create a btrfs file system spanning 2 partitions:
# mkfs.btrfs /dev/sdb1 /dev/sdb2
# btrfs filesystem show /dev/sdb1
Label: none uuid: 41654265-9840-45c4-aca1-55989da358d6
Total devices 2 FS bytes used 112.00KiB
devid 1 size 2.00GiB used 437.50MiB path /dev/sdb1
devid 2 size 2.00GiB used 417.50MiB path /dev/sdb2
2) Resize /dev/sdb2 down to 1 GiB using GParted. This command was
run:
btrfs filesystem resize 1048576K /tmp/gparted-ddyGRh
which resized devid 1 (/dev/sdb1) to 1 GiB:
# btrfs filesystem show /dev/sdb1
Label: none uuid: 41654265-9840-45c4-aca1-55989da358d6
Total devices 2 FS bytes used 256.00KiB
devid 1 size 1.00GiB used 437.50MiB path /dev/sdb1
devid 2 size 2.00GiB used 417.50MiB path /dev/sdb2
but GParted instead resized /dev/sdb2 to 1 GiB:
# sfdisk -s /dev/sdb1
2097152
# sfdisk -s /dev/sdb2
1048576
Even on a single device btrfs devid 1 may no longer exist if the file
system has had the initial device removed from it. Example:
1) Create a single btrfs file system, add a second device and
remove the first:
# mkfs.btrfs /dev/sdb1
# mount /dev/sdb1 /mnt/1
# btrfs device add /dev/sdb2 /mnt/1
# btrfs device remove /dev/sdb1 /mnt/1
# umount /mnt/1
# btrfs filesystem show /dev/sdb2
Label: none uuid: 2cbf3ac3-1344-472a-a0c7-1476d23bdc9f
Total devices 1 FS bytes used 256.00KiB
devid 2 size 2.00GiB used 480.00MiB path /dev/sdb2
2) Again resize /dev/sdb2 down to 1 GiB using GParted. This
command was run:
btrfs filesystem resize 1048576K /tmp/gparted-ddyGRh
but it failed with:
ERROR: unable to resize 'tmp/gparted-lEyGaY' - No such device
A more informative error message was written to syslog:
# tail -1 /var/log/messages
Mar 12 14:15:01 localhost kernel: btrfs: resizer unable to find device 1
This is with Linux kernel 3.13.5 on Fedora 20, circa March 2014.
Fix by specifying the devid when resizing (part of) a btrfs file system.
Example command specifying devid 2:
btrfs filesystem resize 2:1048576K /tmp/1
This will always work because it is the kernel which interprets the
devid colon size parameter and has always done so since btrfs was first
added to the kernel in version 2.6.32 [1].
Reference:
[1] linux v2.6.32 fs/btrfs/ioctl.c btrfs_ioctl_resize()
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/ioctl.c?id=v2.6.32#n578
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Currently GParted fails to report the usage of a multi-device btrfs file
system if it is mounted or if the used space is larger than the size of
an individual member device. When GParted does display usage figures it
also incorrectly reports the file system wide used figure against every
member device.
Mounted case:
statvfs() provides an FS size which is larger than any individual
device so is rejected. See:
GParted_Core::mounted_set_used_sectors()
Utils::get_mounted_filesystem_usage()
partition .set_sector_usage()
Unmounted case, FS used > device size:
FS used figure is larger than any individual device so free space is
calculated as a negative number and rejected. See:
btrfs::set_used_sectors()
Btrfs has a volume manager layer within the file system which allows it
to provide multiple levels of data redundancy, RAID levels, and use
multiple devices both of which can be changed while the file system is
mounted. To achieve this btrfs has to allocate space at two different
level: (1) chunks of 256 MiB or more at the volume manager level; and
(2) extents at the file data level.
References:
* Btrfs: Working with multiple devices
https://lwn.net/Articles/577961/
* Btrfs wiki: Glossary
https://btrfs.wiki.kernel.org/index.php/Glossary
This makes the question of how much disk space is being used in an
individual device a complicated question to answer. Further, the
current btrfs tools don't provide the required information.
Btrfs filesystem show only provides space usage information at the chunk
level per device. At the file extent level only a single figure for the
whole file system is provided. It also reports size of the data and
metadata being stored, not the larger figure of the amount of space
taken after redundancy is applied. So it is impossible to answer the
question of how much disk space is being used in an individual device.
Example output:
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
Fix by guesstimating the per device used figure as the fraction of the
file system wide extent usage based on chunk usage per device.
Calculation:
ptn fs used = total fs used * devid used / sum devid used
Positives:
1) Per device used figure will correctly be between zero and allocated
chunk size.
Known inaccuracies:
[for single and multi-device btrfs file systems]
1) Btrfs filesystem show reports file system wide file extent usage
without considering redundancy applied to that data. (By default
btrfs stores two copies of metadata and one copy of data).
2) At minimum size when all data has been consolidated there will be a
few partly filled chunks of 256 MiB or more for data and metadata of
each storage profile (RAID level).
[for multi-device btrfs file systems only]
3) Data may be far from evenly distributed between the chunks on
multiple devices.
4) Extents can be and are relocated to other devices within the file
system when shrinking a device.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Linux can only show a single device name in /proc/mounts and /etc/mtab
for each mounted btrfs, even if it is a multi-device file system. So
GParted only shows a mount point for one of the devices in the btrfs, no
matter how many devices are part of the file system.
# mkfs.btrfs /dev/sdb1 /dev/sdb2
# btrfs filesystem show /dev/sdb1
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
# mount /dev/sdb1 /mnt/1
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
GParted only shows the mount point for /dev/sdb1 as /mnt/1, but nothing
for /dev/sdb2.
Make GParted report the same mount point for all devices included in a
multi-device btrfs file system.
Add btrfs specific get_mount_device() method to report the mounting
device, if any, for the btrfs file system in the occupying the device in
question. Uses the existing cache of btrfs file system device
membership. Also extract common code from GParted_Core::
set_mountpoints() into set_mountpoints_helper().
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Busy detection of file systems works by checking if the device is
mounted (appears in the mount_info map). For a multi-device btrfs file
system this will only report one of the devices as busy, not all of
them.
# btrfs filesystem show /dev/sdb1
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
# mount /dev/sdb1 /mnt/1
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
GParted will only report /dev/sdb1 as busy, but not /dev/sdb2.
Add btrfs specific is_busy() method which reports the device as busy if
any of the devices in the btrfs file system are mounted. This uses a
cache which maps device membership in all btrfs file systems. The cache
is cleared on GParted refresh and incrementally populated as each btrfs
partition is checked for busy status.
WARNING:
Removal of the mounting device from a btrfs file system makes it
impossible to determine whether the file system is mounted or not for
linux <= 3.4. This is because /proc/mounts continues to show the old
device which is no longer a member of the file system.
# btrfs device delete /dev/sdb1 /mnt/1
# sync
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
# btrfs filesystem show /dev/sdb1
# btrfs filesystem show /dev/sdb2
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 1 FS bytes used 28.00KB
devid 2 size 2.00GB used 1.02GB path /dev/sdb2
Fixed in linux 3.5 by commit:
Btrfs: implement ->show_devname
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9c5085c147989d48dfe74194b48affc23f376650
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Add static member function GParted_Core::is_dev_mounted() so that other
modules can determine if a particular partition contains a mounted file
system or not.
Make it a static member function so that it can be called without
needing the gparted_core object. Extend to make the group of
manipulated variables (mount_info, fstab_info) and manipulating
functions (init_maps(), read_mountpoints_from_file(),
read_mountpoints_from_file_swaps(), get_all_mountpoints()) static too.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Previous commit:
Make partition busy detection method selectable per file system
(#723842)
causes GParted to no longer detect an unknown mounted file system as
busy.
This is needed because there are many less popular file systems which
Linux can mount but GParted doesn't recognise, such as: Acorn ADFS,
AFFS, BeFS, BFS, etc. Encountering an unrecognised mounted device can
also occur with btrfs on Linux 3.4 and earlier when the mounting device
is deleted from a multi-device btrfs file system. Happens because
/proc/mounts continues to show the original mounting device even after
that device was deleted from the file system.
# mkfs.btrfs /dev/sdb1
# mount /dev/sdb1 /mnt/1
# btrfs device add /dev/sdb2 /mnt/1
# btrfs device delete /dev/sdb1 /mnt/1
# btrfs filesystem sync /mnt/1
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
# blkid /dev/sdb1
# btrfs filesystem show /dev/sdb1
# blkid /dev/sdb2
/dev/sdb2: UUID="9c75647c-217a-4718-bcc7-f3ccd8cc7dc6" UUID_SUB="b5d43630-80d4-42ac-b406-185e97cd5bbe" TYPE="btrfs"
# btrfs filesystem show /dev/sdb2
Label: none uuid: 9c75647c-217a-4718-bcc7-f3ccd8cc7dc6
Total devices 1 FS bytes used 28.00KB
devid 2 size 2.00GB used 1.02GB path /dev/sdb2
Reinstate the search for mounted partitions for busy detection even for
unrecognised file system types.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
GParted's primary inbuilt busy detection method is "is the partition
mounted?". A custom method is used for LVM2 PV because its not a
mounted file system.
Make busy detection selectable per file system type.
.fs.busy = FS::NONE (default)
No busy detection.
.fs.busy = FS::GPARTED
Use internal GParted method which checks if the partition is
mounted.
.fs.busy = FS:EXTERNAL
Call the file system type's member function is_busy().
LVM2 PV busy detection changes from a special case to just electing to
call the lvm2_pv::is_busy() method. Linux Software RAID remains a
special case because it's only recognised, but not otherwise supported.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Fragment of debugging and valgrind output:
D: tid=2193 main()
...
D: tid=2202 GParted_Core::set_devices_thread()
...
D: tid=2202 Utils::execute_command(command="dumpe2fs -h /dev/sda1", output, error, use_C_locale=1)
D: tid=2202 this=0x13fef4a0 PipeCapture::PipeCapture()
D: tid=2202 this=0x13fef4f0 PipeCapture::PipeCapture()
D: tid=2202 this=0x13fef4a0 PipeCapture::connect_signal()
D: sourceid=77
D: tid=2202 this=0x13fef4f0 PipeCapture::connect_signal()
D: sourceid=78
D: tid=2193 data=0x13fef4a0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4a0 PipeCapture::OnReadable()
D: signal_update.emit()
D: return true
D: tid=2193 data=0x13fef4f0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4f0 PipeCapture::OnReadable()
D: signal_update.emit()
D: return true
D: tid=2193 data=0x13fef4a0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4a0 PipeCapture::OnReadable()
D: signal_update.emit()
D: return true
D: tid=2193 data=0x13fef4f0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4f0 PipeCapture::OnReadable()
D: signal_eof.emit()
D: return false
D: (!rc) &(pc->sourceid)=0x13fef518
D: tid=2193 data=0x13fef4a0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4a0 PipeCapture::OnReadable()
D: signal_update.emit()
D: return true
D: tid=2193 data=0x13fef4a0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4a0 PipeCapture::OnReadable()
D: signal_update.emit()
D: return true
D: tid=2193 data=0x13fef4a0 PipeCapture::_OnReadable()
D: tid=2193 this=0x13fef4a0 PipeCapture::OnReadable()
D: signal_eof.emit()
D: tid=2202 this=0x13fef4f0 PipeCapture::~PipeCapture()
D: sourceid=0
D: tid=2202 this=0x13fef4a0 PipeCapture::~PipeCapture()
D: sourceid=77
D: return false
D: (!rc) &(pc->sourceid)=0x13fef4c8
==2193== Thread 1:
==2193== Invalid write of size 4
==2193== at 0x490580: GParted::PipeCapture::_OnReadable(_GIOChannel*, GIOCondition, void*) (PipeCapture.cc:56)
==2193== by 0x38662492A5: g_main_context_dispatch (gmain.c:3066)
==2193== by 0x3866249627: g_main_context_iterate.isra.24 (gmain.c:3713)
==2193== by 0x3866249A39: g_main_loop_run (gmain.c:3907)
==2193== by 0x3D7FD45C26: gtk_main (gtkmain.c:1257)
==2193== by 0x469743: GParted::GParted_Core::set_devices(std::vector<GParted::Device, std::allocator<GParted::Device> >&) (GParted_Core.cc:155)
==2193== by 0x4A78F1: GParted::Win_GParted::menu_gparted_refresh_devices() (Win_GParted.cc:1259)
==2193== by 0x4A7886: GParted::Win_GParted::on_show() (Win_GParted.cc:1253)
==2193== by 0x3D82B2009C: Gtk::Widget_Class::show_callback(_GtkWidget*) (widget.cc:3855)
==2193== by 0x3867210297: g_closure_invoke (gclosure.c:777)
==2193== by 0x3867221B86: signal_emit_unlocked_R (gsignal.c:3516)
==2193== by 0x386722A0F1: g_signal_emit_valist (gsignal.c:3330)
==2193== Address 0x13fef4c8 is not stack'd, malloc'd or (recently) free'd
==2193==
PipeCapture.cc (with debugging):
46 gboolean PipeCapture::_OnReadable( GIOChannel *source,
47 GIOCondition condition,
48 gpointer data )
49 {
50 std::cout << "D: tid=" << (long int)syscall(SYS_gettid) << " data=" << data << " PipeCapture::_OnReadable()" << std::endl;
51 PipeCapture *pc = static_cast<PipeCapture *>(data);
52 gboolean rc = pc->OnReadable( Glib::IOCondition(condition) );
53 if (!rc)
54 {
55 std::cout << "D: (!rc) &(pc->sourceid)=" << &(pc->sourceid) << std::endl;
56 pc->sourceid = 0;
57 }
58 return rc;
59 }
The use after free across threads only happens when an external program
is being executed from a thread other than the main() thread. This is
because by default glib registered callbacks are run by the glib main
loop, which is only called from the main() thread with Gtk::Main::run().
Event sequence:
tid=2193 tid=2202
main()
...
GParted_Core::set_devices()
Glib::Thread::create(... set_devices_thread ...)
Gtk::Main::run() GParted_Core::set_devices_thread()
...
Utils::execute_command("dumpe2fs ... /dev/sda1" ...)
Glib::spawn_async_with_pipes()
PipeCapture outputcapture(out, output)
outputcapture.connect_signal()
//Glib main loop runs callback
PipeCapture::_OnReadable()
pc->OnReadable()
//output read
signal_update.emit()
return true
...
//Glib main loop runs callback
PipeCapture::_OnReadable()
pc->OnReadable()
//eof reached
[1] signal_eof.emit()
return status.exit_status
[2] PipeCapture::~PipeCapture()
[3] return false
[4] pc->sourceid = 0
What is happening is that the PipeCapture destructor [2] is running in
the set_devices_thread() thread and freeing the object's memory as soon
as signal_eof.emit() [1] has been called. Then signal_eof.emit()
returns back to OnReadable() which then returns false [3] back to the
_OnReadable() callback function which then assigns 0 to sourceid member
variable [4] in the already freed object, detected by valgrind as:
Invalid write of size 4
at ... GParted::PipeCapture::_OnReadable(...) (PipeCapture.cc:56)
This is happening because PipeCapture member variable sourceid is being
saved, in a different thread, just so the _OnReadable() callback can be
removed. However a glib IOChannel callback, type GIOFunc(), returning
false will be automatically removed.
GLib Reference Manual 2.26 / IO Channels
https://developer.gnome.org/glib/2.26/glib-IO-Channels.html#GIOFunc
GIOFunc()
Returns : the function should return FALSE if the event source
should be removed
Therefore fix by just not saving the event sourceid at all, and not
calling g_source_remove() to manually remove the callback, but instead
letting glib automatically remove the callback when it returns false.
Bug #731752 - Write after free cross thread race in
PipeCapture::_OnReadable()
OperationDetail was storing its children in a std::vector. This means they
can be moved around in memory arbitrarily, going through indeterminate
lifetimes. This is generally a bad thing for any non trivial object and
in the case of OperationDetail, it created havoc with the way it maintains
pointers between parent/child objects for signal connections. It will now
keep only pointers to children in a std::vector instead, so their lifetime
can be controlled, fixing various crashes.
Bug 729139 - Refactor OperationDetail to address random behavior
Returning false from the OnReadable callback causes the source to
be destroyed, but PipeCapture::~PipeCapture was destroying it a
second time. Prevent this by zeroing out the sourceid.
Bug 729800 - Prevent GSource double-destroy warning messages
Place the LVM2 member names in a single string, separated by new lines,
so that they can be selected all together by the user. This was not
previously possible when each member name was placed in a separate
widget.
A LVM volume group can contain more than one member and comprise a
multi-line entry. As such set the "Members" field header and value
label pair to top vertical alignment.
As part of the work on bug 652044 - uses deprecated APIs, selectable
vertical alignment was defaulted to ALIGN_CENTER for all labels. The
relevant commits can be viewed in comment 26 of said bug report.
https://bugzilla.gnome.org/show_bug.cgi?id=652044#c26
For multi-line labels a vertical ALIGN_CENTER value is not
consistently aesthetically pleasing. This becomes obvious when a
single-line heading label is paired with a multi-line value label.
To improve the aesthetics, a vertical alignment of ALIGN_TOP is
preferred.
Hence re-add the ability to optionally specify a vertical alignment for
labels. If a yalign value is not specified a default vertical alignment
of ALIGN_CENTER is used.
With the volume group name displayed immediately below the status field,
the vgname is no longer needed in the status field.
Bug 690542 - Partition Information Dialog Warning not readable
When the partition information dialog is resized, the data below the
partition graphic would remain left aligned. Improve the aesthetics by
horizontally centering the data in the window similar to the partition
graphic.
Bug 690542 - Partition Information Dialog Warning not readable
Placing the LVM2 member names in a string list enables the member names
to be selected all at once by a user. This was not possible with
separate label widgets for each LVM2 member name.
Bug 690542 - Partition Information Dialog Warning not readable
Make the dialog resizable, add a vertical scrollbar to the information
and messages section, and set the initial height to ensure the dialog
fits entirely on an 800x600 screen.
A default height is required because some window managers, such as
fluxbox used in GParted Live, only permit resizing the height by using
the bottom corners of the dialog. If the dialog is too large for the
screen then the user would not be able to resize it.
Note that two default initial heights are used in an effort to minimize
the amount of extra whitespace.
Bug 690542 - Partition Information Dialog Warning not readable
On some desktop environments, such as Unity on Ubuntu 13.04, the
partition information dialog can display the used/unused/unallocated
field values overlapping with the "(##%)" percentage value. The problem
is pronounced for values with 4 digits to the left of the decimal (for
example a 1024 MiB partition ). To address this problem, these
percentages are placed in their own column.
Bug 690542 - Partition Information Dialog Warning not readable
Organize the partition information field & value areas into two columns
to minimize the amount of vertical space required.
This is part of a series of changes to enable viewing all partition
information details on a minimum 800x600 display.
Part of Bug 690542 - Partition Information Dialog Warning not readable
This is part of a series of changes to enable viewing all partition
information details on a minimum 800x600 display.
Part of Bug 690542 - Partition Information Dialog Warning not readable
This is part of a series of changes to enable viewing all partition
information details on a minimum 800x600 display.
Part of Bug 690542 - Partition Information Dialog Warning not readable
The code used to unnecessarily destroy and re-create the file system
objects on every scan for file system support tools.
Instead only create the file system objects once and just call each
object's get_filesystem_support() method on each rescan.
Prior to commit:
1f3b11748e
Remove GParted_Core::p_filesystem (#683149)
set_proper_filesystems() used to set GParted_Core::p_filesystem member
variable to one of the FileSystem objects, but that was just treating it
like a local variable. After the commit local variables named
p_filesystem were used where required and set_proper_filesystem() became
a function which did nothing other than call get_filesystem_object().
Now remove set_proper_filesystem() altogether and use
get_filesystem_object() in its place.
Comment is outdated after GParted stopped using ped_partition_is_busy()
for busy partition detection of normal and logical partitions since
commit:
4202992063
Fix false busy detection of unusual case with Linux Software RAID (#712533)
The String::ucompose method is for easy, i18n-friendly composition of
strings with Gtkmm. From past experience, String::ucompose should not
be used to build command lines due to differences in how locales handle
number translation. More specifically, not all locales use number
separators (spaces, commas or periods) and the decimal separator
(period or comma) in the same way.
The problem with using String::ucompose for command lines was
originally encountered and corrected in the following commit:
Fix attempt data rescue fail to open read-only view (#673246)
e494eca1f7
Use e2image features added in e2fsprogs 1.42.9 to move/copy
an ext[234] file system more efficiently by skipping unused blocks.
Fall back to the internal copy algorithm if e2image is not found
or does not support move/copy.
Bug #721516 - Use e2image to move/copy ext[234] filesystems
Work on bug 701075 inadvertently introduced a problem where ext2/3/4,
resierfs, and ntfs file systems were rounding the file system size up
to the nearest kiB.
The problem was discovered when a user resized a partition by moving
only the start boundary to the right thereby shrinking the partition.
In the situation where the resulting partition size was not an integer
kiB value (such as might occur on a 512 byte per sector device) the
file system size was rounded up to the nearest kiB. This resulted in
a file system size being set one sector larger than the partition
size.
This problem was introduced with the following commit:
Shrink file systems to exact size (#701075)
3461413d28
The fix chosen for this problem involved removing the rounding logic.
Bug 723543 - Shrink ext2/3/4 results in attempt to set partition
smaller than file system
Only recognises partitions containing BitLocker Disk Encryption content.
No other actions are supported.
Bug #723232 - BitLocker Disk Encryption not recognised
Restore the order of the source files so that they are once again
compiled in order A-Z, a-z. Order is obtained with:
fgrep .cc src/Makefile.am | LANG=C sort
fgrep .h include/Makefile.am | LANG=C sort
Make the dialog resizable, add a vertical scrollbar and set the minimum
(and therefore initial) height to 500 pixels. This is so that the
dialog entirely fits on an 800x600 screen, thus allowing the rescan
button to be pressed.
100 pixel difference is to account for the size of the top and bottom
GNOME 2 panels and two sets of title bars. Two sets of title bars
because the window manager tries to place the top of dialog title bars
in line with the bottom of the main window title bar.
Bug #342682 - too much information in 'features' dialog
Use padding to indent the legend narrative to better show hierarchy and
association with the "Legend" category as recommended in the:
GNOME HIG 2.2.3 / Visual Design / Window Layout
https://developer.gnome.org/hig-book/stable/design-window.html.en
Padding the legend narrative widget also deliberately increases the
spacing to the legend icons too.
Bug #342682 - too much information in 'features' dialog
Make the legend always shown, ready for when the dialog is resizable.
Change the widget containing the legend from an expander to a frame
widget. Set the frame to be borderless using a bold label as
recommended in the GNOME Human Interface Guidelines 2.2.1 / Controls /
Frames and Separators.
https://developer.gnome.org/hig-book/2.32/controls-frames.html.en
Bug #342682 - too much information in 'features' dialog
The DialogFeatures::DialogFeatures() constructor used four levels of
nested code blocks and reused the same variable names at multiple
levels. The variable hbox was used at three of the four levels. This
was done by commit:
91b971691d
Bug #634090: Change some attributes to local variables
In my opinion this made the code hard to understand. Give every local
variable a unique and meaningful name and remove the nested code blocks.
This is part of parent bug:
Bug #721455 - Obsolete info in license text on multiple modules
and GNOME Goal:
https://wiki.gnome.org/Initiatives/GnomeGoals/Proposals
* verify all source files to make sure they have a license and a
copyright, and that both are up-to-date
Bug #721565 - License text contains obsolete FSF postal address
Write a loop partition table to a disk and then try to create a new
partition on that disk crashes GParted.
Analysis:
1) Loop partition table, actually just the signature / label
"GNU Parted Loopback 0", is written to the disk.
2) create_partition() calls ped_disk_app_partition() to create the
partition which, arguably erroneously, clears the loop signature.
3) In erase_filesystem_signatures(), get_device_and_disk() fails because
there's no longer a loop signature for libparted to recognise. This
leaves lp_device, lp_disk and lp_partition = NULL, but incorrectly
overall_success = true.
4) Overall_success = true allows the signature erasure loop to run and
evaluate lp_device->sector_size, dereferencing a NULL pointer and
crashing GParted.
Fix erase_filesystem_signatures() to correctly handle failure from
get_device_and_disk(), broken by this commit:
246e05559d
Clear btrfs file system super block mirror copies too (#705426)
Bug #721988 - Crash when creating new partition on disk with loop label
In the Create Partition Table dialog display the entries in the combobox
in order.
Previously the default of MSDOS or GPT was moved to the first item in
the combobox. Now the partition table types remain in order with just
either MSDOS or GPT being selected as as the default as required.
The partition table types are displayed in the order supplied by
libparted, which is alphabetic except with "loop" last.
Bug #711098 - Default partition table can not handle > 2 TiB disks
MSDOS partition table is limited to addressing 2^32 sectors, limiting
disks using 512 byte sectors to 2 TiB in size. Fdisk reports the
following warning on disks 2 TiB and larger.
# truncate -s 2T /var/tmp/loop-2T
# losetup /dev/loop0 /var/tmp/loop-2T
# fdisk /dev/loop0
WARNING: The size of this disk is 2.2 TB (2199023255552 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID
partition table format (GPT).
(Fdisk arguably reports this warning one sector too early. Anyway for
safety and consistency GParted will use this limit too). Continue to
use MSDOS as the default partition table type for disks smaller than 2
TiB and use GPT as the default for disks 2 TiB and larger. This
maximises compatibility.
Also remove the advanced expander and always show the partition table
list box.
Bug #711098 - Default partition table can not handle > 2 TiB disks
When the kernel version as stated in /proc/version did not have at least
three numbers separated by periods, the version would fail to be read.
Sample /proc/version to demonstrate problem:
Linux version 3.10-3-686-pae ...
The Linux kernel will always have a major number and a minor number
separated by a period. There is likely also a patch version number too
that would be preceded by a period. This enhancement will read 2 and 3
component Linux kernel versions.
GParted doesn't report extended partitions as busy if it contains only
busy LVM2 PV or SWRAID logical partitions. Libparted's
ped_partition_is_busy() only detects mounted file systems and swap space
as busy, not active LVM2 PVs or SWRAID members. This is as of libparted
3.1 and earlier.
Fix by determining the busy status of an extended partition based solely
on the busy status of the logical partitions it contains. This makes it
unnecessary to check for mounted DMRAID logical partitions or call
ped_partition_is_busy() for extended partitions.
Bug #712533 - Partitions not detected as busy inside Software RAID on
some distros
In this unusual setup of having one Linux Software RAID array
partitioned and a second array not partitioned, /dev/md1p1 partition in
the first array is falsely reported as busy when the file system filling
the second array /dev/md2 is mounted.
Partition RAID File System Mount mount
--------- ----------------- ---------------- -----------
/dev/sdb1 SWRAID /dev/md1
/dev/md1p1 ext4,Label=test1 (Unmounted)
/dev/sdb2 SWRAID /dev/md2 ext4,Label=test2 /mnt/2
This again affects Debian 6, Debian 7 and RHEL/CentOS 6.x and is as a
result of the this bug fixed in libparted 2.4:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=db52898c214310dab4ed84e6cb2f9ffc8c3aa502
linux: also detect "in-use" dmraid and scsi-Nth (N>=16) partition
Fix by not using libparted's ped_partition_is_busy() to determine if a
normal or logical partition is busy.
Bug #712533 - Partitions not detected as busy inside Software RAID on
some distros
On some distributions GParted doesn't detect when a file system is busy
and mounted when the partition is within a Linux Software RAID array.
Affected distributions include: Debian 6, Debian 7 and RHEL/CentOS 6.x.
This is because of a bug in libparted 2.3 and earlier. It was fixed by
this change in libparted 2.4:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=db52898c214310dab4ed84e6cb2f9ffc8c3aa502
linux: also detect "in-use" dmraid and scsi-Nth (N>=16) partition
Ubuntu 13.10 with libparted 2.3 is not affected because it contains a
distribution specific patch to correct it.
Fix by using GParted's internal mounted partitions map, mount_info, to
determine if a partition is busy, in addition to using libparted's
ped_partition_is_busy().
Bug #712533 - Partitions not detected as busy inside Software RAID on
some distros
Many file systems are capable of growing while mounted, and a few can
even shrink. This support must be explicitly enabled at configure time
with the --enable-online-resize flag and depends on a patched libparted.
Also requires kernel >= 3.6 for partition resizing, even if the
partition is in use (BLKPG_RESIZE_PARTITION).
Thanks to Mike Fleetwood for double check mark idea instead of a second
column to show the online grow/shrink.
Bug #694622 - Add support for online resize
In the Create New Partition dialog use ext4 as the default choice for
new file systems. It has been the preferred file system of
distributions for many years. Use ext3 and ext2 as second and third
choice defaults. This handles RHEL/CentOS 5.x which doesn't support
ext4.
Bug #711114 - Change default fs to ext4
Allow all partition warning messages to be selectable and copied. Merge
all the messages into a single Gtk::Label widget so that they can be
selected together.
Use a blank line between individual messages so that each message can be
distinguished. Therefore each message should be formatted as one or more
non-blank lines, with an optional trailing new line. This is true of
GParted internal messages and probably all external messages and errors
from libparted and executed commands too.
Bug #705596 - Partition Information Dialog - let user copy warnings
Read the contents of /proc/mdstat file to determine if a device is a
member of of an active RAID array.
$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda1[2] sdb1[3]
524224 blocks super 1.0 [2/2] [UU]
md2 : active raid1 sdb2[2] sda2[3](F)
5238720 blocks super 1.1 [2/1] [U_]
md3 : active raid1 sdb3[1]
10477440 blocks super 1.1 [2/1] [_U]
bitmap: 1/1 pages [4KB], 65536KB chunk
md4 : inactive sda4[0](S)
1048564 blocks super 1.2
unused devices: <none>
There are 5 example Linux Software RAID arrays, md1 to md5. All are
RAID1 mirrors with 2 members, in various states.
Array Members Status
md1 sda1, sdb2 Fully operational.
md2 sda2, sdb2 Member sda2 marked as faulty. (Device sda2 is
still in use).
md3 sda3, sdb3 Member sda3 has been removed. (Device sda3 is
not in use).
md4 sda4, sdb4 Incremental start of member sda4 only. (Neither
member devices is in use).
md5 sda5, sdb5 Array stopped. (Neither member device is in
use).
Also disable "Unmount" in the partition menu for active RAID array
members.
Bug #709640 - Linux Swap Suspend and Software RAID partitions not
recognised
Recognise in kernel, Linux Swap Suspend partitions. (When hibernated
the kernel write the RAM out to swap space and changes the magic string
from swap space to suspend). Recognition required either
libparted >= 1.8.8.1 or blkid from util-linux >= 2.15 or before that
blkid from e2fsprogs >= 1.39.
Recognise Linux Software RAID partitions. Recognition requires blkid
from util-linux >= 2.15.
Example:
# blkid /dev/sda10 /dev/sda11
/dev/sda10: ... TYPE="swsuspend"
/dev/sda11: ... TYPE="linux_raid_member"
# parted /dev/sda print
Model: ATA SAMSUNG HM500JI (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
...
10 361GB 362GB 1074MB logical swsusp
11 362GB 363GB 1074MB logical raid
Bug #709640 - Linux Swap Suspend and Software RAID partitions not
recognised
Step 3 of 3:
Now that all label widgets are created with ALIGN_LEFT and ALIGN_CENTER
alignment remove the x_align and y_align parameters from mk_label() and
always use this alignment. Also specify this alignment via floats
rather than enumerators, one of which was deprecated.
Bug #652044 - uses deprecated APIs
Step 2 of 3:
ALIGN_RIGHT was only used for the size figures in the GParted > Devices
device selector with radio buttons. Change to ALIGN_LEFT and adjust the
widget packing to maintain appearance.
Bug #652044 - uses deprecated APIs
Gtkmm release 2.24 in February 2011 deprecated the use of these
alignment enumerators superseding them with:
Deprecated enumerator Use instead
Gtk::ALIGN_LEFT Gtk::ALIGN_START
Gtk::ALIGN_RIGHT Gtk::ALIGN_END
Gtk::ALIGN_TOP Gtk::ALIGN_START
Gtk::ALIGN_BOTTOM Gtk::ALIGN_END
gtkmm: gtkmm Enums and Flags [2.24]
https://developer.gnome.org/gtkmm/2.24/group__gtkmmEnums.html
The deprecated alignment enumerators were only used in the creation of
Gtk::Label widgets by method Utils::mk_label(). In all but three cases
the alignment was left, center. So make all labels with alignment left,
center and then stop using the deprecated enumerators.
Step 1 of 3:
ALIGN_TOP was only used for these 2 labels:
"Path:" text in View > Device Information;
"Path:" text in Partition > Information.
Use of ALIGN_TOP makes no difference to these labels so just change to
ALIGN_CENTER.
Bug #652044 - uses deprecated APIs
Turn on the text progress bar for the resize2fs command. Looks like:
# resize2fs -p /dev/sda13 262144
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/sda13 to 262144 (4k) blocks.
Begin pass 2 (max = 97177)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 80)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 5597)
Updating inode references XXXXXXXXX-------------------------------
Bug #709276 - Percentage indicator for subcommand
Add concept of cursor position within the current line, separate from
the end of the buffer. This is so that programs which output a text
progress bar using backspace, such as resize2fs -p, are displayed
correctly.
Bug #709276 - Percentage indicator for subcommand
All the code was there in btrfs::read_uuid() to read the UUID from the
btrfs-show command. It just needed enabling.
This is only relevant when: (1) the blkid command is unavailable as
GParted primarily reads the UUID through the FS_Info cache using the
blkid command, and (2) the btrfs command is unavailable and the btrfs
module uses the older btrfs-show command instead.
For active swap space read the usage from /proc/swaps. (Linux kernel
uses units of 1 KiB). By definition inactive swap space is 100% free.
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda2 partition 5242876 430552 -1
Always set fs.read = FS::EXTERNAL even if /proc/swaps doesn't exist so
that an attempt is made to open the file generating a specific error, in
addition to the generic error.
open("/proc/swaps", O_RDONLY): No such file or directory
Unable to read the contents of this file system!
Because of this some operations may be unavailable.
The cause might be a missing software package.
The following list of software packages is required for linux-
swap file system support: util-linux.
Closes Bug #708107 - Usage of swap space is not reported
Enable the text progress bar and percentage complete from the e2fsck
command. Looks like:
# e2fsck -f -y -v -C 0 /dev/sda8
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
test8: |========================================= / 73.6%
Note that e2fsck deliberately brackets the progress bar with control-A
and control-B characters when it detects that it is not being run from a
terminal so that logsave(8) can exclude the progress bar from being
written to a log file. As GParted doesn't run e2fsck via a pty it
receives these control characters. Ignore them.
References:
Change e2fsck to bracket its progress bar output with ctrl-A and ctrl-B
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=bc34d6be65cb93a65451ad209cfea2f98b03fd22
Don't print ^A and ^B chars when e2fsck is talking directly to a tty
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=54a31a3b2e432c124aa03442f2983c4f4d4a974c
Closes Bug #697662 - Do not hide the progress of the tools used
Remove the -P, no progress bar option, from the ntfsresize command.
This allows the command to display the %age complete on its output which
is displayed in the operation details dialog, updated in real time.
Possible since:
Bug #685740 - Refactor to use asynchronous command execution
Bug #697662 - Do not hide the progress of the tools used
Currently the btrfs command outputs figures to 2 decimal places followed
by an SI multiplier, e.g. 1.00GB.
This patch to btrfs-progs has been included in the integration
repository and will likely be included in the official btrfs-progs
repository at some point. It changes btrfs-progs to use IEC
multipliers, e.g. 1.00GiB. In fact multipliers already aren't used for
figures less than 1024.
[PATCH] btrfs-progs: use IEC units for size
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26888https://patchwork.kernel.org/patch/2825841/
Make GParted capable of also accepting IEC prefix multipliers, just "B"
for bytes and no multiplier, as well as an optional space between the
number and multiplier. Therefore accept values like these:
1.00GB 1.00 GB
1.00GiB 1.00 GiB
1073741824B 1073741824 B
1073741824
Closes Bug #706914 - Prepare for btrfs tools using IEC prefix
multipliers
With recent btrfs-progs, GParted failed to format a btrfs file system
over the top of an existing one. Make btrfs failed with this error:
# mkfs.btrfs /dev/sdb1
...
/dev/sdb1 appears to contain an existing filesystem (btrfs).
Use the -f option to force overwrite.
With this commit to btrfs-progs on 2013-02-19, mkfs.btrfs checks for
existing file system signatures, including all mirror copies of btrfs
super blocks, before writing to the partition.
http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/commit/?id=2a2d8e1962e8b6cda7b0a7584f6d2fb95d442cb6
btrfs-progs: require mkfs -f force option to overwrite filesystem or partition table
Make GParted clear all the mirror copies of the btrfs file system super
blocks as erase_filesystem_signatures() is intended to prevent detection
of old signatures. This also avoids having to determine if the -f
option to mkfs.btrfs is available before trying to use it.
Closes Bug #705426 - Formatting Existing BTRFS Partition as BTRFS Fails
Because mkfs.btrfs Is Not Run with "-f"
Unfortunately a regression was introduced with GParted 0.14.1 wherein
linux-swap grow and shrink operations were broken. This regression was
a direct result of the following commit:
Prevent file system grow when partition grow fails (#686668)
fd96328920
The regression did not result in an error in the GUI, but rather the
linux-swap file system was not "resized" to the correct partition size.
The logic error introduced with the above commit listed has now been
fixed.
BACKGROUND INFORMATION ON LINUX-SWAP RESIZING
Currently no command line tools are available for resizing linux-swap.
However, since linux-swap does not contain data in the usual sense, we
simulate resizing linux-swap by re-creating (maximizing to fill
partition) the linux-swap file system with the same UUID and volume
label. To work correctly, the linux-swap file system must be re-created
after the final partition resize action has occurred.
Closes Bug #706604 - Failure to properly grow or shrink linux-swap when
resizing
Under GNOME Shell a running instance of GParted was getting named
"Gpartedbin". Ultimately GNOME Shell [1] uses the WM_CLASS X Window
property [2], which GDK defaults from the executable name.
$ xprop WM_NAME WM_CLASS
(Click on running GParted window)
WM_NAME(STRING) = "/dev/sda - GParted"
WM_CLASS(STRING) = "gpartedbin", "Gpartedbin"
Set the Class name, second string of the WM_CLASS X Window property, to
"GParted". (This prevents the use of the '--class' GTK+/GDK common
command line option [3] to override the class name, but I expect nobody
ever uses the option. GNOME Terminal has the same limitation. It also
has the same change setting the Class name [4]).
References:
[1] Application Based GNOME 3
https://wiki.gnome.org/GnomeShell/ApplicationBased
[2] WM_CLASS Property, Inter-Client Communication Conventions Manual
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
[3] Running GTK+ Applications, Common command line options
https://developer.gnome.org/gtk3/stable/gtk-running.html
[4] Bug #685742 - Window class of terminals doesn't match the desktop
file name
https://bugzilla.gnome.org/show_bug.cgi?id=685742https://git.gnome.org/browse/gnome-terminal/commit/?id=3370c0e51159f5be476b909e94ac05e5362dd28a
Closes Bug #705323 - Shows up as 'Gpartedbin' in GNOME Shell
Dosfstools >= 3.0.18, released June 2013, renamed the programs thus:
dosfslabel becomes fatlabel,
dosfsck becomes fsck.fat,
and mkdosfs becomes mkfs.fat.
Dosfstools creates symbolic links for the old names for backward
compatibility, but unfortunately the Debian dosfstools-3.0.22-1
(experimental) package doesn't include those symbolic links. This
causes create, check and read unmounted FAT16/32 file systems to not be
supported.
Make GParted look for the new names first and the old names second.
Closes Bug #704629 - Program name changes in dosfstools 3.0.18+ break
FAT16/32 support
It was difficult to retrieve whether a filesystem's label can be set on reformat.
The read_label flag can't be used as it decides whether to use the logic in the filesystem class
rather than the fallback in GParted::set_device_partitions, to determine the label of a partition.
The create_with_label flag is NONE for file systems that we cannot format with a
label (or that we cannot format at all).
The value is usually EXTERNAL for file systems that we can format with a label.
The read-only functionality is unused and the readonly parameter is
always false in copy_filesystem() and copy_blocks() methods. This has
been the case since the copy simulation was dropped by commit:
b9b4b2e55d
Remove simulation pass ( read test ) on move
The minimum NTFS volume size supported by the ntfs-3g mkntfs command
is 1 MiB. Since 1 extra sector is required for the backup NTFS boot
sector, an NTFS partition must be at least 1 MiB plus 1 sector.
To demonstrate, create a 1 MiB unformatted partition using MiB
alignment (/dev/sdd1), and then try to format the partition as NTFS.
# mkntfs -Q -v -L "ntfs-test" /dev/sdd1
Device is too small (1023kiB). Minimum NTFS volume size is 1MiB.
For GParted this means a minimum NTFS partition size of 2 MiB since
the smallest unit in the GUI is MiB.
Bug #697848 - Failure to Create 1 MiB NTFS Partition
Place the size and noaction options before the device name when resizing
an NTFS file system to match the order documented in the manual page.
Example fixed command:
# ntfsresize -P --force --force -s 104857600 --no-action /dev/sda11
Ext[234] file systems were being shrunk 1 KiB too small. Ntfs and
reiserfs file systems were being shrunk 1 byte too small. The resultant
file systems were ending up 1 block smaller than they could have been.
This looks like an accidental leftover from when GParted use to:
1) Shrink the file system 1 cylinder too small
2) Shrink the partition
3) Grow the file system to fill the partition
Relevant commit:
d663c3c277
removed cylindersize buffering during resize from the filesystems
Closes Bug #701075 - Setting the backup boot sector when resizing NTFS
It was possible to make GParted crash by adding a label, check or new
UUID operation and then applying the operation before the view of
pending operations had finished fully opening. The operation would be
successfully applied but GParted would crash afterwards.
The fault was that Add_Operation() still enabled the Undo and Apply
buttons and processed the GTK event loop before merging the list of
pending operations. Faulty code flow went like this:
activate_*()
Add_Operation()
Add operation to the operations[] vector
Enable Undo and Apply buttons
Refresh_Visual()
Process GTK event loop
Process Apply button callback applying operations,
refreshing display and clearing operations[] vector
Merge operations in the operations[] vector
<< Core dump here >>
Merge_Operations()
Refresh_Visual()
This faulty code flow came about when merging of operations was added
and it didn't appreciate that the operations[] vector could have been
processed and cleared by Add_Operations() before the merge step.
Relevant commit:
b10349ae37
Merge overlapping operations (#438573)
Fragment of code in the label operation case:
2454 void Win_GParted::activate_label_partition()
2455 {
...
2472 Add_Operation( operation ) ;
2473
2474 // Verify if the two operations can be merged
2475 for ( unsigned int t = 0 ; t < operations .size() - 1 ; t++ )
2476 {
2477 if ( operations[ t ] ->type == OPERATION_LABEL_PARTITION )
2478 {
2479 if ( Merge_Operations( t, operations .size() - 1 ) )
2480 break;
2481 }
2482 }
Commentary in the crashing label operation case:
2472 The pending operation was already applied when Add_Operation()
returned resulting in the operations[] vector being cleared
setting its size to 0.
2475 The return type of operations.size() is an unsigned integral, so
the upper limit of the for loop is t < 0UL - 1. Assuming a
32-bit machine that's t < 4294967295.
2477 operations[] vector is access from out of bounds offset 0
upwards until unallocated memory is accessed resulting in a core
dump.
Fix this by not enabling the Undo and Apply buttons and processing the
GTK event loop until after merging of operations has been performed.
Fixed code flow goes like this:
activate_*()
Add_Operation()
Add operation to the operations[] vector
Merge operations in the operations[] vector
Merge_Operations()
show_operationslist()
Enable Undo and Apply buttons
Refresh_Visual()
Process GTK event loop
Process Apply button callback applying operations,
refreshing display and clearing operations[] vector
Not allowing the operations list to be process until after the merge
step is the be correct ordering. This also prevents the new operation
from flashing up in the operations list and then immediately
disappearing if merged. In the case of adding the first operation,
delaying enabling the Undo and Apply buttons is enough as the buttons
were previously disabled preventing the operation being applied before
the merge. In the case of adding further operations, processing of the
GTK event loop must also be delayed until after the merge to prevent the
operations being applied before the merge. Although that window of
opportunity would only be microseconds.
Bug #699452 - Crash when applying operations before pending operations
fully displayed
Mlabel sometimes writes uninitialised memory at the end of the label.
This causes mlabel, and therefore GParted, to display extra junk at the
end of the label. Depending on the bytes written GParted may also show
the following error on stdout:
(gpartedbin:18116): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g_convert_error
code : 1
what : Invalid byte sequence in conversion input
This is caused by a bug in mlabel, believed fixed in mtools 4.0.14.
Effects at least Fedora 14, RHEL/CentOS 6.x and Debian 6. (Use label
"1234567890" on Debian 6 to reproduce). Reproduction steps:
# mkdosfs -F16 /dev/sda7
mkdosfs 3.0.9 (31 Jan 2010)
# export MTOOLS_SKIP_CHECK=1
# mlabel ::123456 -i /dev/sda7
# mlabel -s :: -i /dev/sda7
Volume label is 123456~1t
It is not possible to detect which characters are junk so they can't be
trimmed. Instead just space pad labels so that at least newly written
labels aren't effected. (Fat labels are space padded on the disk by
definition anyway).
Bug #700228 - FAT16/32 labels are sometimes shown corrupted
There was virtually no difference between the separate modules for fat16
and fat32. Remove module fat32 and patch fat16 to serve both file
system subtypes. This is equivalent to what was previously done for
ext[234] by commit:
38dc55d49c
Combine duplicate code for ext[234]
Rename function to update_command_output() to better reflect that this
callback updates the UI with the latest output read from the command
being executed.
This makes more sense knowing a future change will add a separate
callback which parses the output read from the command and updates the
progress bar. This function should be named update_command_progress().
Rename the libsigc++ signals to signal_update and signal_eof to match
the naming used for signals in GParted.
fgrep 'sigc::signal' include/*.h
Also explicitly use the emit() method rather than using the object
operator(). This again is to match the convention in GParted and make
it more obvious what is happening.
fgrep '.emit(' include/*.h
The previous commit missed one glibmm GSource wrapper in the form of the
io watch for the PipeCapture class. Convert this one to use glib
directly as well.
Bug #697727 - Segfault in livecd Gparted v 0.15.0-3 when copying
partition
On RHEL / CentOS 5.9 GParted couldn't set an icon as the
set_default_icon_name() method is not available. See commit [1] for
details.
Re-add the old set_icon_from_file() method as a fallback and re-install
a GParted pixmap as was used before commit [2].
Commit [1]:
a042107883
Only use Gtk::Window::set_default_icon_name method when available
Commit [2]:
f5a80bc904
Enabled GParted to use themed app icon (Tango theme)
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
On RHEL / CentOS 5.9 GParted failed to run any external commands and
instead reported the following warnings to the terminal:
# src/gpartedbin
======================
libparted : 1.8.1
======================
Failed to change to directory '' (No such file or directory)
Failed to change to directory '' (No such file or directory)
Failed to change to directory '' (No such file or directory)
...
Utils::execute_command() and FileSystem::execute_command() passed a zero
length string for the working directory to
Glib::spawn_async_with_pipes() to mean don't change directory. Instead
glibmm just tried to change to the directory with a zero length name.
This was fixed with glibmm >= 2.21.2 released July 2009, however RHEL /
CentOS 5.9 only has glibmm 2.12.10.
Relevant glibmm fix:
Treat empty Glib::spawn*() working dir as unset
https://git.gnome.org/browse/glibmm/commit/?id=8a7805cbbe6d268e975669349beb4e82d971537d
Fix by simply specifying ".", the current working directory, as the
directory to change into before executing all commands.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
Glib::ustring::compose() method requires glibmm >= 2.16, but RHEL /
CentOS 5.9 only provides glibmm 2.12. Replace with String::ucompose()
as is used everywhere else in the code.
Add missing include for kill() and SIGINT declarations.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
Roughly HFSX is a case sensitive version of the HFS+ file system.
Parted reports such a file system as "hfsx" rather than "hfs+".
# mkfs.hfsplus -v "case insensitive hfs+" /dev/sda7
Initialized /dev/sda7 as a 1024 MB HFS Plus volume
# mkfs.hfsplus -s -v "case sensitive hfs+" /dev/sda8
Initialized /dev/sda8 as a 1024 MB HFS Plus volume
# parted /dev/sda print
...
Number Start End Size Type File system Flags
...
7 356GB 357GB 1074MB logical hfs+
8 357GB 358GB 1074MB logical hfsx
# blkid /dev/sda[78]
/dev/sda7: LABEL="case insensitive hfs+" TYPE="hfsplus"
/dev/sda8: LABEL="case sensitive hfs+" TYPE="hfsplus"
Make GParted recognise HFSX file system variants too.
Closes Bug #698876 - GParted fails to recognize HFS+ partition (possible
due to disabled journaling)
In some circumstances gparted would appear to scan forever if it
encountered a blank hard disk. This would happen if the timing of
events was right and gparted encountered a disk without a partition
table. The missing partition table would cause a call to the
exception handler, which could get stuck in a thread waiting position.
The problem was traced back to the ped_exception_handler
and a cond.signal() call missing the requisite mutex.lock() and
mutex.unlock() around the signal call.
Closes Bug #697518 - gparted scans forever blank disk in virtualbox
The glibmm GSource wrappers have a bug where they do not do
reference counting properly, and have a race condition where
the background thread can try to touch the source after the
main thread has already processed and destroyed it. This
results in writes to freed memory and sometimes this causes
crashes or other erratic behavior. Avoid using the glibmm
wrappers and use glib directly. See bug #561885 for details
of the glibmm bug.
Bug #697727 - Segfault in livecd Gparted v 0.15.0-3 when copying partition
For an absolutely full NTFS GParted doesn't show the file system usage
but instead shows a warning against the partition.
GParted was looking only for "resize at %d" to determine file system
used figure in the output from the ntfsresize command. Also handle
finding "ERROR: Volume is full" too to derive used figure.
NTFS with 1 block free case:
# ntfsresize --info --force --no-progress-bar /dev/sda9
...
Current volume size: 1073738240 bytes (1074 MB)
...
Collecting resizing constraints ...
You might resize at 1073737728 bytes (freeing 4096 bytes).
...
# echo $?
0
Absolutely full NTFS case:
# ntfsresize --info --force --no-progress-bar /dev/sda9
...
Current volume size: 1073738240 bytes (1074 MB)
...
Collecting resizing constraints ...
ERROR: Volume is full. To shrink it, delete unused files.
# echo $?
1
Closes Bug #697946 - Absolutely full NTFS reported as partition error
Lookup the maximum reiser4 file system label length instead, so that it
is defined in only one place. Small improvement missed from earlier
commit:
18941e24d3
Avoid reading trailing junk for a reiser4 label (#689318)
These functions in GParted_Core:
open_device()
open_device_and_disk()
close_disk()
close_device_and_disk()
call the following functions in the libparted API:
ped_device_get()
ped_disk_new()
ped_disk_destroy()
ped_device_destroy()
which don't open or close anything. Instead they allocate and
deallocate PedDevice and PedDisk memory structures which describe block
devices and partition tables respectively.
Rename functions:
open_device_and_disk() -> get_device_and_disk()
close_device_and_disk() -> destroy_device_and_disk()
and merge open_device() and open_device() as each only wrapped one
libparted function and was only called from a single place.
The wipefs command has the following significant limitations which were
worked around in previous commits:
1) Wasn't available in the earliest distributions supported by GParted;
2) Had to be called 3 times to erase vfat (fat16/32) signatures in all
but the most recent versions.
This meant we had all the code to clear file system signatures without
using the wipefs command as well as extra complexity of using wipefs
too. So just remove use of the wipefs command.
Bug #688882 - Improve clearing of file system signatures
Wipefs only clears the nilfs2 file system signature from the primary
super block at the start of the partition. This is enough for blkid to
no longer detect the file system. However parted (>= 2.4 with nilfs2
support) and therefore GParted still detect the file system using the
secondary super block at the end of the partition.
# mkfs.nilfs2 /dev/sda12
# wipefs -a /dev/sda12
2 bytes were erased at offset 0x00000406 (nilfs2): 34 34
# blkid /dev/sda12
# parted /dev/sda12 print
Model: Unknown (unknown)
Disk /dev/sda12: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 1074MB 1074MB nilfs2
Overwrite the nilfs2 secondary super block at the end of the partition
with 4K block of zeros. Always do this just in case the partition
contains a nilfs secondary super block but is detected as a different
file system. Such an example was documented in an earlier commit
message.
Bug #688882 - Improve clearing of file system signatures
As failure of flushing the cache can lead to misidentification of file
systems make it a checked step in the displayed operation details.
Bug #688882 - Improve clearing of file system signatures
When wipefs command fails this means that in the display of the
operation results tree:
1) The command is displayed with a time and a stop sign, rather than no
time and a warning sign;
2) There is no report of any warnings or failures at the top level
summary.
(The immedately following "clear primary signatures" step will clear all
the file system signatures which wipefs failed to do. Should this fail
too it will report errors which will fail the whole operation).
Bug #688882 - Improve clearing of file system signatures
RHEL/CentOS 5.x uses util-linux 2.13 which predates the wipefs command.
Also the wipefs command may fail. Therefore implement a fallback which
caters for both these cases by overwriting all possible file system
super blocks with zeros at the start of the partition.
The "MUST be cleared" requirement stated in the first patch is now
satisfied. Therefore the status of the "clear old file system
signatures" step, as returned by erase_filesystem_signatures(), now
reflects the success of the wipefs command or the internal write zeros.
Failure of both will stop all operations, matching what happens with all
other steps.
Bug #688882 - Improve clearing of file system signatures
Before util-linux 2.21.0, released Feb 2012, wipefs only cleared one of
the three vfat (fat16/fat32) signatures it can be detected by each time
wipefs was run. Also if a nilfs2 file system was created before all
three signatures were cleared the partition was still recognised as a
vfat file system, albeit a corrupted one, rather than as a nilfs2 file
system.
Old wipefs clearing vfat signatures:
# wipefs --version
wipefs from util-linux 2.20.1
# wipefs -a /dev/sda7
8 bytes were erased at offset 0x52 (vfat)
they were: 46 41 54 33 32 20 20 20
# wipefs -a /dev/sda7
1 bytes were erased at offset 0x0 (vfat)
they were: eb
# wipefs -a /dev/sda7
2 bytes were erased at offset 0x1fe (vfat)
they were: 55 aa
New wipefs clearing vfat signatures:
# wipefs --version
wipefs from util-linux 2.21.2
# wipefs -a /dev/sda12
8 bytes were erased at offset 0x00000052 (vfat): 46 41 54 33 32 20 20 20
1 bytes were erased at offset 0x00000000 (vfat): eb
2 bytes were erased at offset 0x000001fe (vfat): 55 aa
Workaround by calling "wipefs -a" three times if the output indicated
only one vfat signature was cleared.
Bug #688882 - Improve clearing of file system signatures
When just formatting an existing partition to "cleared", GParted just
uses wipefs to clear the file system signatures. Afterwards parted/
libparted still detect the file system and GParted shows errors from the
file system specific tools reporting the file system doesn't exist.
# wipefs /dev/sda7
offset type
----------------------------------------------------------------
0x0 xfs [filesystem]
UUID: 28399a74-83a5-4ed7-aaf8-c76ac449fb57
# wipefs -a /dev/sda7
4 bytes were erased at offset 0x0 (xfs)
they were: 58 46 53 42
# parted /dev/sda print
Model: ATA SAMSUNG HM500JI (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 538MB 537MB primary ext4 boot
2 538MB 5907MB 5369MB primary linux-swap(v1)
3 5907MB 32.8GB 26.8GB primary ext4
4 32.8GB 500GB 467GB extended
5 32.8GB 355GB 322GB logical ext3
6 355GB 356GB 1074MB logical
7 356GB 357GB 1074MB logical xfs
# xfs_db -c 'sb 0' -c 'print blocksize' -c 'print dblocks' -c 'print fdblocks' -r /dev/sda7
xfs_db: /dev/sda7 is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
Wipefs was run on the partition specific block device (/dev/sda7) where
as libparted reads the disk using the whole disk device (/dev/sda).
However as the Linux buffer cache does not provide cache coherency, the
xfs file system can still be found in the cache of /dev/sda.
Fix this by calling ped_device_sync() after wipefs as it guarantees
cache coherency.
(As documented in erase_filesystem_signatures() there are cases when
calling ped_device_sync() isn't necessary, but testing shows that the
whole processes takes at most 0.15 seconds. As this is in the middle of
applying an operation, uses won't notice this extra time so just always
call ped_device_sync()).
Bug #688882 - Improve clearing of file system signatures
Add "cleared" to the bottom of list of file system formats available in
the Create new Partition dialog and in the Format to --> (file system
list) menu. This clears existing file system signatures in the newly
created partitions and existing partitions respectively.
Bug #688882 - Improve clearing of file system signatures
Move some code into new create_format_menu_add_item() sub-function which
adds one file system entry to the Partition --> Format to -->
(file system list) menu.
Bug #688882 - Improve clearing of file system signatures
Previously the function erase_filesystem_signatures() was used to clear
file system signatures when a new partition was created and when an
existing partition was formatted with a file system. However this was
only available with libparted <= 2.4 and then only for the file systems
which libparted supports.
Having multiple different file system signatures on a partition leads to
misidentification of file system. For example creating a nilfs2 over
the top of a fat32 file system is detected as a fat32, not nilfs2. This
shows that old file system signatures must be cleared before a new file
system is created.
Fix by always using "wipefs -a /dev/PARTITION" command to clear all old
file system signatures rather than libparted API calls. Failure from
wipefs is only considered a warning so doesn't fail the file system
creation. (This doesn't yet fully meet the "MUST be cleared"
requirement above. Will be fully met later in this patchset). Output
from the wipefs command is displayed as a new sub-step which looks like
this:
v Format /dev/sda7 as xfs 00:00:05
> calibrate /dev/sda14 00:00:01
v clear old file system signatures in /dev/sda7 00:00:01 [NEW]
> wipefs -a /dev/sda7 [NEW]
> set partition type on /dev/sda7 00:00:02
v create new xfs file system 00:00:01
> mkfs.xfs -f -L "" /dev/sda7
Also signatures are only cleared immediately before a new file system is
written and not when an unformatted partition is created. This allows
recovery from accidental partition deletion by re-creating the deleted
partition as unformatted.
Bug #688882 - Improve clearing of file system signatures
GParted fails to compile on RHEL/CentOS 5.9 because it doesn't provide
the Gtk::Window::set_default_icon_name() method. The "gtkmm GTK::Window
Class Reference" document says that set_default_icon_name() is available
in gtkmm >= 2.6, however it is not available in RHEL/CentOS 5.9 with
gtkmm 2.10.
Add an autoconf compile and link check for the set_default_icon_name()
method and make GParted only use the method when available.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
GParted fails to compile on RHEL/CentOS 5.9 because it doesn't provide
the Glib::Regex class. Glib::Regex class requires glibmm >= 2.14,
however RHEL/CentOS 5.9 only provides glibmm 2.12.
Add an autoconf check for the Glib::Regex class and fallback code using
the POSIX regex function. Fall back code is the same as that used prior
to commit:
b6f1c56fb1
Enhance regexp_label method to handle unicode characters
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
Only supports detection and creation of f2fs file systems. Requires
f2fs-tools and a blkid with f2fs support, util-linux > 2.22.2.
f2fs-tools v1.1.0 only supports file system creation.
Currently requires util-linux directly from the git repository as f2fs
support was only committed on 5 Feb 2013 and it has not yet been
released.
Closes Bug #695396 - Please apply f2fs patch
After a refresh, instead of having no partition selected, default to the
largest unallocated partition. This allows immediate creation of a new
partition in the unallocated space.
Bug 667365 - Free space should be selected by default
Many filesystems do not implement some of their methods, but had to provide
dummy implementations. Remove all of the dummy implementations and instead
just provide one in the base FileSystem class.
The details view refused to use additional space, even after the window was
expanded, instead continuing to use the scrollbars. Now resizing the
window will be allowed regardless of the state of the details expander, and
the details view will expand to use the extra space. Also request enough
initial width to not need a horizontal scrollbar.
Closes:
Bug 602635 - list of tasks in apply dialog does not expand to the available
vertical space
Bug 662722 - Increase default width of "applying..." dialog to include the
"Details" status icons
There were separate modules for ext3 and ext4 even though there
were virtually no differences with ext2. Remove the duplicate
modules and patch ext2 to serve as a common reference for all
three sub types.
After a move is canceled or fails, an attempt is made to revert the disk to
its previous state. This was moving back all blocks that had already been
copied. Many of the first blocks copied during a move do not overwrite
any valid data, and so do not need put back after an error, so don't bother
doing so.
After a failed or canceled move, the move was reverted, and the filesystem
was fscked while the partition was still in the expanded state encompassing
the original and destination partitions, resulting in errors and
corruption. Move fsck to after the partition table has been restored to
its original state.
After a refresh, instead of having no partition selected, default to the
largest unallocated partition. This allows immediate creation of a new
partition in the unallocated space.
Closes Bug 667365 - Free space should be selected by default
Interested operations can now connect a signal to their OperationDetail
to be notified of a cancelation request. The internal copy/move code
will now cleanly stop on cancelation, allowing the partition to be
rolled back to its previous state. This makes canceling a move
perfectly safe.
After clicking cancel, the button changes to "Force Cancel" and is
disabled for 5 seconds. Operations that are safe to cancel will do so
and those that are not will continue to run. Clicking force cancel
asks operations to cancel, even if doing so is unsafe. For the
internal copy/move algorithm, canceling is always safe because an
error results in a rollback operation. Canceling the rollback is
unsafe. For external commands, filesystem modules may indicate
that the command is safe to cancel or not. Canceled commands will
be terminated with SIGINT.
As a result of the new safe cancel vs force cancel distinction, the
scary warning about cancl causing corruption has been moved to
after clicking the force cancel button.
Part of Bug #601239 - Please allow 'Cancel after current operation'
Have the copy code create a background thread to do the actual copying so
that it won't block the main loop.
Part of Bug 685740 - Refactor to use asynchronous command execution
Win_Gparted and Dialog_Progress were creating threads to perform most
functions in the background. Most of the time, the only reason the
threads blocked was to execute an external command. The external command
execution has been changed to spawn the command asynchronously and wait
for completion with a nested main loop. While waiting for completion,
the pipe output is captured via events. In the future, this will allow
for it to be parsed in real time to obtain progress information.
Those tasks in GParted_Core that still block now spawn a background thread
and wait for it to complete with a nested main loop to avoid hanging the
gui.
Part of Bug #685740 - Refactor to use asynchronous command execution
fat16 and fat32 were creating a temp mtoolsrc file to configure the
command to reference a drive letter and ignore certain errors. They have
been changed to pass this information via the command line and environment
instead.
Dialog_Progress was using pthread_create() so that it could later
pthread_cancel() the thread. pthread_cancel() is wildly unsafe and full
of errors. Changed to use Glib's threads like the rest, and only cancel
between operations. Because it can take some time to cancel, disable
the cancel button once it has been clicked once.
Bug 601239 - Please allow 'Cancel after current operation'
Win_Gparted and Dialog_Progress were looping on Gtk::Main::events_pending()
and iteration() with usleeps in between. Use a full mainloop instead and
a proper timeout to trigger pulsebar updates instead of usleeps.
Part of Bug 685740 - Refactor to use asynchronous command execution
Use of these functions is depreciated and making gtk calls in a background
thread still sometimes causes deadlocks or crashes. Change ped exception
handler to instead use an idle function to force the main thread to display
the dialog box.
Part of Bug 685740 - Refactor to use asynchronous command execution
When moving a MiB aligned primary partition from right to left, the
resulting partition was unexpectedly 1 MiB smaller in size.
From further testing, this occurred only if the move boundaries
overlapped the original partition boundaries.
In cases where the move did not overlap the original partition
boundaries, then the size remained the same.
Closes Bug #695078 - Move of MiB aligned partition right to left
yields unexpected shrink of 1 MiB
Add -I option to 'mkdosfs' command to work around faulty detection of
"complete disks" vs. "partitions".
Bug #693955 - mkdosfs detects "complete disk" vs. "partition" incorrectly
Thanks to Kano for reporting this!
(This will also be needed if GParted ever allows formatting a device without
partitioning it.)
No longer need to trim fat16, fat32 and xfs labels as all labels are
limited to their maximum lengths during entry.
Bug #689318 - filesystem type specific support for partition name
maximum length
For a reiser4 file system with exactly the maximum size 16 character
label, debugfs.reiser4 may include junk at the end of the label it
prints. (It reads the label into a 16 character array and prints it as
a string, but there isn't a nul terminating character).
# mkfs.reiser4 --yes --label abcdefghij123456 /dev/sda13
# debugfs.reiser4 /dev/sda13 2> /dev/null | grep label:
label: abcdefghij123456!
Trim the read label to at most 16 characters.
Bug #689318 - filesystem type specific support for partition name
maximum length
Active Linux software RAID devices are detected in the
Proc_Partitions_Info method. Hence the SWRaid method is no longer
required.
Removal of the SWRaid method fixes the problem with the error message:
Could not stat device /dev/md/0 - No such file or directory
This fixes the problem because we no longer use "mdadm --examine
--scan" in an attempt to detect Linux software RAID devices. The
mdadm command was returning device names such as /dev/md/0, which are
incorrect for GParted.
NOTE: With this change, GParted no longer requires the mdadm command
to detect Linux software RAID devices.
Closes Bug #678379 - Could not stat device /dev/md/0 - No such file or
directory
Add regular expression to detect the device entry only (e.g., md127)
and not the partitions (e.g., md127p1).
Linux software RAID devices are listed in /proc/partitions as follows:
# cat /proc/partitions
major minor #blocks name
9 127 523968 md127
259 0 131072 md127p1
259 1 262144 md127p2
Part of Bug #678379 - Could not stat device /dev/md/0 - No such file
or directory
HP Smart Array Devices are listed in /proc/partitions as follows:
major minor #blocks name
104 0 143338560 cciss/c0d0
104 1 104391 cciss/c0d0p1
104 2 24097 cciss/c0d0p2
104 3 143203410 cciss/c0d0p3
The previous regular expression was too broad, and would match many
other forms, including Linux software RAID devices such as md127.
Linux software RAID devices are listed in /proc/partitions as follows:
major minor #blocks name
9 127 523968 md127
259 0 131072 md127p1
259 1 262144 md127p2
This problem with the regexp was discovered while investigating a
problem with Linux software RAID device detection.
The regular expression has been tightened up to match the following
hardware RAID controllers:
Compaq/HP Smartarray RAID controller
E.g., device = /dev/cciss/c0d0, partition = /dev/cciss/c0d0p1
(linux-x.y.z/Documentation/blockdev/cciss.txt)
Compaq SMART2 Intelligent Disk Array controller
E.g., device = /dev/ida/c0d0, partition = /dev/ida/c0d0p1
(linux-x.y.z/Documentation/blockdev/cpqarray.txt)
Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers
E.g., device = /dev/rd/c0d0, partition = /dev/rd/c0d0p1
(linux-x.y.z/Documentation/blockdev/README.DAC960)
Related to Bug #678379 - Could not stat device /dev/md/0 - No such
file or directory
In certain situations with a mixture of partition alignments, the MiB
alignment option would try to set the end of a logical partition
beyond the end of the extended partition. This, of course, is an
invalid partition geometry and the libparted library correctly reports
failure when this is attempted.
This enhancement to MiB alignment adds a check to see if the end of
the logical partition would be beyond the extended partition, and
adjusts the end of the logical partition if required.
Closes Bug #686668 - Growing logical partition overlaps end of
extended partition
Prior to this enhancement, GParted ignored the status of the partition
grow operation, and attempted to grow the file system.
Now we check the status of the partition grow operation prior to
growing the file system.
Part of Bug #686668 - Growing logical partition overlaps end of
extended partition
A reiser4 file system with a blank label is displayed as "<none>" by
debugfs.reiser4 and therefore GParted too.
# mkfs.reiser4 -y -L "" -f /dev/sda14
# debugfs.reiser4 /dev/sda14 2> /dev/null | grep label:
label: <none>
Additionally when displaying the Partition Information the following
warning is written to the terminal:
(gpartedbin:19609): Gtk-WARNING **: Failed to set text from markup
due to error parsing markup: Error on line 1 char 23: Element
'markup' was closed, but the currently open element is 'none'
Fix by just assuming "<none>" always means blank. If someone really
does set the label to "<none>" it won't be displayed. This is equlivant
to how btrfs and nilfs2 are already handled.
Closes bug 688760 - GParted displays blank resier4 label as <none>
1) lp_disk is not used and assigned NULL so doesn't need closing.
2) lp_device is already ped_device_open()ed and ped_device_close()d
within the above while loop. lp_device will be set to NULL when the
while loop ends so this doesn't need closing either. Hence
close_device_and_disk() is always passed with two NULL pointers and is a
no operation so can be removed.
They were used like global variables. Now they are moved to the
functions that actually use them to make clearer how the data flow is.
Bug #683149 - Cleanup(?): Remove lp_device and lp_disk from GParted_Core
Use swaplabel to read the Linux swap label so that 1) a blank label can
be read, and 2) to replace deprecated and removed vol_id.
Vol_id was deprecated in May 2009, superseded by blkid and soon
thereafter removed. Swaplabel is available in util-linux 2.18 from Jun
2010.
If the swaplabel command is not available GParted falls back on reading
the label through the FS_Info cache which uses the blkid command. If
the blkid command is also not available FS_Info cache will *NOT* return
any label and GParted will display blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
GParted doesn't notice when a file system label is changed to blank.
GParted first calls the file system specific read_label() method. When
the label is blank read_label() correctly sets partition.label to the
zero length string. Second GParted_Core::set_device_partitions() treats
the zero length string to mean that the label is unset and calls
FS_Info::get_label() to retrieve it from the cache of blkid output.
Blkid also doesn't notice when the file system label has been changed to
blank so reports the previous label. Hence GParted displays the
previous file system label.
Fix by making label a private member variable of the class Partition and
providing access methods set_label(), get_label() and label_known()
which track whether the label has been set or not. This only fixes the
fault for file systems which use file system specific commands to read
the label and when these tools are installed. Otherwise GParted uses,
or has to fall back on using, the buggy blkid command to read the file
system label.
NOTE:
Many of the file system specific read_label() methods use a tool which
outputs more than just the label and use Utils::regexp_label() to match
leading text and the label itself. If the surrounding text changes or
disappears altogether to indicated a blank label, regexp_label() doesn't
match anything and returns the zero length string. This is exactly
what is required and is passed to set_label() to set the label to blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
Traced debugreiserfs on a 10GiB reiserfs file system which was 100% full
full with nearly 900,000 files. It read exactly three 4KiB blocks from
different offsets and the program never took more than 0.1 seconds.
A user had a 190 MiB partition containing an old ext2 file system. When
unmounted it was reported as filling the partition, but when mounted it
was reported as having 6% unallocated space. The file system's inode
tables were approximately twice the size of those created by default
with the current mkfs.ext2 defaults.
To create an equivalent file system in a 190 MiB partition:
mkfs.ext2 -N 97344 /dev/sda15
It turns out that for ext2, ext3 and ext4 file systems what was
described as intrinsic unallocated space during the development of
Bug #499202 is actually file system overhead. When mounted the ext2/3/4
kernel code reports the size of the file system after subtracting the
overhead. Overhead is made up of superblock backups, group descriptors,
allocation bitmaps and largest of all inode tables. E2fsprogs tools
don't subtract this overhead when reporting the file system size.
References:
* The Second Extended File System, Internal Layout, by Dave Poirier
http://www.nongnu.org/ext2-doc/ext2.html
* Linux ext2_statfs() function
http://lxr.linux.no/#linux+v3.5.3/fs/ext2/super.c#L1311
Call the file system specific method for reading the usage of ext2, ext3
and ext4 file systems while mounted. Make it read the file system size
from the on disk superblock to avoid subtraction of overhead and use the
statvfs() system call to return an up to date free space figure.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Each file system class can now choose how the size and free space of the
file system is determined when it is mounted.
.fs.online_read = FS::NONE (default)
Do nothing. Don't get the file system size and free space.
.fs.online_read = FS::GPARTED
Use internal GParted method which calls statvfs() system call on
the mounted file system.
.fs.online_read = FS::EXTERNAL
Call the file system's member function set_used_sectors(). This
is the same function as called when the file system is not
mounted. It can determine if the file system is mounted or not
by testing partition.busy and acting accordingly.
This means that determining the size and free space of active LVM2
Physical Volumes is no longer a special case. Instead the lvm2_pv class
just elects to have its set_used_sectors() method called for both the
active and deactive cases.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Vol_id command was deprecated in May 2009 and superseded by the blkid
command. Replace the generic vol_id command with the file system
specific debugfs.reiser4 command to read the file system label.
Debugfs.reiser4 will exist as it's already required to read the file
system usage and UUID.
Use the new RFC 4122 none Nil UUID regular expression to validate the
UUID read in all the Linux native file system specific read_uuid()
methods. No longer need to explicitly exclude "<none>" or all zeros Nil
UUID as the regular expression does this.
Not necessary but use the simpler file system tune command rather than
the file system debug command where possible. Also saves creating an
echo process.
For a mounted reiserfs file system with a Nil UUID (all zeros) GParted
will display a partition specific warning. This comes from the reiserfs
specific read_uuid() method. Error demonstration:
# blkid /dev/sda15
/dev/sda15: LABEL="test-reiserfs-2" TYPE="reiserfs"
# mount | grep sda15
/dev/sda15 on /mnt/2 type reiserfs (rw,relatime)
# reiserfstune /dev/sda15
reiserfstune: Reiserfstune is not allowed to be run on mounted filesystem.
Switch to using debugreiserfs to read the UUID as it can be used on a
mounted file system.
# debugreiserfs /dev/sda15 2> /dev/null | grep UUI
UUID: 00000000-0000-0000-0000-000000000000
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
On Fedora up to and including Fedora 16 and Red Hat and CentOS up to the
current 6.3 release the UUID of an unmounted reiserfs file system is
displayed as "<no" and a GTK markup warning is written to the terminal.
This was because the reiserfs-utils package isn't linked with libuuid
support so reiserfs file systems were created with a Nil UUID (all
zeros). To read the UUID GParted first tries to retrieve the UUID from
the blkid command output via the FS_Info cache. Secondly it tries the
reiserfs file system specific read_uuid() method which uses the first
space separated word following the text "UUID:", hence it gets "<no".
# debugreiserfs /dev/sda15 2> /dev/null | grep UUID
UUID: <no libuuid installed>
In September 2012 Red Hat bug 660285 "reiserfstune compiled without UUID
support" was fixed for Fedora 16 and later releases. On Fedora with
this fix applied GParted will display the Nil UUID (all zeros) for a
previously created reiserfs file system rather than suppressing it.
Only accept valid, none Nil UUIDs in the reiserfs file system specific
read_uuid() method.
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
Rescanning for supported actions in the File System Support dialog was
not detecting the removal and restoration of the lvm command. GParted
was only updating supported actions after refreshing all devices.
Checking for the lvm command was tied to the refresh of the LVM2_PV_Info
cache, hence the behaviour. Fix by always checking for the lvm command
when requested.
Also remove extra new line from end of an error message in
load_lvm2_pv_info_cache().
As LVM2 Physical Volumes can't be resized when they are members of
exported Volume Groups add a warning message to explain this fact.
Display the message as a partition specific warning and as additional
text when growing the file system to fill the partition is skipped for
the check operation and when pasting into an existing larger partition.
Bug #670171 - Add LVM PV read-write support
When an inactive LVM2 Volume Group is exported it makes it unknown to
the local system, ready for moving the member Physical Volumes to
another system, where the VG can be imported and used. In this state a
PV can't be resized.
# lvm pvresize /dev/sda10
Volume group Test-VG1 is exported
Unable to read volume group "Test-VG1".
0 physical volume(s) resized / 1 physical volume(s) not resized
# echo $?
5
Fix this by preventing resizing of such a PV. This has been coded in a
generic way using new function filesystem_resize_disallowed() to
determine whether a file system is allowed to be resized or not. For
a file system which can be resized, but is currently not allowed to be
resized, the behaviour is as follows:
1) Pasting into unallocated space is limited to creating a new
partition which is the same size as the copied partition.
2) Resizing the partition is disallowed, only moving the partition is
allowed.
3) Pasting into an existing partition will only copy the file system.
If the destination partition is larger a warning will report that
growing the file system is not currently allowed.
4) Checking a partition will also report a warning that growing the
file system is not currently allowed.
This is exactly the same behaviour as for a file system which does not
implement resizing, except for a different warning message.
Bug #670171 - Add LVM PV read-write support
Create common cache search and index functions get_attr_by_name() and
get_attr_by_row() as the existing ones, get_pv_attr_by_*() and
get_vg_attr_by_*(), only differ from each other by the string vector
they use.
If an LVM2 Volume Group has two or more missing Physical Volumes, the VG
is displayed as only having one "unknown device" because
get_vg_members() only adds unique names to the list of members.
# lvm pvcreate /dev/sda11 /dev/sda12 /dev/sda13
# lvm vgcreate Test-VG1 /dev/sda11 /dev/sda12 /dev/sda13
# wipefs -a /dev/sda12
# wipefs -a /dev/sda13
View partition information in GParted
The simplest fix would be to include the PV's UUID in the cache of LVM2
information and add PV names based on unique UUIDs being a member of the
relevant VG. Unfortunately "lvm pvs" seems to have a bug when
displaying Logical Volume attributes, and there are two or more missing
PVs, which causes one of the PVs to be displayed multiple times, rather
than displaying each PV once.
Without LV attributes, every PV is listed:
# lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr 2> /dev/null
PV,PV UUID,VG,Attr
/dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-
unknown device,1ESORF-7wlR-0tnO-fy2z-nOL1-MrnJ-2O5yjK,Test-VG1,wz-pn-
With LV attributes, one missing PV is repeated:
# lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr,lv_name,lv_attr 2> /dev/null
PV,PV UUID,VG,Attr,LV,Attr
/dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-,,
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
Also "lvm vgs" and "lvm lvs" don't display anything when including both
VG and LV attributes.
Instead query the LVM2 information in two separate commands, one
querying PV attributes and one querying VG and LV attributes, saving the
results in lvm_pv_cache and lvm_vg_cache respectively.
Bug #670171 - Add LVM PV read-write support
Active LVM2 PVs have the partition class busy member set in
GParted_Core::set_device_partitions() just as mounted file systems do.
This is a basic requirement for GParted so that it only manipulates
partitions and contained file systems when they are not in use.
Add const qualifier to get_pv_attr_by_path() and get_pv_attr_by_row() as
they only access member variables read-only.
Make lvm2_pv_attr_to_num() a static member function as it doesn't access
any member variables.
For LVM2 Physical Volumes the Volume Group name was looked up multiple
times, sometimes from the secondary location of the mount point and at
other times from the primary location in the LVM2_PV_Info class. Just
lookup the VG name once from the primary location.
Rename functions and a variable to use a generic term for the menu item
which changes the busy state of partitions now that it also activates
and deactivates LVM2 Physical Volumes as well as mounting and unmounting
file systems and enables and disables swap partitions.
The new delete non-empty LVM2 Physical Volume warning dialog uses
Gtk::MessageDialog::get_message_area() in the display of Volume Group
members. This function was new in gtkmm 2.22, released September 2010,
which is not available in a number of current distributions including:
Unbuntu 10.04 LTS, RHEL 6.3, SLES 11-SP2, Debian 6.0.
Implement fallback method to display the VG name and member PVs in the
warning dialog for when get_message_area() is not available.
Bug #670171 - Add LVM PV read-write support
When attempting to delete a non-empty LVM2 Physical Volume (one which is
still a member of a Volume Group) display a warning dialog which
includes the VG name and a list of the PV members to allow the user to
make an informed choice whether to go ahead and perform the deletion or
cancel to the operation. This dialog is displayed when a partition
containing a PV is being deleted or being overwritten by being
reformatted or pasted into.
Bug #670171 - Add LVM PV read-write support
Implement remove() method so that the LVM2 metadata is updated to
reflect the removal of the LVM2 Physical Volume as well as removing the
signature from the PV before the partition is deleted or overwritten.
lvm pvremove /dev/DEVICE
Also specifically force the removal of the PV when it is a member of a
Volume Group so that it will succeed.
RATIONAL:
If the PV was not removed before the partition was deleted or
overwritten, LVM2 would be left in a broken state with metadata
describing missing PVs for any partially deleted VGs. This leaves the
user needing to perform recovery of a lost PV, which required in depth
understanding of LVM2 and is beyond the scope of what GParted can
currently provide.
The alternative is to use the pvremove command to instruct LVM2 to
remove the PV and update LVM2 metadata to reflect the removal of the PV.
For PVs which are a member of a VG this includes forcing the removal.
This has the impact of making recovery from accidental deletion of a
partition containing a PV irrecoverable. GParted is not able to recover
this situation anyway because Device -> Attempt Data Rescue, using the
gpart command, is not able to detect the signature of an LVM2 PV.
Choose to remove the PV, forcibly if required, rather than potentially
leave LVM2 with missing PVs.
Bug #670171 - Add LVM PV read-write support
This commit only adds a remove() method to every file system and an
optional call to it in the relevant operations. All remove() methods
are no operations and not enabled.
The remove() method provides explicit controlled removal of a file
system before the partition is deleted or overwritten by being formatted
or pasted into. When implemented, it appears as an extra step in the
relevant operation. The file system specific remove() method is
explicitly allowed to fail and stop the operations currently being
applied.
This is different to the existing erase_filesystem_signatures() which
wipes any previous file system signatures immediately before a new file
system is written to ensure there is no possibility of the partition
containing two or more different file system signatures. It never fails
or reports anything to the user.
NOTE:
Most file systems should NOT implement a remove() method as it will
prevent recovery from accidental partition deletion.
Bug #670171 - Add LVM PV read-write support
Copy operation for LVM2 Physical Volumes is deliberately not implemented
because it doesn't fit with how LVM2 works and is not safe in the
general case without an understanding of its internals. See comment in
lvm2_pv::copy() for more details.
Bug #670171 - Add LVM PV read-write support
In the Partition menu enable activation / deactivation of the LVM2
Volume Group of which the Physical Volume is a member.
Bug #670171 - Add LVM PV read-write support
Add creation of Physical Volumes specifying LVM2 metatdata format:
lvm pvcreate -M 2 /dev/DEVICE
Also set the partition type to identify its contents as LVM. Note that
libparted treats every partition type as a file system except LVM which
it treats as a flag, hence GParted displaying "lvm" in the Manage Flags
dialog. Never the less libparted set the partition types correctly.
For MBR partitioning the type is 8e "Linux LVM" and for GPT partitioning
the type is E6D6D379-F507-44C2-A23C-238F2A3DF928. Setting the partition
type as LVM is not strictly required as LVM2 scans the contents of all
partitions looking for PVs, but it is best practice.
Bug #670171 - Add LVM PV read-write support
Steps to reproduce:
1) Open any of these dialogs: Create New Partition, Resize/Move or
Paste;
2) Update any of the following numeric entry fields to a different value
using the keyboard: Free space preceding, New size or Free space
following;
3) Press [Esc] key;
Gparted crashes.
What is happening is that the [Esc] key is leading to the dialog being
closed and calling the ~Dialog_Base_Partition() destructor. However
after this the GTK widget is calling the on_spinbutton_value_change()
registered callbacks for the change to the other two values, on the now
just deleted object.
Fix by disconnecting the change notification callbacks in the
destructor.
Closes bug #682658 - GParted crash by pressing Esc in dialogs with
number entry
The mount of lost file systems that were larger than a 32 bit integer
could hold (~2 GiB), or started after the first ~2 GiB of disk, would
fail.
Closes Bug #680740 - Gparted fails when mounting the read-only view of
lost filesystems
The member functions btrfs_size_to_num(), btrfs_size_max_delta() and
btrfs_size_to_gdouble() don't access any member variables. Therefore
they don't need the const qualifier allowing them to be called when the
btrfs object is const for read-only access to member variables, but
instead need to be static member functions with no access to member
variables.
When resizing an extended partition, a problem can occur with MiB
alignment wherein the requested end sector could be less than the end
sector of the last logical partition. This would be an invalid
geometry because all the logical partitions must be wholly contained
within the extended partition.
Check for this situation and if found then set requested end for
the extended partition to the end of the last logical partition.
Closes Bug #678831 - Partition End Overlap when Resizing Extended
Partition
Restore intended logic accidentally changed by my recent commit:
Simplify calc_usage_triple() interface and rename
6c96ab34b3
Set each display integer to zero if the associated usage value is
negative, rather than setting 100% unused for unknown usage. Graphical
display of partition usage for unknown and unsupported file system types
is not affected and continues to be all white because of the logic in
the callers.
Local variables used, unused and unallocated were hiding class member
variables of the same name. Remove first two local variables as they
were only accessed once and rename third.
Now that every call to calc_usage_triple() just passes usage figures
returned by get_sectors_*(), remove those parameters, call
get_sectors_*() internally and rename to get_usage_triple().
Stop using fraction_unallocated and fraction_used member variables of
the DrawingAreaVisualDisk class as intermediate storage of partition
usage fractions. Instead get the figures straight from the partition
class and use the new calc_usage_triple() to directly set pixels widths
for the partition usage graphic.
For specific partition usage values the right hand border of the
partition graphic in the Information dialog would be displayed as grey
rather than the color assigned to the partition.
Steps to reproduce fault:
Create 1024 MiB partition
# lvm pvcreate /dev/sda12
# lvm vgcreate GParted-VG1 /dev/sda12
View partition information
Fragment from Dialog_Partition_Info::init_drawingarea():
139 else if ( partition .sector_usage_known() )
140 {
141 used = Utils::round( ( 400 - BORDER *2 ) / ( dlength / partition .get_sectors_used() ) ) ;
142 unused = Utils::round( ( 400 - BORDER *2 ) / ( dlength / partition .get_sectors_unused() ) ) ;
143 unallocated = 400 - BORDER *2 - used - unused ;
144 }
For this issue the above values are both exactly x.5 and both round
upwards, resulting in unallocated being -1.
used = round((400 - 8*2)/(2097152.0/8192)) = round(1.5)
unused = round((400 - 8*2)/(2097152.0/2088960)) = round(382.5)
unallocated = 400 - 8*2 - 2 - 383 = -1
The simple fix would be to use floor() instead of round() in the
calculation of either used or unused. The same fix would also need to
be applied in Display_Info() for the calculation of the percentage
figures. Unfortunately this simple fix can lead to odd figures when the
used or unused is close to zero and floor() or ceil() is effectively
applied rather than round(). For example:
Size: 227.23 GiB
Used: 28.00 KiB ( 1% )
Unused: 180.00 GiB ( 79% )
Unallocated: 47.23 GiB ( 20% )
Used figure of 28 KiB in 227 GiB partition should be rounded to 0% but
wasn't.
Write Partition::calc_usage_triple() which calculates the "best" figures
by rounding the smaller two figures and subtracts them from the desired
total for the largest figure. Apply to the calculation of the partition
usage percentage figures in the Information dialog and the partition
usage graphic in the same dialog and the main window.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Most file systems report intrinsic unallocated space using the statvfs()
system call when mounted, but not using their own tools. They are:
ext2/3/4, fat16/32, hfs, nilfs2, reiserfs and xfs. Showing either a
little or no unallocated space, depending on whether a file system is
mounted or not, could be confusing to the user.
When all file systems are created filling their partitions the unused
figure reported by statvfs() and their own tools are the same or very
close. Also the used plus unallocated figure from statvfs() agrees with
the used figure from their own tools.
For all file systems don't display intrinsic unallocated space (that
below the threshold of 2 to 5%), instead include it as used space. As
soon as the amount of unallocated space becomes significant display it
everywhere and also trigger the warning.
For display purposes always use the new Partition methods:
get_sectors_used(), get_sectors_unused(), and get_sectors_unallocated().
When calculating new usage figures during Paste and Resize/Move
operations directly access sectors_used, sectors_unused and
sectors_unallocated members.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Many file systems report differing percentages of unallocated space over
a range of sizes, as well differing figures using their own specific
tools or using statvfs() system call when mounted.
File systems reporting intrinsic unallocated space using their specific
tools are: jfs, lvm2 pv and ntfs. LVM2 PV has the largest amount of
unallocated space with its default Physical Extent size of 4 MiB. For a
100 MiB partition it has 4.0% unallocated space.
File systems reporting intrinsic unallocated space using the statvfs()
system call when mounted are: ext2/3/4, fat16/32, hfs, jfs, nilfs2,
ntfs, reiserfs, and xfs. Xfs has the worst identified unallocated space
of ~4.7% in a 100 MiB partition. Ext2/3 exhibit unusual behaviour by
reporting unallocated space of ~4.6% in a 100 MiB partition falling to a
constant percentage of ~1.8% for sizes of 1 GiB and above.
Update the calculation for used to estimate the maximum size of
intrinsic unallocated space. Limit is now 5% for partitions smaller
than 100 MiB, 2% for partitions larger than 1 GiB and linear scaling of
the percentage between. Will still get false unallocated space warnings
for mounted xfs file systems and lvm2 pvs smaller than 100 MiB.
Also add a short note and worked example calculation of unallocated
space to the HACKING file.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
A number of file systems report intrinsic unallocated space even when
they are created filling the partition. As reported using their own
specific tools, they are: jfs, lvm2 pv and ntfs. Therefore when
resizing a partition estimate its minimum size to be used sectors plus
any unallocated sectors up to the significant amount.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
The btrfs programs only provide approximations of file system sizes
because they display figures using binary prefix multipliers to two
decimal places of precision. E.g. 2.00GB. For partition sizes where
the contained file system size rounds upwards, GParted will fail to read
the file system usage and report a warning because the file system will
appear to be larger than the partition.
For example, create a 2047 MiB partition containing a btrfs file system
and display its size.
# btrfs filesystem show
Label: none uuid: 92535375-5e76-4a70-896a-8d796a577993
Total devices 1 FS bytes used 28.00KB
devid 1 size 2.00GB used 240.62MB path /dev/sda12
The file system size appears to be 2048 MiB, but that is larger than the
partition, hence the issue GParted has. (Actually uses the btrfs devid
size which is the size of the btrfs file system within the partition in
question).
This issue is new with the fix for Bug #499202 because it queries the
file system sizes for the first time. The same issue could
theoretically occur previously, but with the used figure (FS bytes
used). This would have been virtually impossible to trigger because
btrfs file system would have to have been greater than 99% full, but
btrfs has been notorious for early reporting of file system full.
The fix is that if a btrfs file system size appears larger than the
partition size, but the minimum possible size which could have been
rounded to the reported figure is within the partition size use the
smaller partition size instead. Apply the method to the used figure
too, in case the file system is 100% full. Also if the btrfs file
system size appears smaller than the partition size, but the maximum
possible size which could have been rounded to the reported figure is
within the partition size use the larger partition size instead to avoid
reporting, presumably false, unallocated space. Not applied to file
system used figure.
Bug 499202 - gparted does not see the difference if partition size
differs from filesystem size
When pasting a copied partition into free space or move/resizing a
partition set its space utilisation so that any unallocated space within
the partition is displayed correctly before the operation is applied.
NOTE:
If the file system does not support file system resizing the Paste and
Move/Resize dialogs don't allow resizing the partition so the preview
will always be correct, unlike the case in the previous patch:
Set unallocated space when performing simple operations (#499202)
Also remove the deprecated and no longer used Partition::Set_Unused()
and Partition::set_used() methods.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
When pasting a copied partition into an existing partition set its space
utilisation so that any unallocated space is displayed correctly before
the operation is applied. If the destination partition is larger the
file system will be grown to fill the partition.
NOTE:
GParted will attempt to grow the the file system in this situation
regardless of whether the file system supports it or not. These file
systems: exfat, hfs, hfs+, reiser4 and ufs can't be grown and will fail
with "growing is not available for this file system". The preview will
also be wrong in this case for the same reason. Everything will be
depicted correctly after the refresh.
When formatting an existing partition default its space utilisation to
unknown for display before the operation is applied.
Bug 499202 - gparted does not see the difference if partition size
differs from filesystem size
Display the unallocated space within a partition in the main window's
graphical disk representation.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Update the implementation using libparted to set the file system size
and free space, thus allowing the unallocated space in the partition to
be calculated, for the following unmounted file systems:
hfs, hfs+
(Requires libparted <= 2.4 or libparted >= 3.1, as the needed
functionality did not exist in libparted 3.0).
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Add reporting of the LVM2 Physical Volume size allowing the unallocated
space in the partition to be calculated.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Update file system specific implementations to set the size and free
space, thus allowing the unallocated space in the partition to be
calculated, for the following unmounted file systems:
btrfs, ext2, ext3, ext4, fat16, fat32, jfs, nilfs2, ntfs, reiserfs,
reiser4, xfs
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Display the unallocated space in the graphical partition representation
and numeric figures in the Partition Information dialog.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Currently GParted assumes that a file system fills its containing
partition. This is not always true and can occur when resizing is
performed outside of GParted or a resize operation fails. GParted
doesn't display any information about unallocated space to the user
and in most cases it is simply included in used space.
Add partition unallocated space accounting. Make GParted record the
unallocated space for mounted file system and display a warning in the
Partition Information dialog when too much unallocated space is found.
Partition::set_sector_usage( fs_size, fs_unused ), is the new preferred
method of recording file system usage because it allows the unallocated
space in a partition to be calculated. Partition::Set_Unused() and
Partition::set_used() are now deprecated.
NOTES:
1) Set the minimum unallocated space to be 5% before considering it
significant to avoid false reporting. Worst case found was a
mounted xfs file system in a 100MiB partition, which reports as
~4.7% unallocated according to file system size from statvfs().
However, it reports as having no unallocated space using xfs
specific tools.
2) Unallocated space is only a graphical representation for the user.
GParted must still use relevant tools to resize file systems before
shrinking the data and can't assume all unallocated space exists
after the file system at the end of the partition.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
AFAICS, there is no reason to manually copy all partition fields,
or to manually initialize the copy of the new partition object.
So now the partition object is simply copied using assignment.
AFAICS, there is no reason to manually copy all partition fields,
or to manually initialize the copy of the new partition object.
So now the partition object is simply copied using assignment.
Normally the GUI should restrict partitions from overlapping other
partitions. However we have received a report where an overlap has
occurred.
Unfortunately we did not have enough details to recreate the problem.
Based on the report my thoughts are that somehow the problem arose
due to partitions aligned to boundaries other than MiB in combination
with the size of a partition being rounded up in the GUI resizer.
In an effort to prevent this problem in the future I have added a
check for primary or extended partitions overlapping other primary or
extended partitions.
Closes Bug #661744 - libparted "Can't have overlapping partitions."
after successful move+resize?!
Ensure at least 2 sectors for Extended Boot Record (EBR) between end
of logical partition and start of next logical partition.
Ensure at least 34 sectors reserved for backup GUID Partition Table
(GPT) after the end of the last partition.
GParted_Core::set_device_partitions() creates and initialises the
partition objects based on the partitions on the disk using
partition.Reset() and partition.Set(). These methods never set the
alignment attribute.
Copy and pasting into an existing partition calls GParted_Core::
snap_to_alignment() to adjust the start and end of the newly created
in memory partition object. When pasting into unallocated space the
user has selected the required alignment and this is exactly what is
needed. However when pasting into an existing partition the in memory
partition object should always match the actual partition boundaries on
disk. Unfortunately the partition boundaries are adjusted based on
reading the uninitialised alignment attribute.
Initialise the alignment attribute of newly created partition objects to
ALIGN_STRICT. Also, when pasting into an existing partition set the
alignment of that partition object to ALIGN_STRICT so that no boundary
adjustment is performed.
valgrind:
==6845== Conditional jump or move depends on uninitialised value(s)
==6845== at 0x80C779A: GParted::GParted_Core::snap_to_alignment(...) (GParted_Core.cc:566)
==6845== by 0x810C115: GParted::Win_GParted::Add_Operation(...) (Win_GParted.cc:692)
==6845== by 0x8110499: GParted::Win_GParted::activate_paste() (Win_GParted.cc:1649)
...
==6845== Conditional jump or move depends on uninitialised value(s)
==6845== at 0x80C77A8: GParted::GParted_Core::snap_to_alignment(...) (GParted_Core.cc:568)
==6845== by 0x810C115: GParted::Win_GParted::Add_Operation(...) (Win_GParted.cc:692)
==6845== by 0x8110499: GParted::Win_GParted::activate_paste() (Win_GParted.cc:1649)
GParted_Core.cc:
562 bool GParted_Core::snap_to_alignment( const Device & device, Partition & partition, Glib::ustring & error )
563 {
564 bool rc = true ;
565
>> 566 if ( partition .alignment == ALIGN_CYLINDER )
567 rc = snap_to_cylinder( device, partition, error ) ;
>> 568 else if ( partition .alignment == ALIGN_MEBIBYTE )
569 rc = snap_to_mebibyte( device, partition, error ) ;
570
Closes Bug #672654 - Pasting into an existing partition may shrink
GParted's representation of it
When resizing an extended boot record we must ensure that at least 2
sectors is reserved in front of the nearest logical partition for the
Extended Boot Record.
Please note that unless specifically told otherwise, the Linux kernel
considers Extended Boot Records to be two sectors long, in order to
"leave room for LILO".
Closes Bug #664050 - Unable to resize extended partition
Previously used "fsck.reiser4" to perform a file system check with a by
product of outputting the uuid. However this performs a lot of disk I/O
and takes a while to complete. Instead use the much faster and less
resource intensive "debugfs.reiser4" tool to retrieve the uuid.
The parted-3.1 release brings back FAT16/FAT32 and HFS/HFS+ file
system resize capabilities in a new libparted fs resize library.
The following operations are again available when GParted is linked
with parted-3.1:
FAT16 - grow and shrink
FAT32 - grow and shrink
HFS - shrink
HFS+ - shrink
Note that there is a difference in how move actions are handled for
FAT16/FAT32 file systems based on parted version.
When GParted is linked with parted >= 3.0:
FAT16 - move performed internally by GParted
FAT32 - move performed internally by GParted
When GParted is linked with parted < 3.0:
FAT16 - move performed by libparted
FAT32 - move performed by libparted
Thanks goes to Jim Meyering for restoring these file system resizing
capabilities in Parted 3.1 with a new libparted fs resize library.
Closes Bug #668281 - minimal file-system resize API? (FAT and HFS*
only)
The setting of the write label capability for linux-swap was lost
when it was overwritten in the following commit:
Add support for setting UUID (#667278)
9e96159bb2
Even if invalid, the first filesystem in list is always included.
This is an off-by-one error, which was triggered when the first member
of FILESYSTEMS was no longer a regular filesystem, as a result of
commit ce9feeda0e9a04da04cec0a1b01512ed68c2495c:
'Make FileSystem objects in GParted_Core accessible and usable by others'
This assumption was invalidated by commit
ce9feeda0e9a04da04cec0a1b01512ed68c2495c:
'Make FileSystem objects in GParted_Core accessible and usable by others'
This patch removes the dependency on this implicit assumption.
Since linux-swap does not contain data and does not have a resize
command, linux-swap is recreated instead of moved, copied, or resized.
GParted 0.11.0 contained the following enhancement:
Bug #663980 - Avoid redundant file system maximize actions
An unfortunate side effect of this change was that the required
maximize action to recreate linux-swap would not occur when the new
size for the partition was less than or equal to the original size.
The changes associated with this commit address this regression.
Closes Bug #670017 - Corrupting swap partitions
Also update to use LVM terminology, such that a Physical Volume is
referred to as a member of a Volume Group. Status of an LVM2 PV is now
displayed using one of the following messages:
Not active (Not a member of any volume group)
VGNAME not active
VGNAME not active and exported
VGNAME active
Bug #160787 - lvm support
GParted would crash if there were any embeded spaces in the output from
the command used to query LVM2 PVs. There aren't normally any embeded
spaces, but they can occur in certain degrated situations. For example
if one of the PVs in a VG spanning two PVs is lost the PV is displayed
as "unknown device" rather than its actual device name:
# lvm pvs --nosuffix --units b --separator , -o pv_name,pv_free,vg_name,lv_name,lv_attr
Couldn't find device with uuid DMEi8r-9Vvy-w0Ok-CSSn-oLmY-YrY3-1PBznz.
PV,PFree,VG,LV,Attr
/dev/sda11,2143289344,GParted-VG1,,
unknown device,1619001344,GParted-VG1,lvol0,-wi---
unknown device,1619001344,GParted-VG1,,
This was loaded into the cache as:
["/dev/sda11,2143289344,GParted-VG1,,",
"unknown",
"device,1619001344,GParted-VG1,lvol0,-wi---",
"unknown",
"device,1619001344,GParted-VG1,,"]
The crash would happen when trying to access the VG name or LV flags on
a line without enough comma separated fields.
Improve parsing of the output from "lvm pvs" so that lines are not split
on embeded spaces. Don't crash on lines without without enough comma
separated fields.
Bug #160787 - lvm support
Previously any errors which occurred when running LVM commands used to
load the LVM2_PV_Info cache were simply ignored and the cache wasn't
loaded. This lead to missing information about LVM2 PVs, but the user
had no indication as to why.
Now when any errors occur the command ran and all output is captured.
This is displayed to the user, along with a suitable warning message, in
the Partition Information dialog.
Bug #160787 - lvm support
Btrfs file system can be successfully resized to the same size without
failing on Linux 3.2 or higher.
Linux 3.2-rc4 includes commit:
35bae54a255fbf3eab747b842d300d59f6e1abb4
Btrfs: Don't error on resizing FS to same size
Closes bug #669389
Create function Utils::kernel_version_at_least() to check that the
current Linux kernel is a particular version or higher.
Update nilfs2 to use this function to determine whether the kernel is
new enough to support file system resizing.
Restructure and word-smith translatable text associated with the
enhancement to add ability for setting UUID in an effort to better
align with the Gnome Documentation Style Guide.
See Bug #667278 - Add support for setting UUID
Determine the FS type before checking whether a FS is busy,
and check LVM only for LVM PVs.
Remove the LVM busy check for extended partitions, as they
don't contain LVM PVs - or any other FS for that matter.
(and even if they did, the rest of the code silently assumes
they don't...)
Previously used "dmsetup info" to directly list device-mapper mapping
names in the kernel to identify active Logical Volumes. However GParted
failed to recognise active LVs if the VGNAME contains any hyphens (-).
This is because LVM encodes hyphens as double hyphens in the mapping
name.
To avoid having to duplicate the LVM hyphen encoding in GParted, switch
to using "lvm lvs" to list LVs.
# dmsetup info --columns --noheadings --separator , -o name
GParted_VG1-lvol_00
GParted--VG2-lvol--00
# lvm lvs --noheadings --separator , -o lv_name,vg_name,lv_attr
lvol_00,GParted_VG1,-wi-a-
lvol-00,GParted-VG2,-wi-a-
lvol-01,GParted-VG3,-wi---
.^.
(-) not active, (a) or any other character considered active. Reference
lvs(8).
Bug #160787 - lvm support
A Volume Group is active when any of its Logical Volume mappings are
loaded (and enabled) in the Kernel's device-mapper driver. Therefore
all the Physical Volumes in the VG (must be considered) active too.
This is exactly equivalent to a mounted file system, as the kernel is
actively using the partition. Mark active LVM2 PVs as busy in GParted.
Don't use statvfs() for determining sector usage of busy LVM2 PVs as it
will fail with "statvfs(VGNAME): No such file or directory". Instead
always use the LVM2 PV specific method.
Display the status of the LVM2 PV in the Information dialog using one of
the following relevant messages:
Not active (Not part of any volume group)
VGNAME not active
VGNAME active
(The code uses the VGNAME stored in the partition's first mount point,
as displayed in the "Mount Point" column, rather than going back to the
primary source of the information in the LVM2_PV_Info class).
Temporarily prevent GParted from offering to unmount LVM2 PVs until
activating and deactivating Volume Groups is implemented later.
Bug #160787 - lvm support
As the Mount Point column is being borrowed to display the PV's VGNAME,
also suppress generation of the "Mount on" submenu for LVM2 PVs.
Bug #160787 - lvm support
Previously when GParted was started LVM2_PV_Info cache was loaded twice,
executing LVM2 PV querying commands twice. Firstly when
lvm2_pv::get_filesystem_support() was checking if LVM2 PV support was
available, and secondly when forced by a refresh in
GParted_Core::set_devices().
Implement lazy initialization. Only load the cache when forced by the
above mentioned refresh or having to return a value when the cache is
not yet loaded. Do not initialize the cache when just checking if LVM2
PV support is available.
Bug #160787 - lvm support
Cache results from querying all LVM2 PVs in one go to minimise the
number of times lvm commands are executed. Take inspiration from
caching performed by FS_Info and Proc_Partitions_Info.
Bug #160787 - lvm support
Newly created LVM2 PVs, before being added to a Volume Group, report
free space equal to the partition size. Allow free space to equal
partition size.
# parted /dev/sda10 unit B print
Error: /dev/sda10: unrecognised disk label
Model: Unknown (unknown)
Disk /dev/sda10: 2147483648B
Sector size (logical/physical): 512B/512B
Partition Table: unknown
# lvm pvcreate /dev/sda10
Writing physical volume data to disk "/dev/sda10"
Physical volume "/dev/sda10" successfully created
# lvm pvs --units b -o pv_free /dev/sda10
PFree
2147483648B
Add minimal support for just reporting the space usage of LVM2 PVs.
Accept libparted / blkid detection of LVM2 PVs first, falling back on
GParted's specific detection code otherwise. Maintain LVM not supported
warning message.
Bug #160787 - lvm support
This is the first step of adding support for just LVM2 Phyiscal Volumes,
a subset of full LVM2 support.
Make it clear that it is only LVM2 PVs being treated like a file system.
Bug #160787 - lvm support
Moving the start sector of an extended partition should not adversely
affect booting an operating system because an extended partition is
only a container for logical partitions.
Add the ability to set a new random UUID on file systems that provide
the appropriate tools to perform this action.
Update the help manual to include this new functionality. Also add
reference links to "setting a partition label" and "changing a
partition UUID" in the "copying and pasting a partition" section.
This patch does not include setting the UUID on an NTFS file system.
Bug #667278 - Add support for setting UUID
Bug #608308 - fix documentation - Copying and Pasting a Partition
Inserted cast to int so that third parameter matches expected
parameter precision type.
Original warning:
FileSystem.cc: In member function ‘Glib::ustring
GParted::FileSystem::mk_temp_dir(const Glib::ustring&,
GParted::OperationDetail&)’:
FileSystem.cc:81:69: warning: field precision should have type ‘int’,
but argument 3 has type ‘long unsigned int’
Increase sleep time to decrease pulse bar update frequency.
Debian Bug 499193 - gparted: 100% cpu usage
Debian Bug 519764 - gparted: Lots of animation makes use over SSH
X-tunnel slow
There is a lot of commonality and code repetition for resizing of file
systems which can only be resized while mounted. Resizing of btrfs, jfs
and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir.
Copying an xfs file system also uses a similar pattern, but for the
source and destination xfs file systems simultaneously.
Add three helper functions to the FileSystem class which implement
common tasks, allowing mounted file system resizing to be implemented
more simply.
Also add a function to the Utils class which checks whether the kernel
supports a file system. It handles the case of non-loaded modules,
which currently leads to reporting the growing of jfs and xfs as
unsupported.
We used to just log libparted exceptions without handling them. This patch
changes the exception handler to display a modal dialog box and return the
chosen action to libparted.
The call to "blkid -c /dev/null" on Precise Pangolin Alpha 1 takes
exceedingly long. This occurs when the BIOS is incorrectly set to
indicate a floppy drive is present when none is physically installed.
Use cached blkid results instead.
Ubuntu launchpad 910379 - Gparted does not start and continues to
scan devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/910379
Setting the status and controlling the timing of operation details
initialised with OperationDetail(desc, status, font) uses a conditional
branch depending on the uninitialised variable this->status.
valgrind:
==28957== Conditional jump or move depends on uninitialised value(s)
==28957== at 0x80E4287:
GParted::OperationDetail::set_status(GParted::OperationDetailStatus)
(OperationDetail.cc:77)
OperationalDetail.cc:
75 void OperationDetail::set_status( OperationDetailStatus status )
76 {
>> 77 if ( this ->status != STATUS_ERROR )
78 {
79 switch ( status )
80 {
Requires libparted 2.4 or higher, or blkid from utils-linux 2.20 or
higher for nilfs2 file system detection.
Requires nilfs-utils for nilfs2 file system support.
Closes Bug #642842 - nilfs is not detected
When GParted performed operations or combinations of operations,
such as:
a) copy to same or smaller size destination partition
b) move to same or smaller size due to alignment change
c) resize to smaller size
a redundant maximize file system operation would occur.
Normally these redundant maximize operations to grow the file
system to take up all the space in the partition were not harmful.
However in situations where libparted failed to inform the kernel
of partition changes, then the extra maximize operation would
grow the file system to be the original partition size. In cases
where the original partition was larger than the new partition
size, this caused problems because the file system would be
larger than the partition on reboot.
This enhancement avoids redundant file system maximize actions on
copy, move, and resize, and should help reduce problems described
in the following links:
WARNING! Problem Resizing File Systems with GParted
http://gparted-forum.surf4.info/viewtopic.php?id=13777
Bug #601574 - ERROR: Current NTFS volume size is bigger than the
device size!
Bug #604298 - Problems resizing file systems with
gparted-live-0.5.0-3
Closes Bug #663980 - Avoid redundant file system maximize actions
on copy, move, and resize
Btrfsctl and btrfs-show were depreciated in October 2011 and have been
superseeded by the newer btrfs multi-tool control command. Use btrfs as
first choice, falling back to btrfsctl and btrfs-show when not found.
There are still 2 issues with reading btrfs labels when falling back
on using btrfs-show command, rather than primary method of using the
blkid command:
1) Label is set no "none" when btrfs-show is reporting there is no
label, although it is impossible to distinguish from the case of the
label actually being set to "none".
2) The label has 2 trailing spaces appended as the regular expression
matches "Label: (btrfslabel )uuid:" rather than
"Label: (btrfslabel) uuid:" in the btrfs-show output.
Assume a label "none" means there is no label and fix the regular
expression.
Note that this enhancement changes GParted to first try the native
tools to determine the volume label for all file systems. If the
volume label is not found then the fall back method is to use blkid.
There is a small degradation in device refresh times as a result of
this change.
Closes Bug #662537 - Ext4 unicode labels not shown correctly
Fix bug introduced in GParted 0.9.0 in commit
4a8fef9822 to address ISO C++ ambiguity
compiler warning.
Due to the nature of the surrounding code, this bug was not evident
in the log file output.
Thanks to Magnus Fromreide for finding this bug.
When a new operation is added to operations list, check if a merge
is possible depending on the operation type:
OPERATION_RESIZE_MOVE: 2 consecutive "resize" operations on the
same partition
OPERATION_LABEL_PARTITION: 2 "label change" operations (need not be
consecutive) on the same partition
OPERATION_CHECK: 2 "check" operations (need not be
consecutive) on the same partition
OPERATION_FORMAT: 2 consecutive "format" operations on the
same partition
Closes Bug #438573 - Cancel out overlapping actions
Also fix a bug when copying partition using the Partition::Set(...)
method. This method did not initialize "sectors_used" and
"sectors_unused" members.
Due to a change in error handling behaviour in ntfsresize version
2.011.4.12AR.4 (libntfs-3g) GParted would fail to properly resize ntfs
file systems if the file system was marked for consistency check.
The current maintainer of ntfsprogs provided the following advice:
"Well, though I am reverting back to the old behavior, you should
add -ff instead of relying on an unspecified behavior when
ntfsresize gets an error when trying to read the reply. I suppose
you do not connect the stdin of ntfsresize, hence the error. With
-ff no question is asked (I stress : even with the old
ntfsresize)."
Hence I have added a second "--force" option to the ntfsresize command
for resizing NTFS file systems.
Closes Bug #655215 - NTFS partition resize fails
Enhance code to pass compiler warning. Prior to this change the
compiler would complain with the following message:
error: ISO C++ says that these are ambiguous, even though the worst
conversion for the first is better than the worst conversion for the
second: /usr/include/c++/4.5/bits/postypes.h:192:7: note: candidate 1:
std::fpos<_StateT> std::fpos<_StateT>::operator-(std::streamoff) const
[with _StateT = __mbstate_t, std::fpos<_StateT> =
std::fpos<__mbstate_t>, std::streamoff = long int] Utils.cc:443:27:
note: candidate 2: operator-(std::streamoff, long long int) <built-in>
Add code to handle situation where realpath might return a NULL value.
Prior to this change the compiler would complain with the following
message:
error: ignoring return value of ‘char* realpath(const char*, char*)’,
declared with attribute warn_unused_result
Removed expression that is always true. Prior to this change the
compiler would complain with the following message:
error: comparison of unsigned expression >= 0 is always true
Add code to handle situation where mkdtemp(char*) function returns
with a NULL value. Prior to this code the compiler would complain
with the following message:
error: ignoring return value of ‘char* mkdtemp(char*)’, declared with
attribute warn_unused_result
Some classes contained private attributes which were used only by a single
member function. Such items were moved to the corresponding function implementations
to stress their limited usage scope.
A few unused variables were also deleted.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
The release of (lib)parted 3.0 includes a change to the Application
Programing Interface - API. Most importantly, libparted 3.0 removes
many file system specific function calls, and hence the capabilities
provided by these functions. In order for GParted to compile and link
with libparted 3.0, this libparted functionality is lost.
Specifically, the functionality that is lost when GParted is compiled
and linked with libparted 3.0 is as follows:
- Loss of ability to grow and shrink FAT16 and FAT32 file systems
- Loss of ability to shrink HFS and HFS+ file systems
- Loss of ability to determine used and unused sectors in HFS and
HFS+ file systems
- Loss of ability to erase file system signatures on partition
create and format
It is hoped that other free software projects will include some or all
of the above lost functionality, which can then be added back to
GParted.
This commit includes a change in how FAT16 and FAT32 file systems are
moved. Specifically the move is now performed internally by GParted
when linked with libparted 3.0. The move functionality is provided by
libparted for prior libparted versions (e.g. less than 3.0).
This is the final enhancement in a series of commits that enable
GParted to compile with libparted version 3.0.
Closes Bug #651559 - Doesn't compile against parted 3.0
On disks with an unrecognized disk label, the end sector value
was saved as one sector larger than actual. This caused the
Partition Information dialog to report the end sector value and
the total number of sectors on the disk as one larger than the
actual value.
Closes Bug #649444 - Partition information reports wrong sector
count
I hit this performance bug when I cloneda 40G NTFS partition. The actual
copy was done in under 11 minutes. After that I was shocked to find that
gparted would spend over 12 minutes in cleanup_cursor, pegging a CPU
core. (On a quad core desktop...)
Simply replacing the ustring with std::string would reduce the time to
about 1.5 minutes. Still bad. Also, I didn't want to lose UTF8
awareness.
So I rewrote the algorithm in 'streaming mode'. This has the (potential)
drawback that locale conversions are done, but performs well and
- IMHO - is a lot more readable.
On a minor note: this implementation correctly handles backspaces at the
start of a line.
Change spawn_command_line_sync to spawn_sync to reduce the level of
quoting required when passing commands to the function. Since
spawn_command_line_sync uses the parent's environment, the replacement
call also uses the parent's environment.
This change permits unmounting of file systems mounted with an
apostrophe in the mount point name.
Ubuntu launchpad bug 151796 - Can't unmount partition with apostrophe
in label
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/151796
Usage of the kpartx package to create partition names has been
completely removed. Hence kpartx is no longer even an optionally used
package by gparted.
This change is related to the following bug report:
Ubuntu launchpad bug 719129 - [Natty] Gparted duplicates dmraid
partition devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/719129
The new configure option --enable-libparted-dmraid enables the native
use of /dev/mapper dmraid support in the libparted library.
If this option is not specified, or is disabled, then gparted code
will be used to support dmraid. The gparted code uses the old dmraid
partition naming scheme of always appending the partition number to
the device name. The letter 'p' is not inserted between the device
name and the partition number. The gparted code is particularly
useful when used with older versions of libparted that do not support
/dev/mapper dmraid.
Ubuntu launchpad bug 719129 - [Natty] Gparted duplicates dmraid
partition devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/719129
Added a display refresh to the event queue to address this
problem.
Previously, the display area of the visual disk seemed to
disappear when enough operations had been added to the queue so
that a scrollbar was required (about 4 operations).
If the three lines in HBoxOperations::load_operations method for
"//make scrollwindow focus on the last operation in the list"
were commented out then this also prevented the problem from
occurring.
Interestingly, if I changed the "set_cursor" method to
a "scroll_to_row" method, then this problem does not occur for an
additional 2 operations (about 6 operations total).
Ubuntu launchpad bug 583746 - Partition graph disappears after a
swap partition has been deleted
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/583746
Previously when creating a new partition on a device with 512
byte sectors with 7 MiB chosen and cylinder alignment, the
snap_to_cylinder logic would round up to 2 cylinders (~15.69
MiB), instead of the correct 1 cylinder (~7.84 MiB).
Re-work logic for copying a cylinder aligned partition to a new
MiB aligned partition. Previously this was partially fixed in
bug #626946 - Destination partition smaller than source partition
Closes Bug #639393 - Redux: Destination partition smaller than
source partition
Use mntent C library to read mount point files such as
/etc/fstab, /etc/mtab, and /proc/mounts.
Closes bug #629592 - Unable to find Mount Point if it contains a
Space Character
The reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
This reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
Enhance code so that all calls to the ped_partition_get_path
function in the libparted library go through one
GParted_Core::get_partition_path method.
This one method makes the appropriate adjustments to the dmraid
partition path name as required.
Closes bug #634553 - ntfsresize fails on RAID array
This problem would occur when using align to MiB for the
destination partitions.
Closes bug #628863 - gparted crashes applying move to right of
more than one logical partition
This new URL is actually an html redirect to the actual page
location. This permits us the flexibility to move the actual
page wherever is needed on the web site without the need to
change the URL location in the code.
Correct problem introduced in version 0.6.3 whereby move or copy
operations using MiB alignment resulted in the destination
partition being 1 MiB larger.
Closes bug #632478
GParted already has basic support only to recognize Btrfs volumes; if
configured, use our newer methods to handle them.
Also, put in place interface controls for all supported generic actions.
This adds initial handlers for Btrfs; only .create, .check and
.read_label are done for now, via external btrfs-tools.
Other methods are still only stubs.
Mike Fleetwood