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
Use of execute_command_timed() was removed by this commit from
2013-02-22:
52a2a9b00a
Reduce threading (#685740)
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
When configuring GParted build with libparted from GIT it may perform
the version compares incorrectly and think the version of libparted is
higher that it actually is. Libparted uses the number of commits from
the last git tag as the third part of the version number.
For example install libparted from one commit before release 3.1, 142
commits after release 3.0.
$ git checkout v3.1^
$ describe
v3.0-142-g82327a3
$ ./bootstrap
$ ./configure --prefix=/tmp/parted-3.0-git
$ make && make install
Configure GParted:
$ export CPPFLAGS=-I/tmp/parted-3.0-git/include
$ export LDFLAGS=-L/tmp/parted-3.0-git/lib
$ export LD_RUN_PATH=/tmp/parted-3.0-git/lib
$ export PKG_CONFIG_PATH=/tmp/parted-3.0-git/lib/pkgconfig
$ ./configure
...
checking for libparted >= 1.7.1 (querying pkg-config)... 3.0.142-8232
checking for 2.0 <= libparted <= 3.0 (loop table creation doesn't delete old partitions)... (cached) no
checking for libparted >= 2.2 (improved pt re-read)... (cached) yes
checking for ped_file_system_resize in -lparted... no
checking for ped_file_system_resize in -lparted-fs-resize... yes
checking for libparted >= 3.2 (online resize)... (cached) no
...
Libparted is reported as version 3.0.142, but checking of the version
between 2.0 and 3.0 inclusive fails.
The configure script is multiplying components of the version by 100
when adding them together.
$ echo 3.0.142-8232 | awk -F. '{print $1 * 10000 + $2 * 100 + $3}'
30142
So it is only allowing up to 99 commits before it is equivalent to the
second minor number increasing by one. Increase the multiplication
factor to 10000, allowing up to 9999 commits between releases. An order
of magnitude more commits than so far seen between parted releases.
Bug 753525 - Configuration issues when using non-system location or
non-released versions of libparted
When configuring GParted build with a custom install of libparted the
configure script is using the wrong version number for the version of
libparted. It uses the version of the system install of libparted,
rather that the version of the specified custom install of libparted.
For example configuring GParted build on CentOS 7 with system provided
libparted 3.1 and custom install of libparted 3.2 from GIT in
/tmp/parted-3.2-git:
$ export CPPFLAGS=-I/tmp/parted-3.2-git/include
$ export LDFLAGS=-L/tmp/parted-3.2-git/lib
$ export LD_RUN_PATH=/tmp/parted-3.2-git/lib
$ ./configure
...
checking for libparted >= 1.7.1 (querying pkg-config)... 3.1
checking for 2.0 <= libparted <= 3.0 (loop table creation doesn't delete old partitions)... (cached) no
checking for libparted >= 2.2 (improved pt re-read)... (cached) yes
checking for ped_file_system_resize in -lparted... no
checking for ped_file_system_resize in -lparted-fs-resize... yes
checking for libparted >= 3.2 (online resize)... (cached) no
...
$ make
$ ldd src/gpartedbin | fgrep libparted
libparted-fs-resize.so.0 => /tmp/parted-3.2-git/lib/libparted-fs-resize.so.0 (0x00007f9a460ee000)
libparted.so.2 => /tmp/parted-3.2-git/lib/libparted.so.2 (0x00007f9a45ea3000)
Configure script used version 3.1 as reported by pkg-config to make most
of the decisions (those version related checks with cached results) but
the executable was still linked with the custom libparted 3.2 install.
Temporarily rename the system libparted pkg-config file out of the way:
# cd /usr/lib64/pkgconfig
# mv libparted.pc libparted.pc-NOT
and reconfigure the GParted build:
$ ./configure
...
checking for libparted >= 1.7.1 (querying pkg-config)... not found
checking for libparted >= 1.7.1 (querying libparted)... 3.2.25-5a92
checking for 2.0 <= libparted <= 3.0 (loop table creation doesn't delete old partitions)... (cached) no
checking for libparted >= 2.2 (improved pt re-read)... (cached) yes
checking for ped_file_system_resize in -lparted... no
checking for ped_file_system_resize in -lparted-fs-resize... yes
checking for libparted >= 3.2 (online resize)... (cached) yes
...
Now configure is having to compile a program with the custom install of
libparted and gets the correct version.
Restore libparted pkg-config file:
# mv libparted.pc-NOT libparted.pc
and this time set environment variable PKG_CONFIG_PATH to inform
pkg-config of the additional directory to search for .pc files before
the default system location:
$ export PKG_CONFIG_PATH=/tmp/parted-3.2-git/lib/pkgconfig
$ ./configure
...
checking for libparted >= 1.7.1 (querying pkg-config)... 3.2.25-5a92
checking for 2.0 <= libparted <= 3.0 (loop table creation doesn't delete old partitions)... (cached) no
checking for libparted >= 2.2 (improved pt re-read)... (cached) yes
checking for ped_file_system_resize in -lparted... no
checking for ped_file_system_resize in -lparted-fs-resize... yes
checking for libparted >= 3.2 (online resize)... (cached) yes
...
Now configure is getting the correct version of the custom install of
libparted when querying pkg-config and thus making the correct
decisions.
Update the README file to reflect the need to also set the
PKG_CONFIG_PATH environment variable when building GParted with a custom
install of libparted.
Bug 753525 - Configuration issues when using non-system location or
non-released versions of libparted
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
Update the README file to document the blkid command as a mandatory
requirement for GParted. GParted will run without blkid but it is
needed to detect a number of file systems which libparted doesn't and in
a number of other situations.
Blkid is needed to detect these file systems:
exfat
f2fs
ReFS
SWRaid
ZFS
Blkid also detects these file systems (for which GParted has simple
internal detection but libparted, mostly, doesn't detect):
btrfs (detected by libparted >= 3.2)
LVM2 PV
LUKS
nilfs2 (detected by libparted >= 2.4)
reiser4
Blkid is also needed for these commits:
1) f8faee6377
Avoid whole disk FAT being detected as MSDOS partition table (#743181)
(with libparted 1.9.0 to 2.3 inclusive)
2) 9e5e9f5627
Enhance file system detection to use FS_Info method - blkid
(Detect file systems with sector sizes other than 512 bytes with
libparted 2.2)
Other changes to the DISTRIBUTION NOTES section of the README file:
* Drop NOTE about vol_id and blkid being used to read volume labels for
specific file systems and read the UUIDs. Vol_id was deprecated in
May 2009 and is not included in any currently supported distribution.
Blkid is now mandatory. List of optional commands at the end of the
section seems to cover everything that is necessary.
* Indent description of optional commands at the end of the section to
match the indentation earlier in the section.
* Line wrap the section at column 72 to match the rest of the file.
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
Pedro Albuquerque