ISSUE OVERVIEW
When GParted tries to resize an open LUKS encryption mapping and the
volume (master) key was stored in the kernel keyring service [1] it
fails like this:
Check and repair file system ([Encrypted] ext4) on /dev/...(ERROR)
+ calibrate /dev/sdd1 (SUCCESS)
+ check file system on /dev/mapper/sdd1_crypt for errors...(SUCCESS)
+ grow encryption volume to fill the partition (ERROR)
+ cryptsetup -v resize 'sdd1_crypt' (ERROR)
Command failed with code -1 (wrong or missing parameters).
Nothing to read on input.
This error occurs with cryptsetup >= 2.0, kernel >= 4.10 and LUKS2
format because the crypt Device-Mapper target no longer has the volume
key so cryptsetup resize prompts for a passphrase, but GParted doesn't
provide it.
THIS COMMIT
Additionally capture the location of the volume (master) key location
for active encryption mappings. Do this the using the same method that
cryptsetup uses [2][3]. Namely if the first character of the KEY is a
":" then the key *was* stored in the kernel keyring service, otherwise
it *is* store in the Device-Mapper crypt target as previously.
# echo -n badpassword | cryptsetup luksFormat --type luks1 /dev/sdb1 -
# echo -n badpassword | cryptsetup luksOpen /dev/sdb1 sdb1_crypt
# cryptsetup status sdb1_crypt | egrep 'type|key location'
type: LUKS1
key location: dm-crypt
# echo -n badpassword | cryptsetup luksFormat --type luks2 /dev/sdb2 -
# echo -n badpassword | cryptsetup luksOpen /dev/sdb2 sdb2_crypt
# cryptsetup status sdb2_crypt | egrep 'type|key location'
type: LUKS2
key location: keyring
# dmsetup table --target crypt
sdb1_crypt: 0 520192 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:17 4096
sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
^
First character of the KEY field --------------'
[1] Integration with the kernel keyring service
https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/Keyring.txt
"
Starting with cryptsetup 2.0 we load [Volume Key] VK in kernel
keyring by default for LUKSv2 devices ...
In summary, the key description visible in dm-crypt table line is a
reference to VK that usually no longer exists in kernel keyring
service if you used cryptsetup to for device activation.
"
[2] cryptsetup/v2.3.5/lib/libdevmapper.c:_dm_target_query_crypt()
https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/lib/libdevmapper.c#L2031
if (key_[0] == ':')
*act_flags |= CRYPT_ACTIVATE_KEYRING_KEY;
[3] cryptsetup/v2.3.5/src/cryptsetup.c:action_status()
https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/src/cryptsetup.c#L839
log_std(" key location: %s\n", (cad.flags & CRYPT_ACTIVATE_KEYRING_KEY) ? "keyring" : "dm-crypt");
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
When GParted probes an open encryption mapping which is either blank or
contains a file system which libparted doesn't recognise, such as:
exfat, f2fs, lvm2 pv, minix or reiser4, then the partition also gets
this warning message:
/dev/mapper/sdb11_crypt: unrecognised disk label
Clear the message so that it isn't shown in the GUI.
Note that the message is still written to stderr by GParted, like all
libparted exceptions are. This is done by GParted's libparted exception
handler:
GParted_Core::ped_exception_handler()
_ped_exception_handler()
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
The previous commit "Resolve empty drive displayed as blank minor logic
issue (#152)" left the code in set_device_and_disk() some what
unsightly.
Refactor the whole function. Use if fail return early pattern for
failure of the get_device() call at the start of the function. Reorder
the 4 cases into a single depth if then else if chain. Hopefully this
is a little easier to follow.
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
The previous commit "Remove coding landmine in get_disk() (#152)" made
an empty drive without a disk label (partition table) display as
nothing, instead of the normal single unallocated partition with warning
"unrecognised disk label".
The previous commit said:
3. The two remaining direct calls to get_disk() where the strict
parameter is explicitly set to false, from set_device_from_disk()
and detect_filesystem_in_encryption_mapping(), are when scanning.
As the pass strict=false they don't allow the PedDevice deletion
to occur if no recognised disk label is found.
This is true, but get_disk(..., strict=false) additionally returned true
even if there was no disk label. And in set_device_from_disk() the
empty drive case is inside the if branch of the get_disk() call
returning true.
Simply fix this by calling get_disk(), ignoring the return value.
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
get_disk() is the wrapper around libparted's ped_disk_new() which reads
a disk label from the specified device and if successful creates the in
memory PedDisk object to represent it. In the case that libparted
doesn't recognise a disk label or a file system, having get_disk() go
and destroy the passed in PedDevice object via parameter lp_device is
very unexpected behaviour hence describing it as a coding landmine.
BACKGROUND
1. Early on GParted only worked with devices with valid disk labels.
FileSystem.h:open_device_and_disk() required both ped_device_get()
and ped_disk_new() to succeed or neither to succeed.
2. Commit [1] added support for devices which didn't yet have a disk
label. open_device_and_disk() had default parameter strict=true
added. While scanning strict=false was passed which allowed
open_device_and_disk() to return success if only ped_device_get()
succeeded and ped_disk_new() failed when the disk was empty. All
other times open_device_and_disk() was called with default
strict=true, still requiring both or neither to succeed.
3. Commit [2] added support for whole disk file systems. The now named
get_device_and_disk() had it's functionality split between
get_device() and get_disk(). This result in the code landmine being
left behind: get_disk() destroying the passed device object if
default parameter strict=true and no disk label or file system was
detected.
ANALYSIS
1. Since support for whole disk file systems [2] all current calls to
get_device_and_disk() let the strict parameter default to true and
are only called on known partitions within disk labels when applying
a change to that partition. Therefore they don't care about the
behaviour of get_disk(), just that get_device_and_disk() maintains
that both ped_device_get() and ped_disk_new() succeed or neither
succeed.
2. Two direct calls to get_disk() where the strict parameter defaults to
true, from calibrate_partition() and erase_filesystem_signatures(),
only do so on known partitions within disk labels as part of applying
a change to that partition. Therefore ped_disk_new() will succeed
and so PedDevice isn't deleted when not wanted.
3. The two remaining direct calls to get_disk() where the strict
parameter is explicitly set to false, from set_device_from_disk() and
detect_filesystem_in_encryption_mapping(), are when scanning. As the
pass strict=false they don't allow the PedDevice deletion to occur if
no recognised disk label is found.
FIX
Remove the strict parameter from get_disk() and get_device_and_disk() as
it's no longer needed. Remove the code landmine by removing the side
affect of destroying the PedDevice object if a disk label isn't found.
Make sure get_device_and_disk() maintains the all or nothing behaviour.
Also don't pass lp_device by reference to a pointer to get_disk() so the
code can't change where lp_device points.
[1] 038c5c5d99
P (special thanks to mantiena-baltix for bringing this issue to my
[2] 51ac4d5648
Split get_device_and_disk() into two (#743181)
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
As discussed in the previous commit "Don't crash probing libparted
unrecognised encrypted file system (#152)", detect_filesystem() accepted
a NULL lp_device pointer and dereferenced it leading to the crash.
Document the requirement for lp_device parameter to be non-NULL via an
assert and also correctly const the parameters.
This forces needing to const the lp_partition parameter to
get_partition_path() too. Also assert it's non-NULL requirement.
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
Create a LUKS encrypted partition and open it. Then either leave the
contents blank or create a file system which libparted doesn't
recognise, such as: exfat, f2fs, lvm2 pv, minix or reiser4. When
GParted probes the disk device it crashes.
# echo -n badpassword | cryptsetup luksFormat /dev/sdb11
# echo -n badpassword | cryptsetup luksOpen /dev/sdb11 sdb11_crypt
# ./gpartedbin /dev/sdb
GParted 1.2.0-git
configuration (none)
libparted 3.1
/dev/mapper/sdb11_crypt: unrecognised disk label
Segmentation fault (core dumped)
Backtrace:
#0 0x0000000000460f68 in GParted::GParted_Core::detect_filesystem(_PedDevice*, _PedPartition*, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
(lp_device=0x0, lp_partition=0x0, messages=std::vector of length 0, capacity 0)
at GParted_Core.cc:1235
#1 0x00000000004615a6 in GParted::GParted_Core::detect_filesystem_in_encryption_mapping(Glib::ustring const&, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
(path=..., messages=std::vector of length 0, capacity 0)
at GParted_Core.cc:1096
#2 0x00000000004647c8 in GParted::GParted_Core::set_luks_partition(GParted::PartitionLUKS&)
(this=this@entry=0x7fff43f974e0, partition=...)
at GParted_Core.cc:1011
#3 0x000000000046511b in GParted::GParted_Core::set_device_partitions(GParted::Device&, _PedDevice*, _PedDisk*)
(this=this@entry=0x7fff43f974e0, device=..., lp_device=0x7efc780008c0, lp_disk=0x7efc78000d10)
at GParted_Core.cc:883
#4 0x00000000004658e3 in GParted::GParted_Core::set_device_from_disk(GParted::Device&, Glib::ustring const&)
(this=this@entry=0x7fff43f974e0, device=..., device_path=...)
at GParted_Core.cc:704
#5 0x0000000000465fff in GParted::GParted_Core::set_devices_thread(std::vector<GParted::Device, std::allocator<GParted::Device> >*)
(this=0x7fff43f974e0, pdevices=0x7fff43f96bc8)
at GParted_Core.cc:266
#6 0x00007efc99ba413d in call_thread_entry_slot ()
at /lib64/libglibmm-2.4.so.1
#7 0x00007efc97dc8555 in g_thread_proxy ()
at /lib64/libglib-2.0.so.0
#8 0x00007efc96ab4ea5 in start_thread () at /lib64/libpthread.so.0
#9 0x00007efc967dd9fd in clone () at /lib64/libc.so.6
The relevant sequence of events goes like this:
detect_filesystem_in_encryption_mapping(path, ...)
lp_device = NULL
get_device(path, lp_device)
lp_device = ped_device_get(path.c_str())
return true
lp_disk = NULL
lp_partition = NULL
get_disk(lp_device, lp_disk) // + default parameter strict=true
lp_disk = ped_disk_new(lp_device)
// No libparted recognised disk label or file system found, so
// NULL returned.
destroy_device_and_disk(lp_device, lp_disk)
ped_device_destroy(lp_device)
lp_device = NULL
return false
detect_filesystem(lp_device, lp_partition, ...)
path = lp_device->path
The key points are:
1. get_device() created a PedDevice object pointed to by lp_device;
2. get_disk() didn't find a libparted recognised disk label or file
system but also unexpectedly destroyed the PedDevice object and
assigned NULL to lp_device;
3. detect_filesystem() dereferenced lp_device assuming it was still
valid.
Implement the simplest possible fix by telling get_disk() to not
destroy the needed PedDevice object when there's no recognised content.
This is the same as how get_disk() is called in set_device_from_disk().
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
Even though blkid is considered mandatory [1] GParted should still
perform reasonably when blkid is not available, provided that is not too
onerous a task. Also use libparted file system identification inside
encryption mappings.
[1] 749a249571
Document blkid command as a mandatory requirement (#753436)
Closes 148 - Encrypted file systems are no longer recognised
GParted no longer recognises file systems inside LUKS encryption, apart
from the few recognised by GParted's internal detection. Bisected to
this commit:
8b35892ea5
Pass device and partition names to blkid (#131)
Prior to this commit blkid was run querying all known block devices
including active encryption mappings, hence prior recognition. With
this commit blkid was run only for named or found disk devices and
associated found partitions from /proc/partitions, so no more
recognition of encrypted file systems.
Fix by running blkid on the encryption mapping just before querying for
the file system. This restores the level of functionality that existed
before.
Closes 148 - Encrypted file systems are no longer recognised
To avoid making set_luks_partition() more complicated extract the file
system detection portion into a new function.
Closes 148 - Encrypted file systems are no longer recognised
Since changes for issue #131 "GParted hangs when non-named device is
hung" FS_Info cache is initialised, cleared and loaded via one call to
load_cache_for_paths(). It runs blkid for named or found disk devices
and associated found partitions from /proc/partitions, rather than
running blkid and letting it report for all block devices.
To avoid the possibility of using blkid on an encryption mapping on a
non-specified and possibly hung block device GParted can't just specify
all encryption mappings. Instead only encryption mappings which belong
to the above identified block devices should be probed. That requires
identifying LUKS encryption data in the block devices first so will
require subsequently loading additional data into the FS_Info cache and
running blkid again.
To accommodate this make the FS_Info cache incrementally loadable,
rather than doing everything in a single call to load_cache_for_paths().
Have a separate clear_cache() call which initialises and clears the
cache and make load_cache_for_paths() just run blkid and insert data for
the named paths.
Closes 148 - Encrypted file systems are no longer recognised
Reiser4 has introduced new disk format which includes support for
spanning the file system over multiple block devices (subvolumes)
[1][2]. As such the output of the debugfs.reiser4 for the UUID has
changed slightly. So far the new reiser4progs package (version 2.0.x)
is only available as a Debian experimental package.
Using reiser4progs 1.2.1 the old output was like this:
$ debugfs.reiser4 test.img
debugfs.reiser4 1.2.1
Format release: 4.0.2
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
Master super block (16):
magic: ReIsEr4
blksize: 4096
format: 0x0 (format40)
uuid: 1116afce-99fd-4a6e-94cb-2d9f19c91d67
label: <none>
...
With reiser4progs 2.0.4 the new output is like this:
$ debugfs.reiser4 test.img
debugfs.reiser4
Package Version: 2.0.4
Software Framework Release: 5.1.3
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
Master super block (16):
magic: ReIsEr4
blksize: 4096
volume: 0x1 (asym)
distrib: 0x1 (fsx32m)
format: 0x1 (format41)
description: Standard layout for logical volumes.
stripe bits: 14
mirror id: 0
replicas: 0
volume uuid: 9538bfa3-5694-4abe-864c-edc288a9d801
subvol uuid: d841c692-2042-49e6-ac55-57e454691782
label: <none>
...
GParted happens to read the correct UUID just because the first matching
"uuid" string in the output is the volume UUID. Make the code more
robust by explicitly reading the volume uuid when labelled as such.
[1] Logical Volumes Howto
https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Howto
[2] Logical Volumes Background
https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Background
Executables which are not intended for execution by users, but by other
programs, should be installed into /usr/libexec [1][2]. gpartedbin
falls into this category. Update it's installation accordingly.
Standard Autotools details: gpartedbin will be installed into
EPREFIX/libexec by default. To install gpartedbin into a different
directory set libexecdir when configuring the build system. Like this
from git:
./autogen.sh --libexecdir=DIR
or like this from tar release:
./configure --libexecdir=DIR
[1] Filesystem Hierarchy Standard, version 3.0,
4.7. /usr/libexec : Binaries run by other programs (optional)
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
"/usr/libexec includes internal binaries that are not intended to be
executed directly by users or shell scripts.
"
[2] GNU Coding Standards, June 12, 2020,
7.2.5 Variables for Installation Directories
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
"libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
/usr/local/libexec, but write it as $(exec_prefix)/libexec. (If you
are using Autoconf, write it as '@libexecdir@'.)
"
Closes#85 - Please install gpartedbin under /usr/libexec instead of
/usr/sbin
... in class Dialog_Partition_New and slightly refactor the code in
build_filesystems_combo() method which sets it.
Change the name from first_creatable_fs to default_fs to be more
immediately obvious what the variable represents. As default_fs is used
to index the items in the combo_filesystem derived ComboBox, make it's
type an int to match the type of the parameter passed to
Gtk::ComboBox::set_active() [1]. Initialise default_fs to -1 (no
selection) in the class constructor [2], which also allows removal of
local variable set_first just used to track whether first_creatable_fs
had been assigned yet or not.
[1] gtkmm: Gtk::ComboBox Class Reference, set_active()
https://developer.gnome.org/gtkmm/stable/classGtk_1_1ComboBox.html#a4f23cf08e85733d23f120935b235096d
[2] C++ FAQ / Should my constructors use "initialization lists" or
"assignment"?
https://isocpp.org/wiki/faq/ctors#init-lists
... in Dialog_Partition_New::build_filesystems_combo(). set_data()
populates this->FILESYSTEMS[] vector with supported file systems with
cleared, unformatted and extended added to the end. Then
build_filesystems_combo() adds those items to combo_filesystem, skipping
extended. It then makes the last item in the combobox sensitive,
relying on the fact that it is unformatted.
Refactor the code so build_filesystems_combo() no longer relies on
unformatted being the last item in combo_filesystem to always enable it.
... in Dialog_Partition_New::set_data(). As the change signal for
combo_filesystem has already been connected, combo_changed(false) is
automatically called by setting the active selection. Therefore remove
the unnecessary call.
"Type" was rather a generic name. Use "combo_type_changed" which makes
it clear that the boolean parameter indicates whether a change to
combo_type or one of the other ComboBoxes triggered this callback.
On an MSDOS partitioned drive, open the Create New Partition dialog and
change "created as" from Primary Partition to Extended Partition and
back to Primary Partition. On Fedora and RHEL/CentOS 8, which builds
packages with FORTIFY_SOURCE [1][2] and GLIBXX_Assertions [3][4]
enabled, GParted will crash.
Run GParted built with the default compilation options under valgrind
and repeat the test. Multiple out of bounds reads are reported like
this:
# valgrind --track-origins=yes ./gpartedbin
...
==232613== Invalid read of size 8
==232613== at 0x441AF6: GParted::Dialog_Partition_New::combobox_changed(bool) (Dialog_Partition_New.cc:354)
==232613== by 0x443DBD: sigc::bound_mem_functor1<void, GParted::Dialog_Partition_New, bool>::operator()(bool const&) const (mem_fun.h:2066)
Coming from Dialog_Partition_New.cc:
328 void Dialog_Partition_New::combobox_changed(bool type)
329 {
...
351 // combo_filesystem and combo_alignment
352 if ( ! type )
353 {
> 354 fs = FILESYSTEMS[combo_filesystem.get_active_row_number()];
When the partition type is changed to Extended the file system is forced
to be "Extended" too. This is done in ::combobox_changed() method by
modifying combo_filesystem to add "Extended", making that the selected
item and setting the widget as inactive.
Then when the partition type is changed back to primary the file system
combobox is returned to it's previous state. This is done by first
removing the last "Extended" item, making the widget active and setting
the selected item. However as "Extended" is the currently selected
item, removing it forces their to be no selected item and triggers a
change to combo_filesystem triggering a recursive call to
::combobox_changed() where combo_filesystem.get_active_row_number()
returns -1 (no selection) [5] and on line 354 the code accesses item -1
of the FILESYSTEMS[] vector.
Fix by setting the new combo_filesystem selection before removing the
currently selected "Extended" item. This has the added benefit of only
triggering a change to combo_filesystem once when the default item is
selected rather than twice when the currently "Extended" item is removed
and again when the default item is selected.
[1] [Fedora] Security Features, Compile Time Buffer Checks
(FORTIFY_SOURCE)
https://fedoraproject.org/wiki/Security_Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29
[2] Enhance application security with FORTIFY_SOURCE
https://access.redhat.com/blogs/766093/posts/1976213
[3] Security Features Matrix (GLIBXX_Assertions)
https://fedoraproject.org/wiki/Security_Features_Matrix
[4] GParted 1.2.0-1.fc33 package build.log for Fedora 33
https://kojipkgs.fedoraproject.org/packages/gparted/1.2.0/1.fc33/data/logs/x86_64/build.log
CXXFLAGS='-O2 -g ... -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS ...'
[5] gtkmm: Gtk::ComboBox Class Reference, get_active_row_number()
https://developer.gnome.org/gtkmm/stable/classGtk_1_1ComboBox.html#a53531bc041b5a460826babb8496c363bCloses#101 - Crash changing Partition type in "Create new partition"
dialog
On newer distributions the PipeCapture tests have been failing like
this:
$ ./test_PipeCapture
...
[ RUN ] PipeCaptureTest.ReadEmbeddedNULCharacter
test_PipeCapture.cc:336: Failure
Expected: inputstr
Of length: 6
To be equal to: capturedstr.raw()
Of length: 5
With first binary difference:
< 0x00000000 "ABC.EF" 41 42 43 00 45 46
--
> 0x00000000 "ABCEF" 41 42 43 45 46
[ FAILED ] PipeCaptureTest.ReadEmbeddedNULCharacter (0 ms)
[ RUN ] PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character
test_PipeCapture.cc:353: Failure
Expected: expectedstr
Of length: 7
To be equal to: capturedstr.raw()
Of length: 6
With first binary difference:
< 0x00000000 "._45678" 00 5F 34 35 36 37 38
--
> 0x00000000 "_45678" 5F 34 35 36 37 38
[ FAILED ] PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character (0 ms)
...
Found that test_PipeCapture succeeds on Fedora 31 and fails on
Fedora 32. Also test_PipeCapture binary from Fedora 31 and 32 both pass
on Fedora 31 and both fail on Fedora 32. So something outside of the
GParted code and tests is the cause.
Confirmed that this GLib change "Add a missing check to
g_utf8_get_char_validated()" [1], first released in GLib 2.63.0, made
the difference. On Fedora 32 with GLib 2.64.6, rebuilt GLib with that
change reverted and the tests passed. Anyway fix the wrapper GParted
has around g_utf8_get_char_validated() to also handle this case of
reading a NUL character.
[1] 568720006c
Add a missing check to g_utf8_get_char_validated()
Closes#136 - 1.2.0: test suite is failing in test_PipeCapture
Extract call to GLib's g_utf8_get_char_validated() and the associated
workaround to also read NUL characters into a separate function to make
PipeCapture::OnReadable() a little smaller and simpler, so easier to
understand.
Add max_len > 0 clause into get_utf8_char_validated() like this:
if (uc == UTF8_PARTIAL && max_len > 0)
so that the NUL character reading workaround is only applied when
max_len specifies the maximum number of bytes to read, rather than
when -1 specifies reading a NUL termination string. This makes
get_utf8_char_validated() a complete wrapper of
g_utf8_get_char_validated() [1], even though GParted always specifies
the maximum number of bytes to read.
No longer describe the inability to read NUL characters as a bug [2]
since the GLib author's said it wasn't [3].
[1] GLib Reference Manual, Unicode Manipulation Functions,
g_utf8_get_char_validated ()
https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-get-char-validated
[2] 8dbbb47ce2
Workaround g_utf8_get_char_validate() bug with embedded NUL bytes
(#777973)
[3] Bug 780095 - g_utf8_get_char_validated() stopping at nul byte even
for length specified buffers
https://bugzilla.gnome.org/show_bug.cgi?id=780095#18
"If g_utf8_get_char_validated() encounters a nul byte in the
middle of a string of given longer length, it returns -2,
indicating a partial gunichar. That is not the obvious
behaviour, but since g_utf8_get_char_validated() has been API
for a long time, the behaviour cannot be changed.
"
Closes#136 - 1.2.0: test suite is failing in test_PipeCapture
This previous commit [1] suggested that in future partition deletion
might be allowed even while a LUKS mapping was active in that partition.
To allow deletion of a partition while it has active content is wrong.
That is a significant reason GParted has busy detection of otherwise
unrecognised file systems [2] and recognition and busy detection of, but
otherwise not controllable support for, Linux Software RAID [3] and
ATARAID [4][5] arrays.
To automatically close the LUKS partition first would be against the
pattern of behaviour that GParted has established, of requiring explicit
deactivation of file systems, swap and volume groups before allowing
deletion. Therefore update the comment accordingly.
[1] f1e3d42b56
Prevent deletion of open LUKS mappings (#774818)
[2] 49a2e19462
Restore busy detection of unknown mounted file systems (#723842)
[3] d2e1130ad2
Detect busy status of Linux Software RAID members (#709640)
[4] 6e990ea48a
Detect busy status of mdadm started ATARAID members (#75)
[5] caec22871e
Detect busy status of dmraid started ATARAID members (#75)
Also with exfatprogs 1.1.0 [1], tune.exfat and exfatlabel gained the
capability to report and set the exFAT Volume Serial Number [2][3][4].
This is what blkid and therefore GParted reports as the UUID.
Report serial number:
# tune.exfat -i /dev/sdb1
exfatprogs version : 1.1.0
volume serial : 0x772ffe5d
# echo $?
0
# blkid /dev/sdb1
/dev/sdb1: LABEL="test exfat" UUID="772F-FE5D" TYPE="exfat" PTTYPE="dos"
Set serial number:
# tune.exfat -I 0xf96ef190 /dev/sdb1
exfatprogs version : 1.1.0
New volume serial : 0xf96ef190
# echo $?
0
tune.exfat exists in earlier releases of exfatprogs so check it has the
capability by searching for "Set volume serial" in the help output
before enabling this capability.
# tune.exfat
exfatprogs version : 1.1.0
Usage: tune.exfat
-l | --print-label Print volume label
-L | --set-label=label Set volume label
-i | --print-serial Print volume serial
-L | --set-serial=value Set volume serial
-V | --version Show version
-v | --verbose Print debug
-h | --help Show help
(Note the cut and paste error reporting the set volume serial flag as
'-L' rather than actually '-S').
[1] exfatprogs-1.1.0 version released
http://github.com/exfaoprogs/exfatprogs/releases/tag/1.1.0
[2] [tools][feature request] Allow To Change Volume Serial Number ("ID")
#138https://github.com/exfatprogs/exfatprogs/issues/138
[3] exfatlabel:add get/set volume serial option
b4d9c9eeb5
[4] exFAT file system specification, 3.1.11 VolumeSerialNumber Field
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification#3111-volumeserialnumber-fieldCloses!67 - Add support for reading exFAT usage and updating the UUID
exfatprogs 1.1.0 released 2021-02-09 [1] has gained support for
reporting file system usage [2][3] so add that capability to GParted.
It works like this:
# dump.exfat /dev/sdb1 | egrep 'Volume Length\(sectors\):|Sector Size Bits:|Sector per Cluster bits:|Free Clusters:'
Volume Length(sectors): 524288
Sector Size Bits: 9
Sector per Cluster bits: 3
Free Clusters: 23585
Unfortunately dump.exfat returns a non-zero status on success so that
can't be used to check for failure:
# dump.exfat /dev/sdb1
exfatprogs version : 1.1.0
-------------- Dump Boot sector region --------------
Volume Length(sectors): 524288
...
# echo $?
192
dump.exfat only writes errors to stderr, so use this to identify failure:
# dump.exfat /dev/sdb1 1> /dev/null
# echo $?
192
# dump.exfat /dev/zero 1> /dev/null
invalid block device size(/dev/zero)
bogus sector size bits : 0
# echo $?
234
[1] exfatprogs-1.1.0 version released
http://github.com/exfaoprogs/exfatprogs/releases/tag/1.1.0
[2] [feature request] File system usage reporting
https://github.com/exfatprogs/exfatprogs/issues/139
[3] exfatprogs: add dump.exfat
7ce9b2336bCloses!67 - Add support for reading exFAT usage and updating the UUID
A user had exfat-utils installed and tried to use GParted to create an
exfat file system. GParted ran this command but it failed:
# mkfs.exfat -L '' '/dev/sdb1'
mkexfatfs 1.3.0
mkfs.exfat: invalid option -- 'L'
Usage: mkfs.exfat [-i volume-id] [-n label] [-p partition-first-sector] [-s sectors-per-cluster] [-V] <device>
The problem is that both exfat-utils and exfatprogs packages provide
mkfs.exfat and fsck.exfat commands but they have incompatible command
line options and GParted is programmed for exfatprogs. So far GParted
just checks the executable exists, hence the mis-identification.
Reported version of exfat-utils commands:
$ mkfs.exfat -V 2> /dev/null
mkexfatfs 1.3.0
Copyright (C) 2011-2018 Andrew Nayenko
$ fsck.exfat -V 2> /dev/null
exfatfsck 1.3.0
Copyright (C) 2011-2018 Andrew Nayenko
Reported versions of exfatprogs commands:
$ mkfs.exfat -V 2> /dev/null
exfatprogs version : 1.0.4
$ fsck.exfat -V 2> /dev/null
exfatprogs version : 1.0.4
Fix this by only enabling exfat support also when the version string of
each command starts "exfatprogs version". Note that this extra checking
is not needed for tune.exfat because only exfatprogs provides that
executable.
Closes#137 - Creating exfat partition with a label fails with error
This method is now only called from one location in the code so put it's
two lines of code there.
Closes#131 - GParted hangs when non-named device is hung
Now we always want to run blkid naming all paths, ensure the FS_Info
cache is explicitly loaded first. Report an error if not done so and
remove the cache loading code from running blkid without naming all
paths. Fewer code paths to consider and reason about.
Closes#131 - GParted hangs when non-named device is hung
Again on Fedora 31 with a slightly different disk layout to the previous
commit. sdb is partitioned with 1 empty partition and sdc remains
completely empty:
# lsblk -o name,maj:min,rm,size,ro,type,fstype,label,mountpoint
NAME MAJ:MIN RM SIZE RO TYPE FSTYPE LABEL MOUNTPOINT
sda 8:0 0 20G 0 disk
|-sda1 8:1 0 1G 0 part ext4 /boot
\-sda2 8:2 0 19G 0 part LVM2_member
|-fedora-root 253:0 0 17G 0 lvm ext4 /
\-fedora-swap 253:1 0 2G 0 lvm swap [SWAP]
sdb 8:16 0 8G 0 disk
\-sdb1 8:17 0 1G 0 part
sdc 8:32 0 8G 0 disk
sr0 11:0 1 1024M 0 rom
# blkid -v
blkid from util-linux 2.34 (libblkid 2.34.0, 14-Jun-2019)
# blkid /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 /dev/sdc
/dev/sda: PTUUID="5012fb1f" PTTYPE="dos"
/dev/sda1: UUID="3cd48816-7817-4636-9fec-5f1afe76c1b2" TYPE="ext4" PARTUUID="5012fb1f-01"
/dev/sda2: UUID="PH94ej-C8xU-bnMJ-UIh8-ZimI-4B7f-dHlZxh" TYPE="LVM2_member" PARTUUID="5012fb1f-02"
/dev/sdb: PTUUID="1d120b57" PTTYPE="dos"
/dev/sdb1: PARTUUID="1d120b57-01"
Stracing GParted shows these executions of blkid:
# strace -f -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | egrep -v 'ENOENT|SIGCHLD'
...
[pid 160040] execve("/usr/sbin/blkid", ["blkid", "/dev/sda", "/dev/sda1", "/dev/sda2", "/dev/sdb", "/dev/sdb1", "/dev/sdc"], 0xa4e1b0 /* 32 vars */ <detached ...>
[pid 160041] execve("/usr/sbin/blkid", ["blkid", "/dev/sdc"], 0xa4e1b0 /* 32 vars */ <detached ...>
...
On Fedora 31 with blkid from util-linux 2.34 it reports information for
sdb (partitioned drive) and sdb1 (empty partition) with only no
information for sdc (empty whole disk drive). Hence no FS_Info cache
entry and re-execution of blkid just for sdc.
On older CentOS 7 with the same disk layout blkid reports this:
# blkid -v
blkid from util-linux 2.23.2 (libblkid 2.23.0, 25-Apr-2013)
# blkid /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 /dev/sdc
/dev/sda: PTTYPE="dos"
/dev/sda1: UUID="e7d559e4-3e1d-4fbc-b034-3fdeb498f44d" TYPE="xfs"
/dev/sda2: UUID="B7ODFx-BfTE-hq7N-UlrF-f5ML-CPRe-klSy26" TYPE="LVM2_member"
/dev/sdb: PTTYPE="dos"
And stracing GParted shows these executions of blkid:
# strace -f -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | egrep -v 'ENOENT|SIGCHLD'
...
[pid 1889] execve("/sbin/blkid", ["blkid", "/dev/sda", "/dev/sda1", "/dev/sda2", "/dev/sdb", "/dev/sdb1", "/dev/sdc"], 0x10b8b10 /* 26 vars */ <detached ...>
[pid 1890] execve("/sbin/blkid", ["blkid", "/dev/sdb1"], 0x10b8b10 /* 26 vars */ <detached ...>
[pid 1891] execve("/sbin/blkid", ["blkid", "/dev/sdc"], 0x10b8b10 /* 26 vars */ <detached ...>
...
This time on CentOS 7 with blkid from util-linux 2.23.2 it reports
information for only sdb (partitioned drive), but not sdb1 (empty
partition) or sdc (empty whole disk drive). Hence no FS_info cache
entries and re-execution of blkid for both sdb1 and sdc.
GParted needs blkid identification of file system images, LVM Logical
Volumes or any other partitions named on the command line which it
wouldn't normally scan [1]. Now every name of interest is passed to
blkid, additional executions of blkid won't get any extra information
and are redundant. Therefore remove this unnecessary code.
Note that these last 2 commits remove creation of "blank" cache entries
(just block special with blank fstype and other attributes) when blkid
reports no information for a particular path. Those entry were needed
to suppress unnecessary additional execution of blkid. However now that
blkid is only executed once (excluding querying the label) this is no
longer necessary. All the getter functions return suitable blank values
when no cache entry is found.
[1] e8f0504b13
Make sure that FS_Info cache is loaded for all named paths (#787181)
Closes#131 - GParted hangs when non-named device is hung
On Fedora 31 with this simple disk layout where both sdb and sdc are
completely empty:
# lsblk -o name,maj:min,rm,size,ro,type,fstype,label,mountpoint
NAME MAJ:MIN RM SIZE RO TYPE FSTYPE LABEL MOUNTPOINT
sda 8:0 0 20G 0 disk
|-sda1 8:1 0 1G 0 part ext4 /boot
\-sda2 8:2 0 19G 0 part LVM2_member
|-fedora-root 253:0 0 17G 0 lvm ext4 /
\-fedora-swap 253:1 0 2G 0 lvm swap [SWAP]
sdb 8:16 0 8G 0 disk
sdc 8:32 0 8G 0 disk
sr0 11:0 1 1024M 0 rom
# blkid /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdc
/dev/sda: PTUUID="5012fb1f" PTTYPE="dos"
/dev/sda1: UUID="3cd48816-7817-4636-9fec-5f1afe76c1b2" TYPE="ext4" PARTUUID="5012fb1f-01"
/dev/sda2: UUID="PH94ej-C8xU-bnMJ-UIh8-ZimI-4B7f-dHlZxh" TYPE="LVM2_member" PARTUUID="5012fb1f-02"
Stracing GParted shows extra executions of blkid:
# strace -f -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | egrep -v 'ENOENT|SIGCHLD'
...
[pid 7659] execve("/usr/sbin/blkid", ["blkid", "/dev/sda", "/dev/sda1", "/dev/sda2", "/dev/sdb", "/dev/sdc"], 0x1d300f0 /* 32 vars */ <detached ...>
[pid 7660] execve("/usr/sbin/blkid", ["blkid", "/dev/sdb"], 0x1d300f0 /* 32 vars */ <detached ...>
[pid 7661] execve("/usr/sbin/blkid", ["blkid", "/dev/sdc"], 0x1d300f0 /* 32 vars */ <detached ...>
...
blkid is only run again for sdb and sdc, not sda, because blkid didn't
report anything for them from the first execution. GParted needs blkid
identification of whole disk devices to ensure that ISO9660 images on
whole disk devices are correctly identified [1]. Now the first run of
blkid passes all the device names, so this additional execution of blkid
won't get any extra information and is redundant. Therefore remove this
unnecessary code.
[1] b2190372d0
Ensure blkid FS_Info cache has entries for all whole disk devices
(#771244)
Closes#131 - GParted hangs when non-named device is hung
A user reported that GParted would hang at "scanning all devices...",
when a fully working disk was named on the command line, but another
device on the machine was hung.
This can be replicated like this:
(on Ubuntu 20.04 LTS for it's NBD support)
1. Export and import NBD:
# truncate -s 1G /tmp/disk-1G.img
# nbd-server -C /dev/null 9000 /tmp/disk-1G.img
# nbd-client localhost 9000 /dev/nbd0
2. Hang the NBD server and therefore /dev/nbd0:
# killall -STOP nbd-server
3. Run GParted:
$ gparted /dev/sda
Tracing GParted shows that execution of blkid never returns.
# strace -f -tt -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | fgrep -v ENOENT
...
[pid 37823] 13:56:24.814139 execve("/usr/sbin/mkudffs", ["mkudffs", "--help"], 0x55e2a3f2d230 /* 20 vars */ <detached ...>
[pid 37814] 13:56:24.829246 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37823, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
[pid 37825] 13:56:25.376796 execve("/usr/sbin/blkid", ["blkid", "-v"], 0x55e2a3f2d230 /* 20 vars */ <detached ...>
[pid 37824] 13:56:25.380824 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37825, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid 37826] 13:56:25.402512 execve("/usr/sbin/blkid", ["blkid"], 0x55e2a3f2d230 /* 20 vars */ <detached ...>
Tracking of blkid shows that it hangs on either the open of or first
read from /dev/nbd0.
# strace blkid
...
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0
lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0
lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
access("/dev/nbd0", F_OK) = 0
stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
openat(AT_FDCWD, "/sys/dev/block/43:0", O_RDONLY|O_CLOEXEC) = 4
openat(4, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
close(4) = 0
openat(AT_FDCWD, "/dev/nbd0", O_RDONLY|O_CLOEXEC
Clean up:
1. Resume NBD server:
# killall -CONT nbd-server
2. Delete NBD setup:
# nbd-client -d /dev/nbd0
# killall nbd-server
# rm /tmp/disk-1G.img
Fix this by making GParted specify the whole disk device and partition
names that it is interested in to blkid, rather than letting blkid scan
and report all block devices. Do this both when GParted determines the
devices for itself and when they are named on the command line.
Also update example blkid command output being parsed and cache value
with this change to how blkid is executed.
Closes#131 - GParted hangs when non-named device is hung
GParted already always reads /proc/partitions for whole disk device
names no matter whether it uses whole disk devices named on the command
line, from /proc/partitions or from libparted. As /proc/partitions
lists all the block devices that the kernel knows about, and therefore
all the possible ones blkid could probe, so use it to provide partition
names and device to partition mapping. See code comments for more
details about the assumptions the /proc/partition parsing code makes and
the fact that these are confirmed by examining the Linux kernel source.
This commit just adds debugging to print the existing vector of
validated devices GParted shows in the UI and the vector with all
partitions added, ready for but not yet passed to blkid.
# ./gpartedbin
...
DEBUG: device_paths=["/dev/sda","/dev/sdb"]
DEBUG: device_and_partition_paths=["/dev/sda","/dev/sda1","/dev/sda2","/dev/sdb","/dev/sdb1"]
Also demonstrating that this continues to support named devices,
including file system image files [1].
# truncate -s 256M /tmp/ext4.img
# mkfs.ext4 /tmp/ext4.img
# ./gpartedbin /dev/sda /tmp/ext4.img
...
DEBUG: device_paths=["/dev/sda","/tmp/ext4.img"]
DEBUG: device_and_partition_paths=["/dev/sda","/dev/sda1","/dev/sda2","/tmp/ext4.img"]
[1] e8f0504b13
Make sure that FS_Info cache is loaded for all named paths (#787181)
Closes#131 - GParted hangs when non-named device is hung
Put whole disk device name matching code into a helper function to make
the /proc/partition parsing code easier to understand.
Closes#131 - GParted hangs when non-named device is hung
Now FS_Info::load_cache() and ::load_cache_for_paths() are nearly next
to each other, merge them together to simplify the code a little. This
makes the special case to ensure that file system images named on the
command line were queried by blkid and loaded into the FS_Info cache [1]
become the normal cache loading method. Already passing all discovered
or named devices to load_cache_for_paths() is also a step on the way to
doing it for all devices and partitions of interest.
Just need to ensure that load_cache_for_paths() always loads the cache
as load_cache() did, rather than only when it hadn't already been
loaded. Otherwise GParted will only ever run blkid and load the cache
once at startup and not on each refresh.
[1] e8f0504b13
Make sure that FS_Info cache is loaded for all named paths (#787181)
Closes#131 - GParted hangs when non-named device is hung
PATCHSET OVERVIEW
A user reported that GParted would hang at "scanning all devices...",
when a fully working disk was named on the command line, but another
device on the machine was hung.
This can be replicated like this:
(on Ubuntu 20.04 LTS for it's NBD support)
1. Export and import NBD:
# truncate -s 1G /tmp/disk-1G.img
# nbd-server -C /dev/null 9000 /tmp/disk-1G.img
# nbd-client localhost 9000 /dev/nbd0
2. Hang the NBD server and therefore /dev/nbd0:
# killall -STOP nbd-server
3. Run GParted:
$ gparted /dev/sda
Tracing GParted shows that execution of blkid never returns.
# strace -f -tt -q -bexecve -eexecve /usr/sbin/gpartedbin 2>&1 1> /dev/null | fgrep -v ENOENT
...
[pid 37823] 13:56:24.814139 execve("/usr/sbin/mkudffs", ["mkudffs", "--help"], 0x55e2a3f2d230 /* 20 vars */ <detached ...>
[pid 37814] 13:56:24.829246 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37823, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
[pid 37825] 13:56:25.376796 execve("/usr/sbin/blkid", ["blkid", "-v"], 0x55e2a3f2d230 /* 20 vars */ <detached ...>
[pid 37824] 13:56:25.380824 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37825, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid 37826] 13:56:25.402512 execve("/usr/sbin/blkid", ["blkid"], 0x55e2a3f2d230 /* 20 vars */ <detached ...>
Tracing of blkid shows that it hangs on either the open of or first
read from /dev/nbd0.
# strace blkid
...
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0
lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0
lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
access("/dev/nbd0", F_OK) = 0
stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0
openat(AT_FDCWD, "/sys/dev/block/43:0", O_RDONLY|O_CLOEXEC) = 4
openat(4, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
close(4) = 0
openat(AT_FDCWD, "/dev/nbd0", O_RDONLY|O_CLOEXEC
Clean up:
1. Resume NBD server:
# killall -CONT nbd-server
2. Delete NBD setup:
# nbd-client -d /dev/nbd0
# killall nbd-server
# rm /tmp/disk-1G.img
Going to fix this by making GParted specify the device and partition
names that it is interested in to blkid, rather than letting blkid scan
and report all block devices. Do this both when GParted determines the
devices for itself and when they are named on the command line.
THIS PATCH
Move the loading and initialising of caches used during content
discovery to after device and partition discovery and just before
content discovery. Just makes the code ready for the next change.
Closes#131 - GParted hangs when non-named device is hung
Libparted only allows selection of the partition type indirectly by
specifying the type of the file system it will contain [1] and so far
doesn't know about the exFAT file system. Therefore when GParted is
creating a new exFAT partition, it gets the GParted default of 83
(Linux file system) on MBR partition tables.
Example operation details:
Create Primary Partition #1 (exfat, 512.00 MiB) on /dev/sdb
* create empty partition
* clear old file system signatures in /dev/sdb1
* set partition type on /dev/sdb1
new partition type: ext2
* create new exfat file system
fdisk report:
# fdisk -l /dev/sdb
Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa2aab629
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1050623 1048576 512M 83 Linux
However the "exFAT file system specification" says:
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
"10.2 Partition Tables
To ensure interoperability of exFAT volumes in a broad set of usage
scenarios, implementations should use partition type 07h for MBR
partitioned storage and partition GUID
{EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} for GPT partitioned storage.
"
Fix this.
[1] ped_partition_new(..., const PedFileSystemType* fs_type, ...)
https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5
ped_partition_set_system(..., const PedFileSystemType* fs_type)
https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5Closes!30 - Add exFAT support
With exfatprogs (https://github.com/exfatprogs/exfatprogs) installed the
following operations on exFAT file systems are supported:
- Creation
- Checking
- Labelling
As of the current exfatprogs 1.0.4 the following are not supported:
- Reading usage
- Resizing
- Updating the UUID
Closes!30 - Add exFAT support
To better reflect that they represent the version of mke2fs executable
from the e2fsprogs package, even though the executable is called as
mkfs.ext4.
$ ls -il /sbin/mke2fs /sbin/mkfs.ext*
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mke2fs
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext2
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext3
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext4
$ mkfs.ext4 -V
mke2fs 1.42.9 (28-Dec-2013)
Using EXT2FS Library version 1.42.9
$ mke2fs -V
mke2fs 1.42.9 (28-Dec-2013)
Using EXT2FS Library version 1.42.9
With removal of support for RHEL / CentOS 5 and it's e4fsprogs package
[1][2] it is no longer necessary to accept:
mke4fs 1.41.12 (17-May-2010)
only:
mke2fs 1.42.9 (28-Dec-2013)
[1] 6c4ab5dc28
Remove checks for e4fsprogs commands (#794253)
[2] de6e70d933
Simplify ext2::get_filesystem_support() with regard ext4 support (#794253)
This earlier commit [1] from 2013 recognised the new names for programs
in dosfstools >= 3.0.18, specifically mkfs.fat and fsck.fat. Now that
the oldest supported distributions use dosfstools >= 3.0.18 it is no
longer necessary to support using the old names of mkdosfs and dosfsck,
so remove that code.
Oldest supported Dosfstools
distributions Version
Debian 8 3.0.27
RHEL / CentOS 7 3.0.20
SLES 12 3.0.26
Ubuntu 14.04 LTS 3.0.26
[1] 1ae03dee95
Recognise new dosfstools program names (#704629)
Closes!57 - Raise minimum support dosfstools to 3.0.18 released
2013-06-06
A user reported that formatting a whole disk device with a file system
failed like this:
Format /dev/sdd as ext4 (ERROR)
+ calibrate /dev/sdd (SUCCESS)
path: /dev/sdd (device)
start: 0
end: 15633407
size: 15633408 (7.45 GiB)
+ clear old file system signatures in /dev/sdd (SUCCESS)
+ write 512.00 KiB of zeros at byte offset 0 (SUCCESS)
+ write 4.00 KiB of zeros at byte offset 67108864 (SUCCESS)
+ write 512.00 KiB of zeros at byte offset 8003780608 (SUCCESS)
+ write 4.00 KiB of zeros at byte offset 8004239360 (SUCCESS)
+ write 8.00 KiB of zeros at byte offset 8004296704 (SUCCESS)
+ flush operating system cache of /dev/sdd (SUCCESS)
+ create new ext4 file system (ERROR)
+ mkfs.ext4 -F -O ^64bit -L '' '/dev/sdd' (ERROR)
mke2fs 1.44.1 (24-Mar-2018)
/dev/sdd is apparently in use by the system; will not make a filesystem here!
Opening the whole disk block device exclusively causes mkfs.ext4 to
report that error like this:
# python
>>> import os
>>> f = os.open('/dev/sdb',os.O_RDONLY|os.O_EXCL)
>>> ^Z
[1]+ Stopped python
# mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb'
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdb is apparently in use by the system; will not make a filesystem here!
# echo $?
1
I have not been able to reproduce this error, but with debugging and
sleeping in GParted, stracing GParted and using 'udevadm monitor' to
watch udev events the following sequence of events is seen:
gparted |format(partition, operationdetail)
gparted | erase_filesystem_signatures(partition, operationdetail)
gparted | get_device(device_path="/dev/sdb", lp_device, flush=false)
gparted | ped_device_get("/dev/sdb")
libparted | open("/dev/sdb", O_RDONLY) = 11
libparted | close(11)
gparted | ped_device_open(lp_device)
libparted | open("/dev/sdb", O_RDWR) = 11
gparted | ped_device_sync(lp_device)
libparted | ioctl(11, BLKFLSBUF)
gparted | ped_device_close()
libparted | close(11)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
gparted | set_partition_type(partition, operationdetail)
gparted | create_filesystem(partition, operationdetail)
gparted | ext2::create(partition, operationdetail)
gparted | FileSystem::execute_command("mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb')
So it is assumed that the processing of the udev change rule after
closing the block device in erase_filesystem_signatures() overlaps with
the execution mkfs.ext4 and causes the seen error. Fix by waiting for
those udev events to complete as was previously done by commits [1][2]
[3].
Also note that this is specific to creating file systems on and
formatting unpartitioned whole disk devices because set_partition_type()
is a no-operation. Where as on a partitioned device
set_partition_type() calls commit() which already waits for udev rules
to complete [3].
[1] 50c8924a8e4d9cc96a2ea45f13291114402affee
Wait for udev to recreate /dev/PTN entries when querying partition
FSs (!46)
[2] 4f6c312e3bc68cafb5e6035fd4a5b5bbbfcea992
Wait for udev change on /dev/DISK when querying whole device FS
(!46)
[3] 2f53876c0f
Wait for the kernel and udev to settle partitions for a second time
(#790418)
Closes#83 - /dev/sdd is apparently in use by the system; will not make
a filesystem here!
Name the structure member to 'fsname' used to store strings like "ext2"
etc. This is equivalent to what was previously done in this commit:
a9f08ddc7d
Rename local variable to fsname in get_filesystem() (#741430)
Closes!52 - Rename members and variables currently named 'filesystem'
Previously made this change:
175d27c55d
Rename enum FILESYSTEM to FSType
Now complete the renaming exercise of members and variables currently
named 'filesystem'.
Closes!52 - Rename members and variables currently named 'filesystem'
In GParted_Core::set_device_partitions() the partition path is being
queried from libparted. However this is done before the switch
statement on the type of the partition, so is called for all libparted
partition objects including PED_PARTITION_FREESPACE and
PED_PARTITION_METADATA ones. As libparted numbers these partition
objects as -1, it returns paths like "/dev/sda-1".
Additionally when using GParted, with it's default DMRaid handling, on a
dmraid started array this results in paths like
"/dev/mapper/isw_ecccdhhiga_MyArray-1" being passed to
is_dmraid_device() and make_path_dmraid_compatible(). Fortunately
make_path_dmraid_compatible() does nothing and returns the same name.
Call chain looks like:
GParted_Core::set_device_partitions()
get_partition_path(lp_partition)
// where:
// lp_partition->disk->dev->path = "/dev/mapper/isw_ecccdhhiga_MyArray"
// lp_partition->type == PED_PARTITION_FREESPACE |
// PED_PARTITION_METADATA
// ->num == -1
ped_partition_get_path(lp_partition)
return "/dev/mapper/isw_ecccdhhiga_MyArray-1"
dmraid.is_dmraid_supported()
dmraid.is_dmraid_device("/dev/mapper/isw_ecccdhhiga_MyArray-1")
return true
dmraid.make_path_dmraid_compatible("/dev/mapper/isw_ecccdhhiga_MyArray-1")
return "/dev/mapper/isw_ecccdhhiga_MyArray-1"
Fix by moving the get_partition_path() call inside the switch statement
so that it is only called for PED_PARTITION_NORMAL,
PED_PARTITION_LOGICAL and PED_PARTITION_EXTENDED partition types.
Relevant commits:
* 53c49349f7
Simplify logic in set_device_partitions method
* 81986c0990
Ensure partition path name is compatible with dmraid (#622217)
This is not strictly necessary as members are already recognised using
blkid since this commit earlier in the sequence "Recognise ATARAID
members (#75)". However it makes sure active members are recognised
even if blkid is not available and matches how file system detection
queries the SWRaid_Info module.
Closes#75 - Errors with GPT on RAID 0 ATARAID array
This matches how the array device is displayed as the mount point for
mdadm started ATARAID members by "Display array device as mount point of
mdadm started ATARAID members (#75)" earlier in this patchset.
Extend the DMRaid module member cache to save the array device name and
use as needed to display as the mount point.
Closes#75 - Errors with GPT on RAID 0 ATARAID array
Again this is to stop GParted allowing overwrite operations being
performed on an ATARAID member while the array is actively using the
member. This time for dmraid started arrays using the kernel DM (Device
Mapper) driver.
The DMRaid module already uses dmraid to report active array names:
# dmraid -sa -c
isw_ecccdhhiga_MyArray
To find active members in this array, (1) use udev to lookup the kernel
device name:
# udevadm info --query=name /dev/mapper/isw_ecccdhhiga_MyArray
dm-0
(2) list the member names exposed by the kernel DM driver through the
/sys file system.
# ls /sys/block/dm-0/slaves
sdc sdd
# ls -l /sys/block/dm-0/slaves
lrwxrwxrwx 1 root root 0 Nov 24 09:52 sdc -> ../../../../pci0000:00/0000:00:0d.0/ata3/host2/target2:0:0/2:0:0:0/block/sdc
lrwxrwxrwx 1 root root 0 Nov 24 09:52 sdc -> ../../../../pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdd
Closes#75 - Errors with GPT on RAID 0 ATARAID array
When an ATARAID member is inactive allow basic supported actions of
copy and move to be performed like with other recognised but only basic
supported types.
Closes#75 - Errors with GPT on RAID 0 ATARAID array
Since earlier commit "Display array device as mount point of mdadm
started ATARAID members (#75)" GParted allows attempting to unmout a
busy ATARAID member as if it was a file system. This is not a valid
thing to do, so disallow it.
Closes#75 - Errors with GPT on RAID 0 ATARAID array
This matches how other non-file systems are handled, by displaying the
access reference in the mount point column. For LVM Physical Volumes
the Volume Group name is displayed [1] and for an active Linux Software
RAID array the array device is displayed [2].
[1] 8083f11d84
Display LVM2 VGNAME as the PV's mount point (#160787)
[2] f6c2f00df7
Populate member mount point with SWRaid array device (#756829)
Closes#75 - Errors with GPT on RAID 0 ATARAID array
This stops GParted allowing overwrite operations (such as create
partition table or format with a whole device file system) being
performed on an ATARAID member while the array is actively using the
member.
Closes#75 - Errors with GPT on RAID 0 ATARAID array
The previous commit, made mdadm recognised IMSM and DDF type ATARAID
members get displayed as "linux-raid" (Linux Software RAID array
member). This was because of query method 1 in detect_filesystems().
Fix this now by exposing and using the fstype of the member from the
SWRaid_Info cache.
Closes#75 - Errors with GPT on RAID 0 ATARAID array
Since mdadm release 3.0 (2009-06-02) [1] it has also supported external
metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously
only managed by dmraid.
A number of distributions have switched to use mdadm and kernel MD
(Multiple Devices) driver for managing these Firmware / BIOS / ATARAID
arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3],
SLES >= 12 [4], Ubuntu >= 16.04 LTS.
Therefore additionally parse members in these ATARAID arrays included in
mdadm output, and when activated using the kernel MD driver, in file
/proc/mdstat. Add fstype to the SWRaid_Info cache records to
distinguish members apart. So far the rest of the GParted code
continues to treat all members as FS_LINUX_SWRAID. This will be
resolved in following commits.
Note that this in no way affects how GParted shows and partitions the
array device itself, even those managed by dmraid and use the GParted
DMRaid module. It only affects how GParted shows the member drives
themselves.
[1] mdadm ANNOUNCE-3.0 file
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0
[2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem
https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html
"... Fedora 14 uses mdraid with external metadata to access ISW /
IMSM (Intel firmware RAID) sets. mdraid sets are configured and
controlled through the mdadm utility."
[3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys
"mdraid also supports other metadata formats, known as external
metadata. Red Hat Enterprise Linux 6 uses mdraid with external
metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid
sets are configured and controlled through the mdadm utility."
[4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM
and DDF
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007
"For IMSM and DDF RAIDs the mdadm driver is used unconditionally."
Closes#75 - Errors with GPT on RAID 0 ATARAID array
PATCHSET OVERVIEW
A user had a Firmware / BIOS / ATARAID array of 2 devices configured as
a RAID 0 (stripe) set. On top of that was a GPT with the OS partitions.
GParted displays the following errors on initial load and subsequent
refresh:
Libparted Error
(-) Invalid argument during seek for read on /dev/sda
[ Retry ] [ Cancel ] [ Ignore ]
Libparted Error
(-) The backup GPT table is corrupt, but the
primary appears OK, so that will be used.
[ Ok ] [ Cancel ]
This is an Intel Software RAID array which stores metadata at the end of
each member device, and so the first 128 KiB stripe of the set is stored
in the first 128 KiB of the first member device /dev/sda which includes
the GPT for the whole RAID 0 device. Hence when libparted reads member
device /dev/sda it finds a GPT describing a block device twice it's
size and in results the above errors when trying to read the backup GPT.
A more dangerous scenario occurs when using 2 devices configured in an
Intel Software RAID 1 (mirrored) set with GPT on top. On refresh
GParted display this error for both members, /dev/sda and /dev/sdb:
Libparted Warning
/!\ Not all of the space available to /dev/sda appears to be used,
you can fix the GPT to use all of the space (an extra 9554
blocks) or continue with the current setting?
[ Fix ] [ Ignore ]
Selecting [Fix] gets libparted to re-write the backup GPT to the end of
the member device, overwriting the ISW metadata! Do that twice and both
copies of the metadata are gone!
Worked example of this more dangerous mirrored set case. Initial setup:
# dmraid -s
*** Group superset isw_caffbiaegi
--> Subset
name : isw_caffbiaegi_MyMirror
size : 16768000
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
# dmraid -r
/dev/sda: isw, "isw_caffbiaegi", GROUP, ok, 16777214 sectors, data@ 0
/dev/sdb: isw, "isw_caffbiaegi", GROUP, ok, 16777214 sectors, data@ 0
# wipefs /dev/sda
offset type
---------------------------------------------
0x200 gpt [partition table]
0x1fffffc00 isw_raid_member [raid]
Run GParted and click [Fix] on /dev/sda. Now the first member has gone:
# dmraid -s
*** Group superset isw_caffbiaegi
--> *Inconsistent* Subset
name : isw_caffbiaegi_MyMirror
size : 16768000
stride : 128
type : mirror
status : inconsistent
subsets: 0
devs : 1
spares : 0
# dmraid -r
/dev/sdb: isw, "isw_caffbiaegi", GROUP, ok, 16777214 sectors, data@ 0
# wipefs /dev/sda
offset type
---------------------------------------------
0x200 gpt [partition table]
Click [Fix] on /dev/sdb. Now all members of the array are gone:
# dmraid -s
no raid disks
# dmraid -r
no raid disks
# wipefs /dev/sdb
offset type
---------------------------------------------
0x200 gpt [partition table]
So GParted must not run libparted partition table scanning on the member
devices in ATARAID arrays. Only on the array device itself.
In terms of the UI GParted must show disks which are ATARAID members as
whole disk devices with ATARAID member content and detect array busy
status to avoid allowing active members from being overwritten while in
use.
THIS COMMIT
Recognise ATARAID member devices and display in GParted as whole device
"ataraid" file systems. Because they are recognised as whole device
content ("ataraid" file systems) this alone stops GParted running the
libparted partition table scanning and avoids the above errors.
The list of dmraid supported formats is matched by the signatures
recognised by blkid:
$ dmraid -l
asr : Adaptec HostRAID ASR (0,1,10)
ddf1 : SNIA DDF1 (0,1,4,5,linear)
hpt37x : Highpoint HPT37X (S,0,1,10,01)
hpt45x : Highpoint HPT45X (S,0,1,10)
isw : Intel Software RAID (0,1,5,01)
jmicron : JMicron ATARAID (S,0,1)
lsi : LSI Logic MegaRAID (0,1,10)
nvidia : NVidia RAID (S,0,1,10,5)
pdc : Promise FastTrack (S,0,1,10)
sil : Silicon Image(tm) Medley(tm) (0,1,10)
via : VIA Software RAID (S,0,1,10)
dos : DOS partitions on SW RAIDs
$ fgrep -h _raid_member util-linux/libblkid/src/superblocks/*.c
.name = "adaptec_raid_member",
.name = "ddf_raid_member",
.name = "hpt45x_raid_member",
.name = "hpt37x_raid_member",
.name = "isw_raid_member",
.name = "jmicron_raid_member",
.name = "linux_raid_member",
.name = "lsi_mega_raid_member",
.name = "nvidia_raid_member",
.name = "promise_fasttrack_raid_member",
.name = "silicon_medley_raid_member",
.name = "via_raid_member",
As they are all types of Firmware / BIOS / ATARAID arrays, report all
members as a single "ataraid" file system type. (Except for
"linux_raid_member" in the above blkid source listing which is Linux
Software RAID).
Closes#75 - Errors with GPT on RAID 0 ATARAID array
The HACKING file should be hints for making changes to the code base and
associated processes. A overview of how GParted handled unallocated
space was not that. Also now the size of a JFS is accurately calculated
using JFS as an example of a file system with intrinsic unallocated
space is no longer valid. Therefore removed from the HACKING file.
Instead add the original commit message as an extended comment to method
calc_significant_unallocated_sectors().
Closes!50 - Calculate JFS size accurately
With the same minimum sized 16 MiB JFS used in the previous commit, now
mounted, GParted once again reports 1.20 MiB of unallocated space. This
is because the kernel JFS driver is also just reporting the size of the
Aggregate Disk Map (dmap) as the size of the file system [1].
Fix by reading the on disk JFS superblock to calculate the size of the
file system, but query the free space from the kernel using statvfs().
Need to query mounted JFS free space from the kernel because the on disk
dmap is not updated immediately so doesn't reflect recently used or
freed disk space.
For example, start with the 16 MiB JFS empty and mounted.
# echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree
[2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1
# df -k /mnt/1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 15152 136 15016 1% /mnt/1
Write 10 MiB of data to it:
# dd if=/dev/zero bs=1M count=10 of=/mnt/1/file_10M
10+0 records in
10+0 records out
1048760 bytes (10 MB, 10 MiB) copied, 0.0415676 s, 252 MB/s
Query the file system free space from the kernel and by reading the on
disk dmap figure:
# df -k /mnt/1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 15152 10376 4776 69% /mnt/1
# echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree
[2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1
# sync
# echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree
[2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1
# umount /mnt/1
# echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree
[2] dn_nfree: 0x000000004aa [10] dn_agwidth: 1
The kernel reports the updated usage straight away, but the on disk dmap
record doesn't get updated even by sync, only after unmounting.
This is the same fix as was previously done for EXT2/3/4 [2].
[1] Linux jfs_statfs() function
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/jfs/super.c?h=v3.10#n142
[2] 3828019030
Read file system size for mounted ext2/3/4 from superblock (#683255)
Closes!50 - Calculate JFS size accurately
Upstream NILFS project calls the package nilfs-utils [1][2]. Arch Linux
/ CentOS / Fedora / OpenSUSE use the upstream name. However Debian /
Ubuntu name it nilfs-tools [3] instead.
Document the needed software as:
nilfs-utils / nilfs-tools
Upstream name first separated by slash from alternative names
distributions use.
[1] NILFS Download page
https://nilfs.sourceforge.io/en/download.html
[2] NILFS Public Git Repositories
https://nilfs.sourceforge.io/en/git_repos.html
[3] Debian package: nilfs-tools
https://packages.debian.org/sid/nilfs-tools
Running JFS read usage test on Fedora 30 fails like this:
$ ./test_SupportedFileSystems --gtest_filter='*ReadUsage/jfs'
...
[ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs
unknown file: Failure
C++ exception with description "std::bad_alloc" thrown in the test body.
[ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 (41833 ms)
However the same test passes on Fedora 29, Fedora 31 Beta, CentOS 7,
Debian 10 and Ubuntu 18.04 LTS.
Also running GParted on Fedora 30 crashes just the same when reading JFS
usage:
# gparted
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.2
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
/usr/bin/gparted: line 202: 19218 Aborted (core dumped) $BASE_CMD
Running jfs_debugfs to query the file system usage the same way GParted
does produces an infinite amount of repeating output:
# echo dm | jfs_debugfs /dev/sdb1
So jfs_debugfs gets stuck in an infinite loop inside the dmap subcommand
when it encounters EOF. GParted and the read JFS usage test read this
output until memory is exhausted and crash. This is exactly what was
happening in closed bug 794947. Even installed jfsutils from Fedora 29
on Fedora 30 and visa versa. jfs_debugfs still produced an infinite
amount of output on Fedora 30 and worked correctly on Fedora 29. So
it's not the build of jfsutils, but something in the OS that is making
the difference!
Anyway fix by providing the instruction to exit from the dmap
subcommand, and quit from jfs_debugfs itself, like this:
# echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1
Bug 794947 - gparted hangs when sees JFS partition on discovering
partitions
Closes!49 - Add file system interface tests
GParted_Core::FILESYSTEMS and ::FILESYSTEM_MAP and the methods that
query and manipulate them are self-contained. Therefore move them into
a separate SupportedFileSystems module.
Also having a single class maintaining all FileSystem interface objects
will make testing all the file system types much easier as there will be
no need to duplicate this functionality in the test.
Closes!49 - Add file system interface tests
To match the renaming performed as part of Bug 741424 "Add support for
GPT partition names". In particular this is most closely similar to:
d480800600
Rename enum to OPERATION_LABEL_FILESYSTEM (#741424)
Separate udevsettle command was merged into udevadm back in udev 117
(released 2007-11-13) by:
225cb03bd8
udevadm: merge all udev tools into a single binary
The oldest supported distributions have these much newer versions of
udev:
Distro EOL udevadm -V
Debian 8 2020-Apr 215 (combined systemd and udev)
RHEL / CentOS 7 2024-Jun 219 (combined systemd and udev)
Ubuntu 16.04 LTS 2021-Apr 229 (combined systemd and udev)
Along with the previous patch "Avoid reading the same sector multiple
times in a row (!46)(#16)" internal detection of file system signatures
now reads the minimum number of sectors in increasing order.
As the code still considers the sector size, it now also reads less
sectors from devices with larger sectors to get all the signatures. So
on a 512 byte sector device it maximally seeks to and reads from these
byte offsets:
0, 512, 1024, 65536
and on a 4096 byte sector device, only from these byte offsets:
0, 65536
Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
Closes#16 - "invalid argument for seek()" error on very small (<=40KiB)
drives
GParted internal file system detection is reading the same sector
multiple times in a row. Add an optimisation to only read a sector if
it is different to the previously read sector.
Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
Closes#16 - "invalid argument for seek()" error on very small (<=40KiB)
drives
After the previous commit the lp_device structure pointer parameter is
only used to provide sector_size. Just pass that instead.
Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
Closes#16 - "invalid argument for seek()" error on very small (<=40KiB)
drives
GParted_Core::useable_device() doesn't change the pointed to PedDevice
structure. Pass it as const so the compiler enforces this.
Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
For every device that GParted scans, it determines if it can be used by
attempting to read the first sector. This is the sequence of events,
as reported in the previous two commit messages:
gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"]
...
gparted | useable_device(lp_device) lp_device->path="/dev/sdb"
gparted | ped_device_open()
libparted | open("/dev/sdb", O_RDWR) = 8
gparted | ped_device_read()
gparted | ped_device_close()
libparted | close(8)
udev(async)| KERNEL change /devices/.../sdb (block)
...
udev(async)| UDEV change /devices/.../sdb (block)
Note that these udev block device change events occur before the ones
waited for in the first commit "Wait for udev change on /dev/DISK when
querying whole device FS (!46)" so these were already waited for.
So because libparted only opens devices read-write this triggers a set
of udev change events for the whole block device, and if the device is
partitioned, also remove and re-add events for all the partitions.
Switch to using POSIX open(), read() and close() calls so read-only
access can be specified to avoid the unnecessary udev change events.
Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
After the previous fix, on my CentOS 7 VM, GParted is now often
reporting a warning that the /dev/PTN entry is missing when reading the
label of the file system in the first partition. This happens
regardless of the file system type.
Example error for EXT4:
e2label: No such file or directory while trying to open /dev/sdb1
Couldn't find valid file system superblock.
Example error for XFS:
/dev/sdb1: No such file or directory
fatal error -- couldn't initialize XFS library
As with the case in the previous commit, GParted gets the label via
blkid instead.
Again with debugging and sleeping in GParted, stracing the GParted
thread GParted_Core::set_devices_thread() and using 'udevadm monitor' to
watch udev events the following sequence of events is observed:
gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"]
gparted | ped_device_get("/dev/sdb")
libparted | open("/dev/sdb", O_RDONLY) = 8
libparted | close(8)
gparted | useable_device(lp_device) lp_device->path="/dev/sdb"
gparted | ped_device_open()
libparted | open("/dev/sdb", O_RDWR) = 8
gparted | ped_device_read()
gparted | ped_device_close()
libparted | close(8)
udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| KERNEL add /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL add /devices/.../sdb/sdb2 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb1 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb2 (block)
udev(async)| UDEV change /devices/.../sdb (block)
udev(async)| UDEV add /devices/.../sdb/sdb1 (block)
udev(async)| UDEV add /devices/.../sdb/sdb2 (block)
gparted | set_device_from_disk(device, device_path="/dev/sdb")
gparted | get_device(device_path="/dev/sdb", ..., flush=true)
gparted | ped_device_get()
gparted | flush_device(lp_device) lp_device->path="/dev/sdb"
gparted | ped_device_open()
libparted | open("/dev/sdb", O_RDWR) = 8
gparted | ped_device_sync()
gparted | ped_device_close()
libparted | close(8)
udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| KERNEL add /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL add /devices/.../sdb/sdb2 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb1 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb2 (block)
udev(async)| UDEV change /devices/.../sdb (block)
udev(async)| UDEV add /devices/.../sdb/sdb1 (block)
udev(async)| UDEV add /devices/.../sdb/sdb2 (block)
gparted | settle_device()
gparted | Utils::execute_command("udevadm settle --timeout=1")
gparted | detect_filesystem(lp_device, NULL, ...) lp_device->path="/dev/sdb"
gparted | detect_filesystem_internal(lp_device, NULL) lp_device->path="/dev/sdb"
gparted | ped_device_open()
libparted | open("/dev/sdb", O_RDWR) = 8
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_read()
gparted | ped_device_close()
libparted | close(8)
udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| KERNEL add /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL add /devices/.../sdb/sdb2 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb1 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb2 (block)
udev(async)| UDEV change /devices/.../sdb (block)
udev(async)| UDEV add /devices/.../sdb/sdb1 (block)
udev(async)| UDEV add /devices/.../sdb/sdb2 (block)
gparted | get_disk(lp_device, lp_disk, strict=false)
gparted | ped_disk_new(lp_device) lp_device->path="/dev/sdb"
libparted | open("/dev/sdb", O_RDWR) = 8
libparted | close(8)
udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| KERNEL add /devices/.../sdb/sdb1 (block)
udev(async)| KERNEL add /devices/.../sdb/sdb2 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb1 (block)
udev(async)| UDEV remove /devices/.../sdb/sdb2 (block)
udev(async)| UDEV change /devices/.../sdb (block)
udev(async)| UDEV add /devices/.../sdb/sdb1 (block)
udev(async)| UDEV add /devices/.../sdb/sdb2 (block)
gparted | set_device_partitions()
gparted | detect_filesystem()
gparted | set_partition_label_and_uuid(partition) partition.get_path()="/dev/sdb1"
gparted | read_label()
gparted | ext2::read_label()
gparted | Utils::execute_command("e2label /dev/sdb1")
So in this case for a partitioned drive, libparted ped_disk_new() is
opening and closing the device read-write and triggering the udev remove
and add partition block special entries exactly when the label is trying
to be read from the first partition, causing the device missing error.
The call chain is:
set_devices_thread()
set_device_from_disk()
get_disk()
ped_disk_new()
Looking at the source for ped_disk_new() [1] it is calling
ped_device_open() and ped_device_close(), hence why it is opening the
device read-write and triggering the udev events.
Looking back at commit "Wait for udev to recreate /dev/PTN entries when
calibrating (#762941)" [2] and re-testing it, the udev events were also
caused by ped_disk_new() with this call chain:
apply_operation_to_disk()
calibrate_partition()
get_disk()
ped_disk_new()
Fix this probe case and keep the fix for the previous calibrate case by
moving the waiting for udev events from calibrate_partition() into
get_disk(), right after ped_disk_new(). The maximum wait time is
shortened to the shorter 1 second probing timeout to avoid the longer
10 second apply timeout in this probing case. The calibrate case commit
message said "The longest I have seen udev take to do this is 0.80
seconds in a VM".
[1] parted/libparted/disk.c:ped_disk_new()
http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/disk.c?id=v3.2#n169
[2] fd9013d5f6
Wait for udev to recreate /dev/PTN entries when calibrating
(#762941)
Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
GParted nearly always shows this warning against a whole disk device
FAT32 file system on my development VMs:
plain floppy: device "/dev/sdb" busy (Resource temporarily
unavailable): Cannot initialize '::'
mlabel: Cannot initialize drive
However GParted does get the label via blkid instead. Occasionally
everything works correctly and there is no warning.
Never found a similar error for any other file system on a whole disk
device. The timing never seems to clash.
Remember that when a writable file descriptor of a disk device is
closed, udev events are triggered which update the kernel and /dev
entries for any partition changes. (This is in addition to coding which
has always existed in the partitioning tools, including fdisk and
parted, to inform the kernel, but not create /dev entries, of partition
changes).
With debugging and sleeping in GParted, stracing the GParted thread
GParted_Core::set_devices_thread() and using 'udevadm monitor' to watch
udev events the following sequence of events is observed:
gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"]
gparted | ped_device_get("/dev/sdb")
libparted | open("/dev/sdb", O_RDONLY) = 8
libparted | close(8)
gparted | useable_device(lp_device) lp_device->path="/dev/sdb"
gparted | ped_device_open()
libparted | open("/dev/sdb", O_RDWR) = 8
gparted | ped_device_read()
gparted | ped_device_close()
libparted | close(8)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
gparted | set_device_from_disk(device, device_path="/dev/sdb")
gparted | get_device(device_path="/dev/sdb", ..., flush=true)
gparted | ped_device_get()
gparted | flush_device(lp_device) lp_device->path="/dev/sdb"
gparted | ped_device_open()
libparted | open("/dev/sdb", O_RDWR) = 8
gparted | ped_device_sync()
gparted | ped_device_close()
libparted | close(8)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
gparted | set_device_one_partition()
gparted | set_partition_label_and_uuid()
gparted | read_label()
gparted | fat16::read_label()
gparted | Utils::execute_command("mlabel -s :: -i /dev/sdb")
This sequence of events only shows which close()s by libparted trigger
udev events. It does not show that processing those events are
asynchronous and overlap with GParted executing mlabel, causing the
device busy error.
As libparted's ped_device_open() doesn't offer a way to specify that a
device will only be used for reading, it always opens it read-write
[1][2]. Hence this sequence in GParted_Core::flush_device():
ped_device_open()
ped_device_sync()
ped_device_close()
always triggers udev change events on the whole disk device. Fix by
waiting for those udev events to complete.
[1] libparted documentation, PedDevice, ped_device_open()
https://www.gnu.org/software/parted/api/group__PedDevice.html#ga7c87bd06e76553c8ff3262b5e6ca256
[2] parted/libparted/arch/linux.c:linux_open()
http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c?id=v3.2#n1628Closes!46 - Whole device FAT32 file system reports device busy warning
from mlabel
The last distribution to include the separate 'udevinfo' command was
RHEL / CentOS 5 with udev 095. All supported distributions have much
newer versions of udev and instead have the 'udevadm' command.
A user reported that GParted was slow to refresh on FAT32 file systems:
"can take very long, up to several minutes; can be reproduced by running
dosfsck manually". This is because the file system was large and almost
full, and GParted performs a file system check just to to report the
file system usage.
Created a 4 GiB FAT32 file system and almost filled it with 4 KiB files,
just over 970,000 files.
# df -k /mnt/2
Filesystem 1K-blocks Used Available Used% Mounted on
/dev/sdb2 4186108 39155384 270724 94% /mnt/2
# df -i /mnt/2
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb2 0 0 0 - /mnt/2
# find /mnt/2 -type f -print | wc -l
971059
# find /mnt/2 -type d -print | wc -l
1949
Testing performance of the current fsck.fat:
# time fsck.fat -n -v /dev/sdb2 | \
> egrep 'bytes per logical sector|bytes per cluster|sectors total|clusters$'
512 bytes per logical sector
4096 bytes per cluster
8388608 sectors total
/dev/sdb2: 973008 files, 978846/1046527 clusters
real 0m11.552s
user 0m2.183s
sys 0m7.547s
Free sectors in the file system according to fsck.fat:
(1046527 - 978846) * 4096 / 512 = 541448 sectors
Repeating this test while also using 'blktrace /dev/sdb2' and Ctrl-C
around the test in a separate terminal, reports these numbers of I/Os
being performed:
Read requests Read bytes
15,563 165 MiB
Prior to this commit [1] from 0.0.9, GParted used libparted's
ped_file_system_get_resize_constraint() to report the minimum size to
which a FAT* file system can be resized. Use this test program [2] to
performance test this method:
# time ./fscons /dev/sdb2
dev=/dev/sdb2
sector_size=512
min_size=7909522
max_size=8388608
real 0m2.673s
user 0m0.070s
sys 0m1.834s
Free sectors in the file system according to libparted
ped_file_system_get_resize_constraint():
8388608 - 7909522 = 479086 sectors
blktrace reports these numbers of I/Os being performed:
Read requests Read bytes
7,821 71 MiB
So using libparted resize constraint is a bit faster but is still
reading too much data and is really too slow. Also when testing GParted
using this libparted method against a corrupted FAT32 file system, on
every refresh, one popup dialog is displayed for each error libparted
detects with the file system, each of which needs acknowledgement.
Example popup:
Libparted Error
\DIRNAME\FILENAME.EXT is 107724k, but is has 1920
clusters (122880k).
[ Cancel ][ Ignore ]
There could be a huge number of such errors in a corrupted file system.
Not really suitable for use by GParted.
Test the performance of mtools' minfo command to report the file system
figures:
# time minfo -i /dev/sdb2 :: | \
> egrep 'sector size:|cluster size:|small size:|big size:|free clusters='
sector size: 512 bytes
cluster size: 8 sectors
small size: 0 sectors
big size: 8388608 sectors
free clusters=67681
real 0m0.013s
user 0m0.004s
sys 0m0.019s
Free sectors in the file system according to minfo:
67681 * 8 = 541448 sectors
blktrace reports these numbers of I/Os being performed by minfo:
Read requests Read bytes
1 16 KiB
This matches with minfo just reading information from the BPB (BIOS
Parameter Block) [3] from sector 0 and the FS Information Sector [4]
usually in sector 1. Note that the free cluster figure reported by
minfo comes from the FS Information Sector because it only reports it
for FAT32 file systems, not for FAT16 file systems. Scanning the File
Allocation Table (FAT) [5] to count free clusters is exactly what mdir,
without the '-f' (fast) flag, does. Test the performance of mdir:
# export MTOOLS_SKIP_CHECK=1
# time mdir -i /dev/sdb2 ::/ | fgrep 'bytes free'
277 221 376 bytes free
real 0m0.023s
user 0m0.011s
sys 0m0.023s
Free sectors in the file system according to mdir:
277221376 / 512 = 541448 sectors
blktrace reports these number of I/Os being performed by mdir:
Read requests Read bytes
5 448 KiB
So minfo and mdir together provide the needed information and are 2 to 3
orders of magnitude faster because they only read the needed BPB and FAT
data from the drive. Use these together to read the file system usage.
[1] 61cd0ce778
lots of stuff and cleanups, including fixing getting used/unused
space of hfs/hfs+/fat16/fat32
[2] fscons.c
/* FILE: fscons.c
* SYNOPSIS: Report libparted's FS resize limits.
* BUILD: gcc -o fscons fscons.c -lparted -lparted-fs-resize
*/
int main(int argc, const char *argv[])
{
PedDevice* dev = NULL;
PedDisk* tab = NULL;
PedPartition* ptn = NULL;
PedFileSystem* fs = NULL;
PedConstraint* cons = NULL;
if (argc != 2)
{
fprintf(stderr, "Usage: fscons BLOCKDEV\n");
exit(1);
}
dev = ped_device_get(argv[1]);
if (dev == NULL)
{
fprintf(stderr, "ped_device_get(\"%s\") failed\n", argv[1]);
exit(1);
}
printf("dev=%s\n", dev->path);
printf("sector_size=%ld\n", dev->sector_size);
tab = ped_disk_new(dev);
if (tab == NULL)
{
fprintf(stderr, "ped_disk_new(dev) failed\n");
exit(1);
}
ptn = ped_disk_get_partition_by_sector(tab, 0);
if (ptn == NULL)
{
fprintf(stderr, "ped_disk_get_partition(tab, 0) failed\n");
exit(1);
}
fs = ped_file_system_open(&ptn->geom);
if (fs == NULL)
{
fprintf(stderr, "ped_file_system_open(&ptn->geom) failed\n");
exit(1);
}
cons = ped_file_system_get_resize_constraint(fs);
if (cons == NULL)
{
fprintf(stderr, "ped_file_system_get_resize_constraint(fs) failed\n");
exit(1);
}
printf("min_size=%ld\n", cons->min_size);
printf("max_size=%ld\n", cons->max_size);
ped_constraint_destroy(cons);
ped_file_system_close(fs);
ped_disk_destroy(tab);
ped_device_destroy(dev);
return 0;
}
[3] Design of the FAT file system, BIOS Parameter Block
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#BIOS_Parameter_Block
[4] Design of the FAT file system, FS Information Sector
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FS_Information_Sector
[5] Design of the FAT file system, File Allocation Table
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#File_Allocation_Table
Bug 569921 - dosfsck -n delays device scan
When GParted is configured with `--disable-doc` the help documentation
is neither built, nor installed.
With this configuration the Help -> Contents menu displays a message
dialog indicating the "Documentation is not available".
On GNOME 3 no title is shown; however, on some other graphic toolkits
/ window managers an unspecified title is shown.
For example on GParted Live with Fluxbox the following is displayed:
Unnamed
-------
Documentation is not available
This build of gparted is configured without documentation.
Documentation is available at the project web site.
https://gparted.org
OK
To address the unspecified title on non-GNOME 3 graphic toolkits, add
a title that works with and without GNOME 3.
Closes!45 - Add missing window title to Help Contents dialog
All the dialogs which compose new or modified partition boundaries
create those partitions within the boundaries of the device. Therefore
trimming the partition boundaries to device boundaries never happens.
So replace this trimming with bug error reports.
Also add bug prefixes to the other error messages in
GParted_Core::valid_partition() too.
Closes#48 - Error when moving locked LUKS-encrypted partition
The previous commit moved the code from GParted_Core to
Dialog_Base_Partition class without making a single formatting change to
ensure the code was guaranteed to work the same within that larger
commit. Now reformat the code to current layout standards. Making it a
separate commit simplifies the effort for both changes and improves
bisectability.
Additionally to be sure there were no code changes,
Dialog_Base_Partition.cc was compiled to assembler code with and without
this change applied and the resultant assembler code compared. There
were no differences in the generated assembler code.
Start with the make generated g++ command for compiling
Dialog_Base_Partition.o; (1) remove the '-g' flag as inserted debugging
directives do differ; and (2) replace '-c -o Dialog_Base_Partition.o'
with '-S -o Dialog_Base_Partition.s' to produce assembler output instead
of object code.
Closes#48 - Error when moving locked LUKS-encrypted partition
Move snap_to_*() method calls from the point when all operations are
added to the list, to earlier when Resize/Move, Paste (into new) and
Create New dialogs are composing the new partition objects. In
particular for the Resize/Move operation, to just before updating the
file system usage.
This change finally resolves this bug.
Because of the dialog call chains into Dialog_Base_Partition,
snap_to_alignment() must be added into:
* Dialog_Base_Partition::prepare_new_partition() for the Resize/Move and
Paste (into new) dialogs; and
* Dialog_Partition_New::Get_New_Partition() for the Create New dialog.
Closes#48 - Error when moving locked LUKS-encrypted partition
The current device has to be passed to the dialog constructors and then
on to the Dialog_Base_Constructor. Note that the Dialog_Partition_New
constructor is already passed the current device, however it still needs
to pass it on to Dialog_Base_Constructor.
This is ready so that snap_to_*() methods can access the current device
when they are called from within these dialogs.
* Pass Parameter to Base Class Constructor while creating Derived class
Object
https://stackoverflow.com/questions/16585856/pass-parameter-to-base-class-constructor-while-creating-derived-class-objectCloses#48 - Error when moving locked LUKS-encrypted partition
Move setting of the new_partition object file system usage to after
everything else, specifically after free_space_before and strict_start.
This is because snap_to_*() use free_space_before and strict_start and
snap_to_alignment() is going to be called before the file system usage
is updated to avoid the error in this bug report.
Closes#48 - Error when moving locked LUKS-encrypted partition
None of the snap_to_*() methods report any errors so remove the unused
error parameter and return value.
Closes#48 - Error when moving locked LUKS-encrypted partition
PATCHSET OVERVIEW
A user had 2 adjacent partitions which were aligned to multiples of
33553920 bytes (32 MiB - 512 bytes), not MiB or cylinders. As far as
GParted is concerned this is not aligned. The second partition
contained closed LUKS encrypted data. Recreate this setup with:
# truncate -s 200G /tmp/disk.img
# losetup -f --show /tmp/disk.img
/dev/loop0
# sfdisk -u S /dev/loop0 << EOF
65535 2162655 83
2228190 78904140 83
EOF
# partprobe /dev/loop0
# echo -n badpassword | cryptsetup luksFormat /dev/loop0p2 -
When trying to move the second LUKS encrypted partition to the right by
any amount, with the default MiB alignment, GParted displays this error
dialog and fails to even queue the operation:
Could not add this operation to the list
A partition with used sectors (78907392) greater than its
length (78905344) is not valid
[ OK ]
Overview of the steps involved:
1. The Resize/Move dialog composed a new partition to start a whole
multiple of MiB after the end of the previous non-aligned partition.
The new partition also had it's size increased to a whole multiple of
MiB, to 78907392 sectors (38529 MiB) which was 1.59 MiB larger than
before. Neither the start or end of the new partition are aligned at
this point.
2. Win_GParted::activate_resize() applied the change back to the closed
LUKS partition object, additionally making the used sectors equal to
the partition size.
(To match the fact that when opened the LUKS mapping it will
automatically fill the new larger partition size).
3. GParted_Core::snap_to_mebibyte() then aligned the partition start and
end to whole MiB boundaries, reducing the partition size in the
process to 78905344 (38528 MiB).
4. GParted_Core::snap_to_alignment() reported the error saying that it
couldn't add the operation to the list because it was invalid to have
the file system used sectors larger than the partition size.
Fix this by having the snap to alignment adjustments applied before the
dialogs update any associated file system usage. Specifically the
Resize/Move, Paste (into new) and Create New dialogs as these are the
only ones which either create or modify partition boundaries.
Validation done by snap_to_alignment() will continue to occur at the
current point when the operation is added to the list.
THIS COMMIT
snap_to_alignment() is doing two different jobs, it is (1) optionally
adjusting the new partition boundaries for MiB or Cylinder alignment;
and (2) checking that the partition boundaries and file system usage are
valid.
Split those into two different functions (1) snap_to_alignment() and
(2) valid_partition(). For now valid_partition() still calls
snap_to_alignment() so there is no functional change with this commit.
Closes#48 - Error when moving locked LUKS-encrypted partition
After an NTFS file system has been resized the command GParted currently
uses to read the file system usage fails like this:
# ntfsinfo --mft /dev/sdb1
Volume is scheduled for check.
Please boot into Windows TWICE, or use the 'force' option.
NOTE: If you had not scheduled check and last time accessed this volume
using ntfsmount and shutdown system properly, then init scripts in your
distribution are broken. Please report to your distribution developers
(NOT to us!) that init scripts kill ntfsmount or mount.ntfs-fuse during
shutdown instead of proper umount.
Failed to open '/dev/sdb1'.
Fix by added the '--force' flag as described in the error message.
Closes#57 - NTFS Resize results in Partition Information Warning on
Refresh
GParted uses ntfsinfo to read the NTFS file system usage. However when
ntfsinfo fails with a non-zero exit status GParted reports stdout twice,
rather than stdout and stderr. Correct this.
Closes#57 - NTFS Resize results in Partition Information Warning on
Refresh
With the same case as from the previous commit, the very long "Mounted
on ..." text is now wrapped, but the text may not be left justified.
Slowly adjust the dialog width and see how the text wrapping is updated
to fit the size adjustment but the text is centred rather than left
justified.
This is because setting the halign property to Gtk::ALIGN_START does not
guarantee left alignment of text for wrapped or ellipsized Gtk::Labels.
Use the xalign property instead.
To set the xalign property there is a method in the GtkMisc (Gtk::Misc)
base class:
gtk_misc_set_alignment (Gtk::Misc::set_alignment)
However, GtkMisc (Gtk::Misc) was deprecated in Gtk 3.14 (Gtkmm 3.14)
and in Gtk 3.16 (gtkmm 3.16) set_alignment() was replaced with the
introduction of two new methods:
gtk_label_set_xalign (Gtk::Label::set_xalign)
gtk_label_set_yalign (Gtk::Label::set_yalign)
Add a check for Gtkmm method Gtk::Label::set_xalign() in configure.ac
and use it when available.
References:
[1] Gtk3 Reference Documentation - gtk_misc_set_alignment()
https://developer.gnome.org/gtk3/stable/GtkMisc.html#gtk-misc-set-alignment
"gtk_misc_set_alignment has been deprecated since version 3.14 and
should not be used in newly-written code. Use GtkWidget's alignment
("halign" and "valign") and margin properties or GtkLabel's
"xalign" and "yalign" properties."
[2] Gtkmm 3.16 Gtk::Misc Class Reference, set_alignment() method
https://developer.gnome.org/gtkmm/3.16/classGtk_1_1Misc.html#a52b2675874cf46a3097938756b9fe9e8
[3] GNOME BugZilla - EmptyBoxes: instructions_label's alignment is off
https://bugzilla.gnome.org/show_bug.cgi?id=735841
[4] Gtk commit from 2014-09-16:
GtkLabel: add x/yalign properties
https://gitlab.gnome.org/GNOME/gtk/commit/d39424fc
[5] Gtk3 Reference Documentation - gtk_label_set_xalign()
https://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-xalign
[6] Gtkmm 3.16 Gtk::Label Class Reference, set_xalign() method
https://developer.gnome.org/gtkmm/3.16/classGtk_1_1Label.html#acee7d4e87d7cc14080a7b8ded5f84e5eCloses!40 - Limit wrapping labels
Opening the Partition Information dialog for a file system mounted on a
very long mount point, or on openSUSE which mounts the OS from 10 btrfs
subvolumes from the same partition, will cause the dialog to be very
wide as the "Mounted on ..." text is not wrapped.
Back in Gtk2, when width_chars / max_width_chars were not set, wrapping
labels had a default width beyond which text wrapped onto a new line
[1].
For Gtk3 this default width was first reworked a bit [2], and then was
removed for the very early Gtk3 3.0.10 release [3].
It is recommended that applications explicitly set default values,
otherwise wrapping labels never wrap when requesting their natural
allocation.
References:
[1] Gtk 2.24.32 source code - gtk/gtklabel.c:2975
https://gitlab.gnome.org/GNOME/gtk/blob/2.24.32/gtk/gtklabel.c#L2975
"This long string gives a good enough length for any line to
have."
[2] Gtk commit from 2010-04-21:
680d7762ba
Make sure not to base the minimum size on "max-width-chars", only
the natural size.
"This string is just about long enough."
[3] Gtk commit from 2011-04-17:
c8ce1106c1
label: Don't try to guess a label's size
People should use window default sizes or label
width-chars/max-width-chars to find the ideal layout for a label
instead of relying on magic.
Closes!40 - Limit wrapping labels
Before Gtk 3.22 GtkScrolledWindow propagated natural size to its
Children and so on to descendants. In Gtk 3.22 this was changed to
always request the minimum size. This was done because it is believed
to be a safer default (gives a better behaviour) in case of dynamic
content inside the scrolled window, that is, content that may change
allocated size. [1][2][3]
When the scrolled window content is not dynamic the natural size is
preferable because it gives a better looking layout and without any
downside.
In the case of GParted content which is not dynamic, so request the
scrolled windows to allocate children at natural sizes for Gtk >= 3.22.
The benefits of natural size allocation are evident in presence of
wrapping labels (for example inside the "Partition Info" dialog), that
with the minimum size request likely end up taking a very small width.
References:
[1] Gtk commit from 2016-08-31:
GtkScrolledWindow: Make propagation of natural child sizes optional
0984d1622d
"Making propagation of child natural sizes mandatory (or default,
even) was evidently a mistake as this causes dynamic content in a
scrolled window to resize it's parent when the scrolled window is
competing for space with an adjacent widget."
[2] Gtk 3.22 Reference Documentation -
gtk_scrolled_window_set_propagate_natural_width
https://developer.gnome.org/gtk3/3.22/GtkScrolledWindow.html#gtk-scrolled-window-set-propagate-natural-width
[3] Gtkmm 3.24 Gtk::ScrolledWindow Class Reference,
set_propagate_natural_width() method
https://developer.gnome.org/gtkmm/3.24/classGtk_1_1ScrolledWindow.html#a2d4cb945688ecb8739efd70b18742779
[4] Gtkmm 3.21.6 NEWS
https://gitlab.gnome.org/GNOME/gtkmm/blob/3.21.6/NEWS
"ScrolledWindow: Added get/set_propagate_natural_height/width() and
the properties."
Closes!39 - Always request natural size inside Gtk::ScrolledWindow
Gtk::Table was deprecated in Gtk 3.4.0. Replace with Gtk::Grid.
This commit makes the change for Dialog_Partition_Info.
Closes!25 - Modern Gtk3 - part 1
Gtk::Table was deprecated in Gtk 3.4.0. Replace with Gtk::Grid.
This commit makes the change for Dialog_Base_Partition.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_Progress.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_Rescue_Data.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for DialogPasswordEntry.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_Partition_Name.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_FileSystem_Label.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for DialogFeatures.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_DiskLabel.cc.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_Partition_Info.{h,cc}.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for Dialog_Base_Partition.{h,cc}.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with
plain Gtk::Box.
This commit makes the change for HBoxOperations.{h,cc}.
Closes!25 - Modern Gtk3 - part 1
Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2 [1]. Replace with
plain Gtk::Box.
This commit makes the change for Win_GParted.{h,cc}.
[1] Gtkmm 3.2.0 NEWS file (actually first included in gtkmm 3.1.6
unstable)
https://gitlab.gnome.org/GNOME/gtkmm/blob/3.2.0/NEWS#L91
Gtk:
* All H* or V* specialized classes have been deprecated, to
match the deprecations in the GTK+ C API. You should now
set the orientation instead.
This includes HBox, VBox, HButtonBox, VButtonBox, HPaned,
VPaned, HScale, VScale, HSeparator, VSeparator, HScrollbar and
VScrollbar.
Closes!25 - Modern Gtk3 - part 1
The Gdk::RGBA data type was introduced to replace Gdk::Color in
Gtkmm 3.0 [1], with Gdk::Color being deprecated in Gtkmm 3.10 [2].
With this commit we make the change to Gdk::RGBA data type which is the
modern replacement to Gdk::Color. Gdk::RGBA can be used almost as a
drop in replacement because it keeps most of the Gdk::Color interface.
Also, this commit removes the C Gtk call introduced during the
port-to-gtk3 patchset by commit:
5379352766
repare-for-gtk3: Prepare for removal of Gtk::Widget::modify_fg() (#7)
[1] Gtkmm 3.0.1 NEWS file
https://gitlab.gnome.org/GNOME/gtkmm/blob/3.0.1/NEWS#L48
* RGBA replaces Color, though Color still exists because it is
used by TextView. We hope to deprecated Color completely in
gtkmm 3.2.
[2] Gtkmm 3.10.0 NEWS file
https://gitlab.gnome.org/GNOME/gtkmm/blob/3.10.0/NEWS#L127
Gdk:
* Deprecate Color.
Closes!25 - Modern Gtk3 - part 1
Mostly add, but also remove, #includes so both DialogFeatures.h and .cc
include exactly the header files each needs to get the definitions they
use.
Header file #include guards are there to specifically enable this.
To better reflect that it is loading the supported actions for one file
system into the treeview, just like it's parent load_filesystems() is
initiating the loading for all the file systems.
Select a partition and look at the available actions in the Partition
menu. Then add or remove some commands which that particular file
system uses and rescan to detect those changes. Open the Partition menu
again. It doesn't reflect the changes of supported actions seen in the
File System Support dialog. Select a different partition and then
select the original partition again. Now the available actions in the
Partition menu reflect the changes of supported actions.
Have been testing by adding and removing /sbin/e2label to add and
remove EXT2/3/4 file system labelling support just because that feature
has existed for a very long time and EXT2/3/4 are displayed near the top
of the File System Support dialog. Tested this minor issue existed as
far back as GParted 0.3.7.
Fix by simply also refreshing the valid operations to update the
Partition menu after updating the found file system specific commands.
Closes!38 - Fixes for minor issues with File System Support rescanning
Open the File System Support dialog, either add or remove some file
system specific commands used by GParted and press the
[Rescan For Supported Actions] button. The supported actions don't
change. However after just closing and reopening the dialog, the
supported actions do reflect the added or removed file system specific
commands.
Bisected to this commit:
4d6d464664
Display "other" in the File System Support dialog (!13)
The problem is that commit made a subset copy of the
GParted_Core::FILESYSTEMS vector, obtained from get_filesystems(), so
when the rescan ran and the FILESYSTEMS vector was updated with new
supported actions, the dialog still displayed the original subset copy,
so didn't reflect the changed supported actions.
Fix by passing a reference to the GParted_Core::FILESYSTEMS vector,
obtained from get_filesystems(), and perform the necessary filtering
inside the dialog, like before the above faulty commit. Additionally
finding and adding "other" file system to the end of the list.
Closes!38 - Fixes for minor issues with File System Support rescanning
The oldest supported distributions have these versions of ntfs-3g /
ntfsprogs.
Distro EOL ntfs-3g / ntfsprogs
- Debian 8 2020-Jun 2014.2.16AR.2
- RHEL / CentOS 7 2024-Jun 2017.3.23
- Ubuntu 14.04 LTS 2019-Apr 2013.1.13AR.1
The oldest version of ntfs-3g / ntfsprogs on Ubuntu 14.04 LTS includes
support for the --new-serial option.
$ ntfslabel -V
ntfslabel v2013.1.13AR.1 (libntfs-3g) - Display, or set, the label for an NTFS Volume.
$ ntfslabel --help | grep -- --new-serial
--new-serial Set a new serial number
Therefore it is no longer necessary to check for this option as it is
always available. The worst case scenario is that some how an old
version of ntfslabel is used which doesn't support this option. In such
a case GParted goes from not supporting changing the UUID to claiming
support, but presumably it would fail with an error reporting unknown
option when applied. Arguably better from an end user support point of
view.
A user reported GParted was slow to refresh and timing ntfsresize to
query his file systems found that it was taking 4.7 seconds and 9.2
seconds for sizes 31.7 GiB and 49 GiB NTFS file systems respectively.
Almost 14 seconds just to read the usage.
Created a 4 GiB NTFS and filled it with as many 4 KiB files as possible,
just over 800,000 files.
# df -k /mnt/2
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb2 4194300 4193860 440 100% /mnt/2
# df -i /mnt/2
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb2 819640 808591 11049 99% /mnt/2
Testing perform of ntfsresize:
# time ntfsresize --info --force --no-progress-bar /dev/sdb2 | \
> egrep 'Current volume size|resize at|Cluster size'
Cluster size : 4096 bytes
Current volume size: 4294963712 bytes (4295 MB)
You might resize at 4294516736 bytes (freeing 450560 bytes).
real 0m5.231s
user 0m2.072s
sys 0m3.014s
Computation of figures:
Clusters per volume = 4294963712 / 4096 = 1048575.125
Free clusters = (4294963712 - 4294516736) / 4096 = 109.125
Testing performance of ntfscluster, as used before this commit [1] from
GParted 0.3 in 2006:
# time ntfscluster --force /dev/sdb2 | \
> egrep 'bytes per cluster|bytes per volume|clusters per volume|clusters of free space'
...
bytes per cluster : 4096
bytes per volume : 4294963200
clusters per volume : 131071
clusters of free space : 110
real 0m4.243s
user 0m1.629s
sys 0m2.587s
Note that the clusters per volume figure reported by ntfscluster is
wrong. 4294963200 / 4096 = 1048575, not 131071.
Testing performance using ntfsinfo:
# time ntfsinfo --mft /dev/sdb2 | \
egrep 'Cluster Size|Volume Size in Clusters|Free Clusters'
Cluster Size: 4096
Volume Size in Clusters: 1048575
Free Clusters: 110 (0.0%)
real 0m0.022s
user 0m0.012s
sys 0m0.018s
Repeating the above tests while also using 'btrace /dev/sdb2' and Ctrl-C
around each test via a separate terminal, reports these numbers of I/Os
being performed:
Command Read requests Read bytes
- ntfsresize 2,695 1116 MiB
- ntfscluster 2,685 1116 MiB
- ntfsinfo 13 2208 KiB
No wonder that ntfsresize and ntfscluster take a long time, they read
just over 1 GiB of data from the 4 GiB file system, where as ntfsinfo
only reads just over 2 MiB.
Switch to using ntfsinfo to report file system usage.
[1] 9d956594d6
replaced ntfscluster with ntfsresize (see #350789)
Closes#47 - GParted is slow refreshing NTFS file systems
With that same commit in parted 1.9 [1], libparted only recognised these
linux-swap names via deprecated aliases:
linux-swap(old)
linux-swap(new)
but does accept this name as a current alias:
linux-swap
for:
linux-swap(v1)
Demonstration:
# parted -v
parted (GNU parted) 2.1
...
# parted /dev/sdc mkfs yes 1 "linux-swap(new)" unit s print
...
[0] filesys.c:148 (ped_file_system_type_get(): File system alias linux-swap(new) is deprecated
...
Number Start End Size Type File system Flags
1 2048s 2099199s 2097152s primary linux-swap(v1)
# parted /dev/sdc mkfs yes 1 "linux-swap" unit s print
...
Number Start End Size Type File system Flags
1 2048s 2099199s 2097152s primary linux-swap(v1)
Again as GParted now requires libparted 2.2 or later:
1) Stop using alternative "linux-swap(new)" name as that is deprecated
by libparted.
2) Also stop using alternative "linux-swap(v1)" name as that code is
never used because libparted recognised the GParted "linux-swap"
name as a current alias.
[1] http://git.savannah.gnu.org/cgit/parted.git/commit/?id=cfafa4394998a11f871a0f8d172b13314f9062c2
Rationalise linux-swap fs names, and add a "linux-swap" alias
With this commit in parted 1.8.3 [1], libparted changed from reporting
the name of Linux swap as:
linux-swap
to reporting either:
linux-swap(old)
linux-swap(new)
Later with this commit in parted 1.9 [2], libparted stopped reporting
those names and reported these instead:
linux-swap(v0)
linux-swap(v1)
Demonstration:
# mkswap /dev/sdc1
Setting up swapspace version 1, size = 1048572 KiB
no label, UUID=a2010834-003d-4bf2-9e94-58383fe20a26
# blkid /dev/sdc1
/dev/sdc1: UUID="a2010834-003d-4bf2-9e94-58383fe20a26" TYPE="swap"
# parted -v
parted (GNU parted) 2.1
...
# parted /dev/sdc unit s print
...
Number Start End Size Type File system Flags
1 2048s 2099199s 2097152s primary linux-swap(v1)
As GParted now requires libparted 2.2 or later [3], remove recognition
for those no longer libparted reported linux-swap names. Note that the
"swap" name is reported by blkid.
[1] http://git.savannah.gnu.org/cgit/parted.git/commit/?id=98a53fd115ca012edf226525b8d4be628454f99e
Enable support for swsusp partitions, and the ability to
differentiate between old and new versions of linux-swap partitions.
Changed the swap_init signature and removed extra ped_geometry_read
from _swap*_open.
[2] http://git.savannah.gnu.org/cgit/parted.git/commit/?id=cfafa4394998a11f871a0f8d172b13314f9062c2
Rationalise linux-swap fs names, and add a "linux-swap" alias
[3] 8df975c7d1
Increase minimum required libparted to 2.2 (!22)
Formatting a partition to cleared over the top of LVM2 PV leaves the
"lvm" flag set on the partition; where as formatting with an actual file
system over the top of an LVM2 PV clears the "lvm" flag. This is true
for both MSDOS and GPT partitioned drives.
Fix by setting the partition type when formatting to cleared too.
Closes!36 - Set partition type when clearing partition contents
Having a member variable named 't' which is used to share state in a
Dialog_Progress object between on_signal_show() and on_cancel() methods
is horrible. Rename to something more meaningful.
Also initialise m_curr_op in the constructor's initialisation list,
rather than later when first used in on_signal_show(). Not strictly
required, but avoids this POD (Plain Old Data) member variable being
undefined in the Dialog_Progress object between construction and when
on_signal_show() previously assigned to it for the first time and
started using it.
* C++ FAQ / Should my constructors use "initialization lists" or
"assignment"?
https://isocpp.org/wiki/faq/ctors#init-lists
Writes the starting device overview information of all known devices to
the top of the saved details HTML. This is so that hopefully we don't
need to additionally ask users for their disk layouts via 'fdisk -l',
'parted print' and 'lsblk' when the saved details file is provided.
Also moves the equals separators "==================" from below to
above each operation so the each section is separated.
Bug 639176 - Save partition layout to gparted_details.htm
Some icon themes only provide large icons for stock items. This can
cause problems like overly large icons appearing in the GParted UI.
Found on Kubuntu 16.04 LTS with default breeze icon theme.
Be compatible with these icon themes by forcing scaling of stock icons
to the requested size.
Icons are used either by Gtk::Image widgets, or Gtk::CellRendererPixbuf
objects for comboboxes/treeviews. For Gtk::Image widgets we add
Utils::mk_image() that constructs Gtk::Image widgets and then sets the
pixel-size property. For Gtk::CellRendererPixbuf we add
Utils::mk_pixbuf() that first loads a Gdk::Pixbuf and then scales if
needed.
Closes#39 - After GTK3 port icons are too big on KDE
To further help in diagnosing root authorisation issues by reporting the
error message to the terminal too. Also set a failure exit status when
terminating with this error.
Example:
$ ./gpartedbin
GParted 0.33.0-git
configuration --enable-online-resize
libparted 3.2
Root privileges are required for running GParted
$ echo $?
1
Closes!34 - Display more version and configuration information
So that the new version and configuration information is displayed even
if the gpartedbin executable is run as a non-root user. To help with
diagnosing root authorisation issues with the gparted shell wrapper
script.
Closes!34 - Display more version and configuration information
For consistency save the 3 same lines of information into the saved
operation details. None of the new 3 lines are subject to translation.
As this information is really for our benefit when supporting users
leaving them as English is OK. Also "GParted" and "Libparted", as
previously used, are proper nouns so they were never changed as part of
any language translation. See with:
egrep -r '"(GParted|Libparted)"' po/
Closes!34 - Display more version and configuration information
So that we might get more information from users when helping them.
Starting GParted from the command line now looks like this:
# ./gpartedbin
GParted 0.33.0-git
configuration --enable-online-resize
libparted 3.2
Closes!34 - Display more version and configuration information
Running GParted on AltLinux with dmraid installed but with no configured
RAID arrays produces this error:
# gparted
...
Could not stat device /dev/mapper/No RAID disks - No such file or directory.
Most distributions use dmraid 1.0.0.rc16 which reports no raid disks
like this:
# dmraid -sa -c
no raid disks
# echo $?
1
However AltLinux had the slightly older version, dmraid 1.0.0.rc14,
which reported no raid disks like this:
# dmraid -sa -c
No RAID disks
# echo $?
0
So because dmraid 1.0.0.rc14 reported success, exit status 0, and the
"No RAID disks" message was not in lower case, that text was considered
a disk device in a DMRaid array. Fix by checking for "no raid disks" in
any case.
Bug 786031 - Could not stat device /dev/mapper/No RAID disks - No such
file or directory
Glibmm has implemented a ustring::compose() set of methods [1] since
Glibmm 2.16, circa 2008. So replace String::ucompose(). Note that
GParted already requires glibmm >= 2.32 as set in configure.ac.
This commit just replaces all the method calls. Edit created by:
sed -i 's|String::ucompose *|Glib::ustring::compose|' src/*.cc
[1] Glibmm Reference Manual, Glib::ustring Class, compose() method
https://developer.gnome.org/glibmm/2.32/classGlib_1_1ustring.html#a64ff7ac3d9e9899c2910f1d831f8d500Closes#46 - Drop compose subdir
Fix to make mkfs.f2fs properly handle labels longer than 16 characters
was included in f2fs-tools 1.2.0 [1]. The oldest supported
distributions now include this release:
Distro EOL f2fs-tools
- Debian 8 2020-Jun 1.4.0
- RHEL / CentOS 7 2024-Jun 1.4.1
- SLES 12 2027-Oct Unknown
- Ubuntu 14.04 LTS 2019-Apr 1.2.0
Note that on Ubuntu 14.04 LTS blkid from util-linux 2.20.1 is too old to
recognise F2FS file systems, as 2.23 is required for F2FS support [2].
mkfs.f2fs claims the maximum label length is less than 512 characters,
but actually accepts 512 characters.
# label=`head -c 1024 < /dev/zero | tr '\0' 'A'`
# mkfs.f2fs -l `echo -n "$label" | cut -c1-513` /dev/sdb10
F2FS-tools: mkfs.f2fs Ver: 1.4.0 (2014-09-18)
Error: Volume Label should be less than 512 characters
Usage: mkfs.f2fs [options] device [sectors]
[options]:
-a heap-based allocation [default:1]
-d debug level [default:0]
-e [extension list] e.g. "mp3,gif,mov"
-l label
-o overprovision ratio [default:5]
-s # of segments per section [default:1]
-z # of sections per zone [default:1]
-t 0: nodiscard, 1: discard [default:1]
sectors: number of sectors. [default: determined by device size]
# echo $?
1
# mkfs.f2fs -l `echo -n "$label" | cut -c1-512` /dev/sdb10
F2FS-tools: mkfs.f2fs Ver: 1.4.0 (2014-09-18)
Info: Label = AAAAAAAAAAAA...[trimmed from 512 "A"s]...AAAAAAAAAAAA
Info: sector size = 512
Info: total sectors = 1048576 (in 512bytes)
Info: zone aligned segment0 blkaddr: 256
Info: Discarding device
Info: This device doesn't support TRIM
Info: format successful
# echo $?
0
# blkid -V
blkid from util-linux 2.25.2 (libblkid 2.25.0, 24-Oct-2014)
# blkid /dev/sdb
/dev/sdb10: LABEL="AAAAAAAAAAAA...[only 127 "A"s]...AAAAAAAAAAAA"
UUID="f47f3fdc-dd91-4616-bb6d-0d643a884265" TYPE="f2fs"
PARTUUID="3bb4bef8-9494-4e82-8dda-5d8edd9c60d9"
As blkid only reports the first 127 characters and is the only command
used for reading the label of an F2FS file system, use this as the new
increased limit.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?id=9799d6364dc93e1fd259d812d4a50ed984a6456b
mkfs: handle labels longer than 16 characters
[2] https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.23/v2.23-ReleaseNotes
"add Flash-Friendly File System (f2fs) support [Alejandro Martinez
Ruiz]"
Closes!29 - Enhance F2FS support
On CentOS 7 with f2fs-tools 1.4.1, checking an F2FS file system fails
like this:
# fsck.f2fs -f -y -a /dev/sdb3
Info: Force to fix corruption
fsck.f2fs: invalid option -- 'y'
Error: Unknown option ?
Usage: fsck.f2fs [options] device
[options]:
-a check/fix potential corruption, reported by f2fs
-d debug level default:0]
-f check/fix entire partition
-t show directory tree [-d -1]
# echo $?
1
Turns out that the '-y' option was not available until f2fs-tools 1.10.0
and is identical to the existing '-f' option anyway [1], which GParted
already uses. Just remove the '-y' option passed to fsck.f2fs.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?id=55ee9e7202f84168f868d863da8ed1c4995a0e6d
fsck.f2fs: add -y for generic fsck
Closes!29 - Enhance F2FS support
Before this commit [1] first included in f2fs-tools 1.5.0, dump.f2fs
didn't report the total space used by the file system. This causes F2FS
file system usage not be reported on older distributions, including
RHEL/CentOS 7 and Debian 8.
On CentOS 7:
# rpm -q f2fs-tools
f2fs-tools-1.4.1-2.el7.nux.x86_64
# dump.f2fs -d 1 /dev/sdb3 | egrep 'sector size =|total.*sectors ='
Info: sector size = 512
Info: total sectors = 2097152 (in 512 bytes)
On Fedora 28:
# rpm -q f2fs-tools
f2f2-tools-1.10.0-1.fc28.x86_64
# dump.f2fs -d 1 /dev/sdb2 | egrep -a 'sector size =|total.*sectors ='
Info: sector size = 512
Info: total sectors = 3145728 (1536 MB)
Info: total FS sectors = 2621440 (1280 MB)
"total sectors" reports the size of the partition.
"total FS sectors" reports the size of the file system.
Cope with the file system size being missing. Pass -1 as the file
system size to partition.set_sector_usage() in this case. Note that
this means GParted won't be able to detect and report unallocated space
within the partition when using f2fs-tools < 1.5.0.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?id=fea6162a6db9af527648262d9fbb0335a0cc5460
fsck.f2fs: show total sectors consumed by filesystem
Closes!29 - Enhance F2FS support
On Fedora 28 with f2fs-tools 1.10.0, dump.f2fs is producing NUL
characters in it's output and this completely breaks the parsing code in
f2fs::set_used_sectors(). Glib::Regex, as used by
Utils::regexp_label(), just doesn't match any text after the first NUL
character from the output.
# dump.f2fs -d 1 /dev/sdb1
Info: Debug level = 1
Info: [/dev/sdb1] Disk Model: VBOX HARDDISK 1.0 ^@^@^@^@^@^@^@^...
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 2097152 (1024 MB)
...
Grep thinks the output is binary too:
# dump.f2fs -d 1 /dev/sdb1 | \
> egrep 'valid_block_count|user_block_count|log_blocksize|sector size =|total FS sectors ='
Binary file (standard input) matches
# dump.f2fs -d 1 /dev/sdb1 | \
> egrep --text 'valid_block_count|user_block_count|log_blocksize|sector size =|total FS sectors ='
Info: sector size = 512
log_blocksize [0x c : 12]
Info: total FS sectors = 2097152 (1024 MB)
user_block_count [0x 36400 : 222208]
valid_block_count [0x 2 : 2]
Re-write set_used_sectors() using string find() and sscanf() to be
similar to how a number of the other set_used_sectors() are written for
other file systems.
Closes!29 - Enhance F2FS support
Now that GParted requires Gtk3 there is no need to use floating point
numbers for compatibility with Gtk <= 2.22. Replace with symbolic
alignment constants.
Relevant commit history:
* 6efa623401
Add optional yalign argument to Utils::mk_label() method
* be2689ad25
Stop using deprecated widget alignment enumerators (#652044)
btrfs-progs 3.12 includes 'btrfs filesystem label /dev/PTN NEWLABEL'
functionality so stop checking for this before enabling setting the
label.
$ btrfs version
Btrfs v3.12
$ btrfs filesystem label --help
usage: btrfs filesystem label [<device>|<mount_point>] [<newlabel>]
Get or change the label of a filesystem
With one argument, get the label of filesystem on <device>.
If <newlabel> is passed, set the filesystem label on <newlabel>.
$ echo $?
0
Worst case scenario is that some how an old version of the btrfs command
is used which doesn't support the labelling functionality. Then this
commit would change GParted from disallowing labelling of a btrfs, to
allowing it, but presumably it would fail with an error from the btrfs
command reporting so. Arguably better from a support point of view.
Closes!26 - Remove support for btrfs-progs < 3.12
This commit [1] from btrfs-progs 3.12 removed the previously deprecated
programs btrfsctl and btrfs-show. As btrfs-progs 3.12 is now the
minimum requirement, remove support for those removed programs.
This commit is just removing the use of btrfs-show as a fallback to read
the label.
Note that 'btrfs-show /dev/PTN' didn't distinguish between a label of
"none" and no label. Hence the logic in btrfs::read_label() to do with
matching the label "none", or matching the label with or without single
quotes. Unfortunately as identified in this commit [2]
'btrfs filesystem show /dev/PTN' is subject to the same issue, but only
when the file system is mounted and only for btrfs-progs 3.12. This was
fixed by this commit [3] from btrfs-progs 3.14.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=f243fcd1b2aa55ffadfbcc032c66dedbee56e79e
Removing btrfsctl, btrfs-vol, btrfs-show
[2] eca732fb0c
Update parsing of btrfs filesystem show for the label (#733601)
[3] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=a156b967ed9bd606afa8dc402451abcf07226c17
btrfs-progs: make filesystem show by label work
Closes!26 - Remove support for btrfs-progs < 3.12
PATCHSET OVERVIEW
The oldest supported distributions have these versions of the Linux
kernel and btrfs-progs:
Distro EOL kernel btrfs-progs
- RHEL / CentOS 7 2024-Jun 3.10.0 4.9.1
- Ubuntu 14.04 LTS 2019-Apr 4.4.0 3.12
- Debian 8 2020-Jun 3.16.0 3.17
- SLES 12 2027-Oct 3.12.28 3.16
Making the oldest supported packages be kernel 3.10 and btrfs-progs 3.12
allows the btrfs support code to be simplified by removing backward
compatibility.
THIS CHANGE
Remove old workaround for ignoring the error when resizing a btrfs to
the same size on Linux kernel < 3.2.
Also now that only exit status 0 is considered successful from btrfs
resize, the EXEC_CHECK_STATUS flag to execute_command() can be used,
rather than having to separately call set_status() afterwards.
Relevant commit history:
* 11d044dba0
Don't ignore any errors resizing btrfs on Linux >= 3.2 (#669389)
* a580abbc30
Use newer btrfs multi-tool control command first
Closes!26 - Remove support for btrfs-progs < 3.12
The title has never been set in this case, and defaulted to the name of
the executable 'gpartedbin'. Fix this.
Closes#44 - Title not set in Resize/Move dialog for extended partitions
'launched' local POD (Plain Old Data) variable was left uninitialised,
but was set in both the try and catch clauses. Best practice is to
initialise when defined, so do that instead. Cosmetic change.
It is not creating a dialog (a pop-up window managed by GParted code
itself). It is launching independent yelp program to display the help,
so remove the "_dialog" from the name to avoid any possible confusion.
Originally, if the yelp command was not installed, attempting to display
help produced an error dialog with this message:
Failed to execute child process "yelp" (No such file or directory)
However since this commit during the Gtk 3 port [1] the error message
became this less useful one:
Operation not supported
Two attempts are made to display the GParted Manual, first using
gtk_show_uri() and second by executing the yelp command directly. Prior
to the aforementioned commit [1] both methods returned the failure
reason using the same 'error' variable. Hence reported the message
"Failed to execute child process "yelp" ..." from the second attempt.
However that commit had to re-code the second method as part of the Gtk
3 port and use a different error returning mechanism, thus the use of
different variable 'e'. But the dialog was left reporting the message
from the original 'error' variable, thus reporting "Operation not
supported" message from the first attempt using gtk_show_uri().
Fix by again displaying the message from the second failure into the
error dialog. Also make it very clear there are two error returning
variables by naming them 'error1' and 'error2_msg'.
[1] 2953778a4c
port-to-gtk3: Use Gdk::AppLaunchContext to launch yelp (#7)
Update GParted to specify the GParted Manual using the new GNOME 3 way
with the 'help:' prefix to avoid yelp reporting this error:
Document Not Found
The URI 'ghelp:gparted' does not point to a valid page.
Closes!24 - Port to GNOME 3 yelp-tools documentation infrastructure
According to the GIT history the lines were added by this commit:
8d808c0b62
gparted-0.3.6 - code recreation from Source Forge
Looking at the SVN history this commit actually fleshed out the
implementations of fat16::get_label() and fat32::get_label() and added
the commented #includes:
https://sourceforge.net/p/gparted/svn/118
Added read label support for fat16 and fat32 using mtools mlabel command
2008-02-12
Then this SVN commit moved the mtools temporary file handling code into
Utils.cc, leaving behind the commented #includes:
https://sourceforge.net/p/gparted/svn/124
Added MTools temporary file handling functions
2008-02-19
Finally this commit removed fat32.cc by merging the code with fat16.cc:
519af1a7c0
Combine duplicate code for fat16/32
So remove the left behind commented #includes from fat16.cc.
A forum user had a case where they wanted to grow their in use root,
ext4 file system. GParted supports this, but the partition was a
logical partition inside an extended partition and GParted doesn't
support resizing an extended partition while any contained logical
partitions are busy.
Example layout:
Partition File System Mount Point
/dev/sdb1 ntfs
/dev/sdb2 [busy]
/dev/sdb5 [busy] ext4 /
unallocated unallocated
So just allow extended partitions to be resized online when online
partition resizing is available via libparted.
NOTE:
The block device that the Linux kernel provides for an extended
partition just maps to the first 1 KiB of the extended partition where
the Extended Boot Record is stored, and does not include any of the
contained logical partitions. Therefore no application can care that
the extended partition is resized while a logical partition is in use
because it can't use the extended partition block device to access any
data.
The on disk layout looks like this:
# fdisk -l /dev/sdb
Disk /dev/sdb: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0007650e
Device Boot Start End Blocks Id System
/dev/sdb1 2048 1050623 524288 7 HPFS/NTFS/exFAT
/dev/sdb2 1050624 2101247 525312 5 Extended
/dev/sdb5 1052672 2101247 524288 83 Linux
# parted /dev/sdb unit s print free
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 16777216s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
63s 2047s 1985s Free Space
1 2048s 1050623s 1048576s primary ntfs
2 1050624s 2101247s 1050624s extended
5 1052672s 2101247s 1048576s logical ext4
2101248s 16777215s 14675968s Free Space
The kernel's partition sizes from /sys/block/sdb/sdb${N}/{start,size}
shows extended partition 2 has a size of only 2 sectors:
# for N in 1 2 5
> do
> echo -e "/dev/sdb${N}\tstart=`cat /sys/block/sdb/sdb${N}/start`\tsize=`cat /sys/block/sdb/sdb${N}/size`"
> done
/dev/sdb1 start=2048 size=1048576
/dev/sdb2 start=1050624 size=2
/dev/sdb5 start=1052672 size=1048576
The EBR read from the whole of extended partition 2 block device:
# hexdump -C /dev/sdb2
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 86 |................|
000001c0 06 41 83 cb 09 82 00 08 00 00 00 00 10 00 00 00 |.A..............|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400
Closes!23 - Enable online resizing of extended partitions
With the Gtk3 port the File System Support dialog has become too wide
because the legend text is no longer wrapped. Set the max-width-chars
property to specify the natural size of the widget in terms of
characters [1]. It is converted to pixels using the average character
width in the current font.
Also use PACK_EXPAND_WIDGET when adding the label to the box so that if
the dialog is resized extra space is used to increase the size of this
child widget [2].
[1] GNOME HowDoI / Labels
https://wiki.gnome.org/HowDoI/Labels
[2] Gtkmm 3.0 Enums and Flags, enum Gtk::PackOptions
"PACK_EXPAND_WIDGET Space is expanded, with extra space filled by
increasing the child widget size."
https://developer.gnome.org/gtkmm/3.0/group__gtkmmEnums.html#ga83727a1b6fed51566dfd5c8e58890dbaCloses#7 - Port to Gtk3
In Gtk2 the up and down buttons in a SpinButton were smaller leaving
space for 7 digits before scrolling the entry. In Gtk3 the up and down
buttons are much larger leaving only space for 4 digits. This occurs in
the SpinButtons in the Dialog_Base_Partition class as displayed in the
New Partition, Paste and Resize/Move dialogs.
Set width-chars property of all Gtk::SpinButtons to ensure 7 digits can
be displayed before scrolling the entry.
Closes#7 - Port to Gtk3
In Gtk3 the progress bar height is fixed and defined by the CSS theme in
use. Changing the widget allocation size does nothing, it is always
rendered the same way.
In many themes, including Adwaita, the progressbar is very, very thin.
Provide custom CSS to specify a height of 8 pixels.
The CSS source string has to be differentiated for Gtk pre and post
3.20, because Gtk 3.20 introduced some breaking changes in the way CSS
is handled.
References:
[1] Migrating from GTK+ 2.x to GTK+ 3 - Parsing of custom resources
https://developer.gnome.org/gtk3/stable/gtk-migrating-GtkStyleContext-parsing.html
[2] Gtk3 Reference Documentation - Changes in GTK+ 3.20
https://developer.gnome.org/gtk3/stable/ch32s10.html
[3] Gnome/HowDoI - Custom Style
https://wiki.gnome.org/HowDoI/CustomStyleCloses#7 - Port to Gtk3
The pulsebar looks very small and needs to be widened. The pulsebar is
packed inside the statusbar so that it displays activity text on the
left side and the pulsebar on the right side. Ideally we want the space
to be evenly divided for the textual messages and for the pulsebar
activity indicator.
For this we just have to set the 'homogeneous' property to TRUE for the
statusbar (note that GtkStatusBar inherits from GtkBox).
Also vertically align the pulsebar to the center of the statusbar. This
is achieved setting the 'valign' property to Gtk::ALIGN_CENTER for the
pulsebar widget.
Closes#7 - Port to Gtk3
There is a bug affecting Gtk+ 3.22.8 to 3.22.30 in which destroying a
GtkComboBox when it is not hidden results in this message:
Gtk-CRITICAL **: gtk_widget_is_drawable: assertion 'GTK_IS_WIDGET (widget)' failed
This happens in GParted when some dialogs are closed, for example the
Create New Partition and Create Partition Table dialogs. To work around
the issue we call Gtk::Dialog::hide() in the destructors of our dialog
classes.
The issue was fixed in Gtk 3.24.0.
* Gtk 3.22.8 was released in February 2017.
* Gtk 3.24.0 was released in September 2018.
References:
[1] Gtk Issue - GtkComboBox::private::popup_window can be NULL
https://gitlab.gnome.org/GNOME/gtk/issues/125
[2] Gtk commit - combobox: popdown() the menu during unmap()
7401794de6
[3] Gtk commit - Check for NULL priv->popup_window in
gtk_combo_box_popdown()
aa5d926c84Closes#7 - Port to Gtk3
There is a bug in Gtkmm3 when setting accelerator keys on a
Gtk::MenuItem, the accelerator keys work but are not displayed when the
menu is drawn. This happens for Gtk::MenuItems, including derived
objects, that are constructed with a non-default constructor.
All non-default constructors of Gtk::MenuItem, and subclasses, work by
creating themselves a Gtk::AccelLabel and packing it inside the menu
item. But in Gtk3 GtkMenuItem are created with a GtkAccelLabel already
packed in as a child and that accel label should be used instead.
To workaround the issue we only use the default constructor for
Gtk::MenuItem and subclasses. This is easy to do because we only have
to change the wrappers in MenuHelpers.cc.
This bug affects Gtkmm version 3.0.0 to 3.22.2 and was fixed in
Gtkmm 3.22.3.
* Gtkmm 3.0.0 was released in April 2011
* Gtkmm 3.22.3 was released in November 2018
References:
[1] Bug Report on the Gtkmm mailing list
https://mail.gnome.org/archives/gtkmm-list/2018-February/msg00006.html
[2] Commit - Gtk::MenuItem: Fix add_accel_label()
e5c8c2df67Closes#7 - Port to Gtk3
Now GParted compiles with Gtkmm3, but we get a failed assertion doing
the following:
* Select a device with more than 1 partition
* Select a partition
* Activate 'Refresh Devices' (or do any operation that causes it, like
mount/unmount etc.)
This is the failed assertion:
**
ERROR:Win_GParted.cc:1152:void GParted::Win_GParted::set_valid_operations(): assertion failed: (valid_display_partition_ptr( selected_partition_ptr ))
Aborted (core dumped)
Where is the problem?
Win_GParted::Refresh_Visual() calls TreeView_Detail::load_partitions()
to clear and refill the treeview.
The problem is in GParted::TreeView_Detail::load_partitions() at
TreeView_Detail.cc:91:
treestore_detail->clear();
This activates TreeView_Detail::on_selection_changed() which in turn
activates Win_GParted::on_partition_selected() passing an old, stale
pointer as an argument. This triggers the failed assertion.
Why does this happen with Gtk3 and not with Gtk2?
First a bit of background of GtkTreeView:
What happens to the selection in a GtkTreeView when the selected row
is removed?
With Gtk2 the selection simply becomes empty, so nothing is selected
afterwards. With Gtk3 this was changed [1] and selection moves to an
adjacent row.
gtk_tree_store_clear() removes rows one by one. While removing rows the
selection changed signal is emitted. With Gtk2 it is emitted only one
time, to indicate that selection has become empty. With Gtk3 it is
instead emitted several times, each time indicating that selection has
moved to the adjacent row.
The handler TreeView_Detail::on_selection_changed() only takes action
when the selection is not empty. So with Gtk3 it really takes action
and activates Win_GParted::on_partition_selected() with a pointer to old
data.
What's the purpose of TreeView_Detail::on_selection_changed()?
Its task is to update the selection in the drawing area above the
TreeViewDetail, the DrawingAreaVisualDisk, so that the selected
partition stays in sync on the two widgets.
Fix by blocking the signal handler during the treeview clear.
Reference:
[1] Commit - treeview: Handle the case where the cursor row gets deleted
1a2932ba29Closes#7 - Port to Gtk3
gdk_spawn_command_line_on_screen() is not present in Gtk3. The
documentation from Gtkmm 2.24 states [1]:
gdk_spawn_command_line_on_screen has been deprecated since version
2.24 and should not be used in newly-written code. This function is
being removed in 3.0. Use either g_spawn_command_line_sync(),
g_spawn_command_line_async() or GdkAppLaunchContext instead.
g_spawn_command_line_sync() and g_spawn_command_line_async() are screen
/ display agnostic, as such we would loose functionality. There is a
workaround, which involves setting the DISPLAY environment variable [2],
but it's a weak solution (and I don't know if it works on backends
other than X11).
GdkAppLaunchContext is an implementation of GIO's GAppLaunchContext that
handles launching an application in a graphical context [3]. Therefore
use GdkAppLaunchContext and GIO's GAppInfo.
GdkAppLaunchContext was introduced in Gtk2 version 2.14. The C++
wrapper Gdk::AppLaunchContext was introduced only in Gtkmm3 version 3.4
[4]. Bump the minimum required version of Gtkmm to 3.4.0 for this
requirement.
GAppInfo was introduced in GLib version 2.16. The C++ wrapper
Gio::AppInfo was introduced in Giomm version 2.16. Note that the
minimum required version for glibmm is already 2.32.
[1] GDK 2 Reference Manual, GdkScreen, gdk_spawn_on_screen()
https://developer.gnome.org/gdk2/2.24/GdkScreen.html#gdk-spawn-on-screen
[2] Migrating from GTK+ 2.x to GTK+ 3 - "Use GIO for launching applications"
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.7
[3] GDK 3 Reference Manual - "Application launching"
https://developer.gnome.org/gdk3/stable/gdk3-Application-launching.html
[4] Gtkmm 3.4 Gdk::AppLaunchContext Class Reference, Detailed Description
https://developer.gnome.org/gtkmm/3.4/classGdk_1_1AppLaunchContext.html#detailsCloses#7 - Port to Gtk3
GParted uses Gtk::TreeViewColumn::get_cell_renderers(). This is not
present in Gtkmm3. Now Gtk::TreeViewColumn inherits from
Gtk::CellLayout and we have to use Gtk::CellLayout::get_cells() instead.
GtkCellLayout was introduced in Gtk2 version 2.18 as the common
interface for containers of cell renderers.
The C++ wrapper Gtk::CellLayout was introduced in Gtkmm2 version 2.18,
but Gtk::TreeViewColumn was never made to inherit from Gtk::CellLayout
to avoid breaking the API / ABI. That change was made for Gtkmm3.
This is an excerpt from gtkmm/treeviewcolumn.h header in Gtkmm2:
// TODO: Should be deprecated, but we cannot derive from CellLayout
// without breaking API and ABI.
/** Returns a list of all the cell renderers in the column,
* in no particular order.
*
* @return A list of Gtk::CellRenderers.
*/
Glib::ListHandle<CellRenderer*> get_cell_renderers();
Replace Gtk::TreeViewColumn::get_cell_renderers() with base class
method Gtk::CellLayout::get_cells().
Reference:
[1] Commit - "Deprecate get_cell_renderers implementations"
6abc52a29dCloses#7 - Port to Gtk3
In Gtk2 widgets draw themselves in response to the expose event signal.
In Gtk3 widgets draw themselves in response to the GtkWidget::draw
signal, and the signal handler gets a Cairo context as an argument.
Convert Gtk::DrawingArea rendering code to respond to the
GtkWidget::draw signal.
This commit is specific to the drawing area in the Create new Partition
dialog and the Resize/Move dialog.
Reference:
[1] Migrating from GTK+ 2.x to GTK+ 3 - "The GtkWidget::draw signal":
https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11Closes#7 - Port to Gtk3
In Gtk2 widgets draw themselves in response to the expose event signal.
In Gtk3 widgets draw themselves in response to the GtkWidget::draw
signal, and the signal handler gets a Cairo context as an argument.
Convert Gtk::DrawingArea rendering code to respond to the
GtkWidget::draw signal.
This commit is specific to the drawing area contained in the main
application window (also called the DrawingAreaVisualDisk).
Reference:
[1] Migrating from GTK+ 2.x to GTK+ 3 - "The GtkWidget::draw signal":
https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11Closes#7 - Port to Gtk3
In Gtk2 widgets draw themselves in response to the expose event signal.
In Gtk3 widgets draw themselves in response to the GtkWidget::draw
signal, and the signal handler gets a Cairo context as an argument.
Convert Gtk::DrawingArea rendering code to respond to the
GtkWidget::draw signal.
This commit is specific to the drawing area in the Partition Info
dialog.
Reference:
[1] Migrating from GTK+ 2.x to GTK+ 3 - "The GtkWidget::draw signal":
https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11Closes#7 - Port to Gtk3
Starting from Gtkmm3 Gdk::Cursor objects cannot be constructed directly,
but instead you have to get a smart pointer to an instance by calling
the static member function Gdk::Cursor::create().
Gdk::Cursor::create() returns a Glib::RefPtr<Gdk::Cursor> object.
Gtkmm3 always uses Glib::RefPtr<Gdk::Cursor> in its interface and never
plain Gdk::Cursor.
Reference:
[1] Programming with gtkmm3, Changes in gtkmm3:
https://developer.gnome.org/gtkmm-tutorial/3.24/changes-gtkmm3.html.en
"... Gdk::Cursor are now used via Glib::RefPtr."
Closes#7 - Port to Gtk3
In Gtk3 individual headers cannot be included directly in application
code, only the header <gtk/gtk.h> can be included (with a few exceptions
for some platform specific headers).
This has always been considered good practice even for Gtk2, though was
not a hard requirement.
In Gtk3 this is enforced by preprocessor checks. Failure to do so
yields a preprocessor error and compilation fails:
"error: Only <gtk/gtk.h> can be included directly."
Change specific Gtk header includes to:
#include <gtk/gtk.h>
References:
[1] Migrating from GTK+ 2.x to GTK+ 3 - "Do not include individual headers"
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.3
[2] Commit - "Remove all traces of GDK_PIXBUF/GTK_DISABLE_SINGLE_INCLUDES"
5e29973773Closes#7 - Port to Gtk3
Now that we are compiling against Gtkmm3 there are missing declarations
of Gtkmm identifiers due to changes in Gtkmm internal header structure.
All we have to do is bring back the declarations by including the
appropriate headers where needed.
Add necessary Gtkmm header includes.
Closes#7 - Port to Gtk3
Now that we are compiling against Gtkmm3 there are missing declarations
of Glibmm identifiers due to changes in Gtkmm internal header structure.
All we have to do is bring back the declarations by including the
appropriate headers where needed.
Add necessary Glibmm header includes.
Closes#7 - Port to Gtk3
The Gtk::Widget::modify_fs() API was removed in Gtkmm3 [1] and also
there is no direct replacement. GParted uses this in one place. So
instead use the C gtk_widget_modify_fg() version that is still present
in Gtk3.
This is just a temporary change to port GParted to Gtk3. In future this
will be replaced as part of the switch from Gdk::Color to Gtk::RGBA,
since Gdk::Color was deprecated in Gtkmm 3.10 [2].
Reference:
[1] ee432e2190
commit message "... Remove the modify_*() methods, ..."
[2] Gtkmm 3.10 Gdk::Color Class Reference
https://developer.gnome.org/gtkmm/3.10/classGdk_1_1Color.html#details
Deprecated:
Use Gdk::RGBA instead.
Closes#7 - Port to Gtk3
GParted uses Gtk::Menu_Helpers::MenuList helper class to access
individual menu items. This helper class made it easy to navigate menu
items by index.
Gtk::Menu_Helpers::MenuList was removed in the switch from Gtkmm2 to
Gtkmm3 [1]. Instead, use a separate std::map<Gtk::MenuItem*> to keep
track of individual Gtk::MenuItem objects.
Reference:
[1] Gtkmm 3 commit "MenuShell: Remove items()." removed the code
c8e47b0db5Closes#7 - Port to Gtk3
Gtk::Menu_Helpers::Element class and subclasses help in Gtk::MenuItem
widgets and also automate tasks like registering keyboard accelerators
when parented to a top-level window [1][2].
Gtk::Menu_Helpers::Element class and subclasses were removed in Gtkmm3
[3]. Provide compatible implementations under the namespace
GParted::Menu_Helpers.
References:
[1] gtkmm: Gtk::Menu_Helpers Namespace Reference
https://developer.gnome.org/gtkmm/2.24/namespaceGtk_1_1Menu__Helpers.html
[2] gtkmm: Gtk::Menu_Helpers::Element Class Reference
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Menu__Helpers_1_1Element.html
[3] Gtkmm 3 commit "MenuShell: Remove items()." removed the code
c8e47b0db5Closes#7 - Port to Gtk3
During the switch from Gtk2 to Gtk3 keyname constants were renamed from
GDK_<KeyName> to GDK_KEY_<KeyName> [1]. This was done to avoid name
clashes in gobject-introspection and language bindings. The new
constant names were also backported to Gtk 2.22 [2].
Make use of the new constant names.
References:
[1] Migrating from GTK+ 2.x to GTK+ 3 - "Replace GDK_<keyname> with GDK_KEY_<keyname>"
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.6
[2] Commit - "gdk: Prefix keys with _KEY by default"
750c81f43dCloses#7 - Port to Gtk3
Originally in Gtk2, by default, dialogs showed a horizontal separator
between the content area and the action area (buttons). GParted
explicitly called Gtk::Dialog::set_has_separator(false) for all it's
dialogs to remove the separator.
In Gtk2/Gtkmm2 2.22, separators were deprecated [1]. In Gtk3/Gtkmm3
separators in dialogs were removed altogether, including all the related
APIs [2][3][4]. Therefore remove all calls.
References:
[1] Commit - "Document separator-related api in GtkDialog as deprecated"
6f6650e6cf
[2] Commit - "Remove separators from dialogs"
d433a60611
[3] GTK+ 3.0.0 NEWS file
https://gitlab.gnome.org/GNOME/gtk/blob/3.0.0/NEWS#L779
"
Overview of Changed from GTK+ 2.90.6 to 2.90.7
==============================================
* Various deprecated APIs have been removed:
...
- GtkDialog separators, including the GtkDialog::has-separator
property, including setter/getter, the GTK_DIALOG_NO_SEPARATOR
flag and the GtkMessageDialog::use-separator style property
"
[4] Gtkmm 3.0.0 NEWS file
https://gitlab.gnome.org/GNOME/gtkmm/blob/3.0.0/NEWS#406
"
* Dialog:
- Remove get/set_has_separator() and property.
- Constructors: Remove use_separator parameters.
"
Closes#7 - Port to Gtk3
Use of Glib::thread_init() was deprecated in glibmm 2.32 [1]. The
oldest supported distributions have these versions:
Debian 8 glibmm 2.42.0
RHEL / CentOS 7 glibmm 2.56.0
SLES 12 glibmm 2.38.1
Ubuntu 14.04 LTS glibmm 2.39.93
Checking further the glibmm 2.32 reference manual says this about
Glib::thread_init() [2]:
Initializes the GLib thread system.
Deprecated:
Calling thread_init() is no longer necessary and no longer has any
effect.
However only some of the glibmm example programs had Glib::thread_init()
removed, others had it replaced by Glib::init() [3]. Again the glibmm
2.32 reference manual says this about Glib::init() [4]:
Initialize glibmm.
You may call this more than once. You do not need to call this if
you are using Glib::MainLoop or Gtk::Main, because they call it for
you.
GParted does call Gtk::Main and test_PipeCapture does call
Glib::MainLoop. Therefore just raise the minimum version to glibmm 2.32
and remove both calls to Glib::thread_init().
[1] Glibmm 2.32 NEWS file
https://gitlab.gnome.org/GNOME/glibmm/blob/2.32.0/NEWS#L207
[2] glibmm 2.32, glibmm: Glib Namespace Reference, Glib::thread_init()
https://developer.gnome.org/glibmm/2.32/namespaceGlib.html#ab26d01c776801f1fff00753e97af4fc7
[3] glibmm commit "Avoid use of deprecates API in tests and examples."
3e0fbb22c0
[4] glibmm 2.32, glibmm: Glib Namespace Reference, Glib::init()
https://developer.gnome.org/glibmm/2.32/namespaceGlib.html#ac90aee10d0b90e3d8a96a86b5394f87bCloses!22 - Increase minimums to libparted 2.2 and glibmm 2.32
Raise the minimum required version of GNU Parted from 1.7.1 to 2.2,
released 2010-02-16 [1][2]. The oldest supported distributions, also
with gtkmm >= 2.24, since commit [3], are:
Debian 8 parted 3.2
RHEL / CentOS 7 parted 3.1
SLES 12 parted 3.1
Ubuntu 14.04 LTS parted 2.3
Raising the minimum required version allows removal of optional code
associated with these definitions:
* USE_LIBPARTED_LARGE_SECTOR_SUPPORT
Fallback code reporting ignored device with logical sector size
other than 512 bytes.
* ENABLE_PT_REREAD_WORKAROUND
Fallback code re-attempting to inform the kernel of partition
changes.
[1] GNU Parted 2.2 release announcement
http://lists.gnu.org/archive/html/info-gnu/2010-02/msg00016.html
[2] NEWS file from GNU Parted 2.2
http://git.savannah.gnu.org/cgit/parted.git/tree/NEWS?h=v2.2
[3] 8b42bab1ee
modern-gtk2: Require Gtkmm version 2.24 (!17)
Closes!22 - Increase minimums to libparted 2.2 and glibmm 2.32
Mike Fleetwood