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
The code inconsistently uses GParted:: scope in front of STAT_*.
$ fgrep 'GParted::STAT_' src/*.cc | wc -l
3
$ egrep '[^:]STAT_' src/*.cc | wc -l
41
GParted:: scope resolution is unnecessary as all the code is inside the
GParted scope, except for main(). So remove it.
Closes!20 - Minor namespace and scope operator tidy-ups
The code inconsistently uses GParted:: scope in front of TYPE_*.
$ fgrep 'GParted::TYPE_' src/*.cc | wc -l
35
$ egrep '[^:]TYPE_' src/*.cc | wc -l
83
GParted:: scope resolution is unnecessary as all the code is inside the
GParted scope, except for main(). So remove it.
Closes!20 - Minor namespace and scope operator tidy-ups
The code inconsistently uses GParted:: scope in front of FS_*.
$ fgrep 'GParted::FS_' src/*.cc | wc -l
41
$ egrep '[^:]FS_' src/*.cc | wc -l
441
GParted:: scope resolution is unnecessary as all the code is inside the
GParted namespace, except for main(). So remove it.
Closes!20 - Minor namespace and scope operator tidy-ups
The code inconsistency uses GParted::FS::* and FS::*.
$ fgrep 'GParted::FS::' src/*.cc | wc -l
97
$ egrep '[^:]FS::' src/*.cc | wc -l
152
GParted:: scope resolution is unnecessary as all the code is inside the
GParted namespace, except for main(). So remove it.
Closes!20 - Minor namespace and scope operator tidy-ups
All the other modules are in the GParted namespace, except for main()
which has to be in the global namespace, so put these in the GParted
namespace too.
Closes!20 - Minor namespace and scope operator tidy-ups
Create an active Linux Software RAID member which is larger than /dev
virtual file system and GParted will report the usage figure of the /dev
virtual file system for the SWRAID member.
# df -h /dev
Filesystem Size Used Avail Use% Mounted on
devtmpfs 732M 0 732M 0% /dev
# sgdisk -n 1:1M:+1G /dev/sdb
# mdadm --create --verbose /dev/md1 --level=linear --raid-devices=1 --force /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
GParted reports the usage of /dev/sdb1 as:
Partition Mount Point Size Used Unused Unallocated
/dev/sdb1 /dev/md1 1.00GiB 0.00B 731.04MiB 292.96MiB
However GParted should have reported the usage as "---" for unknown
because it isn't coded to query the size of the SWRAID member within a
partition.
The fault has been bisected to this commit:
Extend un/mounting and usage reporting to unsupported file systems (!13)
95903efb1f
What happens for busy Linux Software RAID array members:
* GParted_Core::is_busy()
has custom code to identify busy members.
* GParted_Core::set_mountpoints()
has custom code to add the array device name as the "mount point" of
the member.
* GParted_Core::set_used_sectors()
falls into the else not a supported file system (because SWRAID
doesn't have a derived FileSystem implementation class).
* GParted_Core::mounted_set_used_sectors()
is called to get the file system usage of mounted, but unsupported
file systems, such as UFS and any others.
* Utils::get_mounted_filesystem_usage()
is called which queries the kernel using statvfs() and gets the file
system usage of the /dev virtual file system because the array
device name will always start /dev.
Fix by ensuring that GParted only asks the kernel for the usage of paths
which it knows are mount points of mounted file systems. (As read from
/proc/mounts and cached in the Mount_Info module). Also rename the
method, by inserting "_fs", to mounted_fs_set_used_sectors() to remind
us that it is for mounted *file systems* only.
Closes#27 - GParted may report incorrect usage for SWRAID partitions
instead of unknown
S
Third commit in a series to convert Gdk::GC based drawing to Cairo based
drawing. This specific commit makes the transition for the graphical
partition visualizer widget that is used in the main application window.
Closed!17 - Gtk2 modernisation
Second commit in a series to convert Gdk::GC based drawing to Cairo
based drawing. This specific commit makes the transition for the
graphical partition info widget that is used in the "Information about"
dialog.
Closes!17 - Gtk2 modernisation
C++ initialises static member variables before main() is called.
Therefore the static members of:
struct Slots
{
static Gtk::TreeModelColumn<Glib::ustring> text;
static Gtk::TreeModelColumn<bool> sensitive;
private:
static Gtk::TreeModel::ColumnRecord record_;
};
are constructed before Gtk::Main() is called in main(). However the
Gtkmm documentation specifically says that they must be constructed
afterwards [1].
Resolve this by using the Construct On First Use Idiom [2] to delay
initialisation until the slots are first used. Normally this idiom uses
static local objects, however it is being applied to class static
objects here because the objects are accessed in many methods. The
downside of this approach is that the objects are never destructed,
which memory analysers like Valgrind could see as a memory leak, but
that is actually deliberate. That leak can be removed once we can use
C++11 and std::unique_ptr.
[1] gtkmm: Gtk::TreeModelColumnRecord Class Reference
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1TreeModelColumnRecord.html#details
"Neither TreeModel::ColumnRecord nor the TreeModelColumns contain
any real data - they merely describe what C++ type is stored in
which column of a TreeModel, and save you from having to repeat that
type information in several places.
Thus TreeModel::ColumnRecord can be made a singleton (as long as you
make sure it's instantiated after Gtk::Main), even when creating
multiple models from it.
"
[2] C++ FAQ / How do I prevent the "static initialization order
problem"?
https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-useCloses!17 - Gtk2 modernisation
Final part in a series of commits to replace Gtk::OptionMenu widgets
with GParted::OptionComboBox.
This specific commit renames the signal handler callback to match the
previously renamed combobox widget variable names.
Closes!17 - Gtk2 modernisation
Third part in a series of commits to replace Gtk::OptionMenu widgets
with GParted::OptionComboBox.
This specific commit is about file system combobox.
Closes!17 - Gtk2 modernisation
Second part in a series of commits to replace Gtk::OptionMenu widgets
with GParted::OptionComboBox.
This specific commit is about partition type combobox.
Closes!17 - Gtk2 modernisation
First part in a series of commits to replace Gtk::OptionMenu widgets
with GParted::OptionComboBox.
This specific commit is about partition alignment combobox.
Closes!17 - Gtk2 modernisation
The shades of aquamarine, cyan and orange didn't fit with the GNOME
32-colour palette. Create a set of aquamarine, cyan and orange shades
which match the GNOME palette shades and update the colours of the
relevant file systems accordingly.
Aquamarine Hilight (#97DFC7) -
Aquamarine Medium (#70D2B1) - NTFS
Aquamarine Dark (#3EA281) - REFS
Aquamarine Shadow (#1F7258) -
Cyan Hilight (#95E3E5) - EXTENDED
Cyan Medium (#6FCECE) -
Cyan Dark (#3C9899) -
Cyan Shadow (#166F70) -
Orange Hilight (#E59F6A) -
Orange Medium (#E58749) - BTRFS
Orange Dark (#C26825) - ZFS
Orange Shadow (#984F18) -
Note that the hues of aquamarine and cyan are quite close and for the
thin outlines of partitions used in GParted they aren't easy to
distinguish. Hence also using different lightness to additionally
separate the colour for extended partitions from NTFS and ReFS file
systems.
Just add detection of APFS using GParted's internal magic string
detection. It just matches 1 byte of the 2 byte object type and the
4 byte magic field found in the super block [1]. See code comment for
more details.
Blkid has just gained recognition of APFS with util-linux v2.33 released
06-Nov-2018 [2].
This will write enough for GParted's simple internal detection to find
APFS:
# python -c '
import sys
sys.stdout.write("\0"*24 + "\1\0" + "\0"*6 + "NXSB")
' > /dev/sdb1
[1] Apple File System Reference
https://developer.apple.com/support/apple-file-system/Apple-File-System-Reference.pdf
[2] [ANNOUNCE] util-linux v2.33
https://marc.info/?l=linux-fsdevel&m=154150400305928&w=2Closes#23 - GParted doesn't detect APFS (Apple File System)
Currently Linux Swap, Linux Suspend, and HFS use reds from the GNOME
32-colour palette with HFS Plus using serene red outside that palette.
HFSPLUS - Serene Red
HFS - Red Hilight
LINUX_SWAP - Red Medium
LINUX_SUSPEND - Red Dark
- Red Shadow
Apple have a new file system, APFS (Apple File System), which is a
successor to HFS Plus [1][2]. With HFS Plus using a colour outside the
GNOME 32-colour palette and there not being enough distinct reds
available for a new file system, create a new range of magenta colours
which fit with the GNOME palette and use them for the group of Apple
file systems.
Magenta Hilight (#D59FD4) - HFS
Magenta Medium (#B173B0) - HFSPLUS
Magenta Dark (#874986) - APFS
Magenta Shadow (#662C64) -
This commit just moves HFS and HFS Plus to their new magenta colours.
[1] About Apple File System
https://developer.apple.com/documentation/foundation/file_system/about_apple_file_system
"Overview
Apple File System replaces HFS Plus as the default file system for
iOS 10.3 and later, and for macOS High Sierra and later. Apple File
System offers improved file system fundamentals as well as several
new features, including cloning, snapshots, space sharing, fast
directory sizing, atomic safe-save, and sparse files.
"
[2] Apple File System Reference
https://developer.apple.com/support/apple-file-system/Apple-File-System-Reference.pdf
"About Apple File System
Apple File System is the default file format used on Apple
platforms. Apple File System is the successor to HFS Plus, so some
aspects of its design intentionally follow HFS Plus to enable data
migration from HFS Plus to Apple File System. Other aspects of its
design address limitations with HFS Plus and enable features such as
cloning files, snapshots, encryption, and sharing free space between
volumes.
"
Closes#23 - GParted doesn't detect APFS (Apple File system)
No other file system allows this, but btrfs allows simultaneous mounting
with different read-write permission. Further, btrfs allows resizing
via read-write mounts, but not via read-only mounts.
# mkfs.btrfs /dev/sdb1
btrfs-progs v4.15.1
...
Filesystem size: 512.00MiB
...
Number of devices: 1
Devices:
ID SIZE PATH
1 512.00MiB /dev/sdb1
# mount -o ro /dev/sdb1 /mnt/1
# mount -o rw /dev/sdb1 /mnt/2
# grep sdb1 /proc/mounts
/dev/sdb1 /mnt/1 btrfs ro,relatime,space_cache,subvolid=5,subvol=/ 0 0
/dev/sdb1 /mnt/2 btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
# btrfs filesystem resize 1:500M /mnt/1
Resize '/mnt/1' of '1:500M'
ERROR: unable to resize '/mnt/1': Read-only file system
# echo $?
1
# btrfs file system resize 1:500M /mnt/2
Resize '/mnt/2' of '1:500M'
# echo $?
0
# btrfs filesystem show /dev/sdb1
Label: none uuid: 74ccd37a-e665-4f25-b77e-a305b8a025e9
Total devices 1 FS bytes used 128.00KiB
devid 1 size 500.00MiB used 88.00MiB path /dev/sdb1
Also with the above order of the read-only mount listed in /proc/mounts
first and the read-write mount second, GParted again allows a resize
operational to be tried, but if fails just like before:
Grow /dev/sdb1 from 512.00 MiB to 1.0 GiB (ERROR)
* calibrate /dev/sdb1 (SUCCESS)
* grow partition from 512.00 MiB to 1.00 GiB (SUCCESS)
* grow filesystem to fill the partition (ERROR)
* btrfs filesystem resize 1:max '/mnt/1' (ERROR)
Resize '/mnt/1 to '1:max'
ERROR: unable to resize '/mnt/1': Read-only file system
What happened is that the Mount_Info module only stores single read-only
flag against the mounted block device, not for each mount point, and as
the first and second sdb1 lines from /proc/mounts were processed, the
MountEntry became:
1st) mount_info[BS("/dev/sdb1")] -> {true , ["/mnt/1"]
2nd) mount_info[BS("/dev/sdb1")] -> {false, ["/mnt/1", "/mnt/2"]
So GParted thought the file system was mounted read-write, but used the
first mount point, /mnt/1, which was mounted read-only.
This is a very unusual situation so unlikely to be encountered by users.
Fix simply and safely by treating the mounted block device as mounted
read-only if any of the mount points are mounted read-only, rather than
just the last processed mount point.
Closes#10 - Gparted fails to resize btrfs partition that is mounted
read-only
Resizing a file system mounted read-only fails. Example:
# mkfs.btrfs /dev/sdb1
# mount -o ro /dev/sdb1 /mnt/1
In GParted try to resize partition sdb1. The operation fails like this:
Grow /dev/sdb1 from 512.00 MiB to 1.00 GiB (ERROR)
* calibrate /dev/sdb1 (SUCCESS)
* grow partition from 512.00 MiB to 1.00 GiB (SUCCESS)
* grow filesystem to fill the partition (ERROR)
* btrfs filesystem resize 1:max '/mnt/1' (ERROR)
Resize '/mnt/1' of '1:max'
ERROR: unable to resize '/mnt/1': Read-only file system
See GitLab issue for the testing results of attempting to online resize
all supporting file system while mounted read-only. No file system
allows online resizing while mounted read-only, except for reiserfs.
Issue #10 - Gparted fails to resize btrfs partition that is mounted
read-only
https://gitlab.gnome.org/GNOME/gparted/issues/10
Fix by preventing online resizing of *all* file systems mounted
read-only, including reiserfs. Instead of displaying the resize dialog
in this case, display an information dialog explaining why the partition
can't be resized. This is similar to what happens when attempting to
create a new partition on a disk without a partition table. The new
dialog looks like:
(!) Unable to resize read-only file system /dev/sdb1
The file system can not be resized while it is mounted read-only.
Either unmount the file system or remount it read-write.
[ OK ]
Closes#10 - Gparted fails to resize btrfs partition that is mounted
read-only
Set the partition read-only mount flag at the same time as setting the
file system mount points.
Closes#10 - Gparted fails to resize btrfs partition that is mounted
read-only
Parse file system mount options string from file and mount command
output, extracting the setting for the read-only flag and storing in the
mount maps. Read-only flag for swap space gets the struct MountEntry
constructor default of false.
Closes#10 - Gparted fails to resize btrfs partition that is mounted
read-only
Just updates the 2 maps in the Mount_Info module so that they also have
a read-only flag for each mount. Ensure that when a struct MountEntry
is created the readonly bool POD (Plain Old Data) type is initialised by
the constructor. Nothing yet sets or uses the flag.
Closes#10 - Gparted fails to resize btrfs partition that is mounted
read-only
Back when unallocated space handling was being added, this case was not
converted from open coding to using the provided method to check for
unknown file system usage. Specifically this commit missed using
Partition::sector_usage_known() in
Dialog_Base_Partition::prepare_new_partition():
7ebedc4bb3
Don't show intrinsic unallocated space (#499202)
Fix it now.
The function was using std::map::count() [1] to test if the file system
entry existed in the map before looking up the value using
std::map::operator[] to avoid having operator[] inserting elements which
don't exist [2].
Rewrite using std::map::find() [3] so that map is only searched once,
and so that it is more obvious what is happening without having to know
the subtleties of std::map::count() and ::operator[].
[1] std::map::count()
http://www.cplusplus.com/reference/map/map/count/
"Searches the container for elements with a key equivalent to k and
returns the number of matches.
Because all elements in a map container are unique, the function can
only return 1 (if the element is found) or zero (otherwise).
"
[2] std::map::operator[]
http://www.cplusplus.com/reference/map/map/operator[]/
"If k does not match the key of any element in the container, the
function inserts a new element with that key and returns a reference
to its mapped value. Notice that this always increases the
container size by one, even if no mapped value is assigned to the
element (the element is constructed using its default constructor).
"
[3] std::map::find
http://www.cplusplus.com/reference/map/map/find/
"Searches the container for an element with a key equivalent to k
and returns an iterator to it if found, otherwise it returns an
iterator to map::end.
"
There is no prospect of there being ufs-tools on Linux. The was a
project which did release ufs-tools version 0.1 in 2004, but has been
inactive since then.
http://ufs-linux.sourceforge.net/
Copying and moving is now implemented for file systems in the basic
supported category. Also mounting and unmounting of unsupported file
system and reporting their usage while mounted has been added. This is
all the support that GParted has ever implemented for UFS. Therefore
re-assign UFS as a basic supported file system as it looses no
functionality.
Closes!13 - Support copying and moving of unsupported partition content
For unsupported (including basic supported) file systems, also record
the mount point(s) when mounted and from /etc/fstab when not. This
allows mounted unsupported file systems to be unmounted and ones with
/etc/fstab entries to be mounted, just like fully supported file
systems.
Also for unsupported (again including basic supported) mounted file
systems query the kernel for the usage, just like is already done for
supported file systems.
Closes!13 - Support copying and moving of unsupported partition content
When previewing copying a partition of unknown file system usage into an
existing partition, the usage still shows that of the overwritten file
system. This affects existing supported file systems EXFAT, F2FS, MINIX
and UFS and the new basic supported one too, all for which GParted can't
read the file system usage.
Handle the case of the source file system usage being unknown and
explicitly set the copied usage to unknown too.
Closes!13 - Support copying and moving of unsupported partition content
GParted previews copying a partition of unknown file system usage into a
new partition as 100% used. This affects existing supported file
systems EXFAT, F2FS, MINIX and UFS and the new basic supported ones too,
all for which GParted can't read the file system usage.
When preparing the working new_partition object in the Copy / Paste
dialog, the maths for the known file system usage happened to convert
the figures of used = -1 and unused = -1 into set_sector_usage(-1, 0).
Those values passed to set_sector_usage() mean unable to query the file
system size so assume it fills the partition and unused is 0, hence 100%
used.
Fix this by specifically handling the copying of file systems with
unknown usage, setting the pasted file system usage to unknown too,
used = -1 and unused = -1.
Closes!13 - Support copying and moving of unsupported partition content
To display the supported actions for all basic supported file systems to
the users.
Prepare the list of file system actions in Win_GParted because calling
get_fs() for the "other" actions requires the gparted_core object and
load_filesystems() currently doesn't have access to it. One alternative
would have been to make get_fs() and FILESYSTEMS static members of
GParted_Core class. Another alternative would have been to pass the
gparted_core object to load_filesystems(). The chosen way seemed
simplest.
Closes!13 - Support copying and moving of unsupported partition content
Want a single term under which the supported actions for all basic
supported file systems are displayed in the File System Support dialog.
"Unknown" isn't the correct adjective because the group includes
unknown, but also includes: BitLocker, GRUB2 core image, ISO9660, Linux
SWRaid, Linux Suspend, REFS and ZFS. Add "other" file system type just
for displaying in the dialog.
Closes!13 - Support copying and moving of unsupported partition content
Introduce a third category of basic file system support to go along with
the existing full and none. Use the file system's entry in
FILESYSTEM_MAP to determine the level of support. See comment in
GParted_Core::init_filesystems() for details.
Add and remove FILESYSTEM_MAP NULL pointer entries as required, so that
only the file system types intended to have basic support have such
entries.
Closes!13 - Support copying and moving of unsupported partition content
PATCHSET OVERVIEW:
Forum user wanted to be able to move a partition with unknown content:
Topic: Can't move/rezise partition on android device (unknown format)
http://gparted-forum.surf4.info/viewtopic.php?id=17742
While GParted isn't going to be able to run any sort of file system
check on the unknown content there isn't any reason why such a partition
can't be copied or moved so long as the partition stays the same size.
GParted can just use it's existing internal block copy routine it uses
for copying and moving most partition content. This is no different to
a few of the already supported file system types which don't have a
check-repair tool: exfat, f2fs, nilfs2, udf, ufs.
This patchset introduces a third category called basic file system
support to go along with the existing full and unsupported categories.
Basic supported file systems will just use GParted's inbuilt
capabilities to perform actions so they won't need a derived FileSystem
implementation class. Unknown file systems along with all other
recognised, but otherwise unsupported, file systems will be assigned to
this new basic supported category.
THIS PATCH:
FS_UNKNOWN is used when GParted is unable to identify the contents of a
partition. FS_UNKNOWN is also used to generate a file system support
set with no supported actions, in the FileSystem::FS::FS() constructor
and in GParted_Core::get_fs().
As support for operations on partitions with unknown content is being
added, the second usage will be confusing or even wrong.
FS( FS_UNKNOWN ) constructs the no supported actions set, yet GParted
will support some actions for the FS_UNKNOWN file system type.
Therefore add FS_UNSUPPORTED for the second usage.
Closes!13 - Support copying and moving of unsupported partition content
No functional change. The code layout is old and a mess, not lining up
vertically. Use more common code layout and spaces to align text
vertically. List cases in enumeration order. Identify each colour
choice as either in the GNOME palette (no marking), an extended shade to
a colour in the GNOME palette [+], or a colour outside the GNOME palette
[*].
There's lots of other switch statements just in Utils.cc which could do
with tidying up, but this is the one I am looking at now.
FAT16 was a fully saturated green (RGB #00FF00) and FAT32 was a little
darker. These are out of character with the colours from the GNOME
palette for other file systems. Change the colours to use near
alternative Accent Greens from the GNOME colour palette. So now we have
the following file system colours, from light to dark:
FAT16 - Accent Green Hilight
FAT32 - Accent Green
EXFAT - Accent Green Dark
UDF - Accent Green Shadow
Strictly speaking only Accent Green and Accent Green Dark are part of
the GNOME palette. Accent Green Hilight and Accent Green Shadow are
extensions expanding the range of Accent Greens.
GNOME Human Interface Design 2.2.1 / Visual Design / colour /
https://developer.gnome.org/hig-book/2.32/design-color.html.en
"Guidelines
* Use the GNOME color palette. If you need a darker or lighter
shade, start from one of the colors from the palette and darken or
lighten as needed.
"
Util-linux package, at least as far back as version 2.23.2 as found on
CentOS 7, provides the mkfs.minix and fsck.minix commands. Also blkid
from the same package, recognises minix file systems.
Create version 3 file systems because MINIX 3 [1] is the only supported
version and that reportedly uses version 3 of the file system [2].
[1] MINIX 3 / History
https://en.wikipedia.org/wiki/MINIX_3#History
[2] Regarding MINIX 3 file system
https://groups.google.com/forum/#!topic/minix3/3-TeHR_23X8
"MINIX 3 uses Minix File System (MFS). More precisely MFS V3."
Closes!12 - Add minix file system support
I see the MINIX file system as a kind of forerunner to EXT* because of
it's history [1]. No body uses the original EXT file system any more,
however the MINIX file system is still used by the MINIX 3 operating
system. So use the same range of colours for MINIX and EXT2/3/4. Use
one shade darker blue for EXT2/3/4, allowing MINIX to use the lightest
blue. After adding MINIX support in the next patch, the colours will
become:
MINIX - Blue Hilight
EXT2 - Blue Medium
EXT3 - Blue Dark
EXT4 - Blue Shadow
[1] MINIX file system / History
https://en.wikipedia.org/wiki/MINIX_file_system#History
"When Linus Torvalds first started writing his Linux operating
system kernel (1991), he was working on a machine running MINIX, and
adopted its file system layout. This soon proved problematic, since
MINIX restricted filename lengths to fourteen characters (thirty in
later versions), it limited partitions to 64 megabytes, and the file
system was designed for teaching purposes, not performance. The
Extended file system (ext; April 1992) was developed to replace
MINIX's, but it was only with the second version of this, ext2, that
Linux obtained a commercial-grade file system. As of 1994, the
MINIX file system was "scarcely in use" among Linux users.
"
Closes!12 - Add minix file system support
If an EXT2/3/4 file system needs checking, then resize2fs will report an
error, rather than report the minimum file system size.
# mkfs.ext4 /dev/sdb11
# resize2fs -P /dev/sdb11
resize2fs 1.42.9 (28-Dec-2013)
Estimated minimum size of the filesystem: 17012
# debugfs -w -R "ssv state 0" /dev/sdb11
# resize2fs -P /dev/sdb11
resize2fs 1.42.9 (28-Dec-2013)
Please run 'e2fsck -f /dev/sdb11' first.
# echo $?
1
This will prevent GParted reading the file system usage and in turn
GParted won't allow the file system to be shrunk. Re-add the previous
method of reading the free space from dumpe2fs output as a fallback.
With this change, the worst case scenario is that GParted allows the
user to attempt to shrink an unclean EXT4 file system, smaller that that
which resize2fs allows and gets an error telling them so. As part of
the failed shrink operation GParted will have checked the file system so
on refresh GParted will get the correct minimum size next time.
This scenario only seems to apply to unclean EXT4 file systems because
resize2fs has a larger minimum size that the free blocks would suggest
because of extra space requirements when resizing EXT4 file systems [1].
[1] e2fsprogs 1.44.3, resize/resize2fs.c:calculate_minimum_resize_size()
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/resize/resize2fs.c?h=v1.44.3#n2946
/*
* For ext4 we need to allow for up to a flex_bg worth of
* inode tables of slack space so the resize operation can be
* guaranteed to finish.
*/
/*
* We need to reserve a few extra blocks if extents are
* enabled, in case we need to grow the extent tree. The more
* we shrink the file system, the more space we need.
*
* The absolute worst case is every single data block is in
* the part of the file system that needs to be evacuated,
* with each data block needs to be in its own extent, and
* with each inode needing at least one extent block.
*/
Closes#8 - Shrinking an EXT4 partition does not respect resize2fs
limits
A user reported GParted failed to shrink an EXT4 file system because
GParted tried to shrink it smaller than resize2fs reported minimum size.
Operation details were:
Shrink /dev/sdc1 from 931.51 GiB to 605.00 GiB (ERROR)
calibrate /dev/sdc1 (SUCCESS)
path: /dev/sdc1 (partition)
start: 63
end: 1953520064
size: 1953520002 (931.51 GiB)
check file system on /dev/sdc1 for errors and (if poss...(SUCCESS)
e2fsck -f -y -v -C 0 '/dev/sdc1' (SUCCESS)
...
158165624 blocks are used (64.77% of 244190000)
...
shrink file system (ERROR)
resize2fs -p '/dev/sdc1' 634389176K (ERROR)
resize2fs 1.44.2 (14-May-2018)
resize2fs: New size smaller than minimum (171882113)
The GParted figures:
* Partition size = 1953520064 (512b sectors) = 976760032 KiB
* FS size = 244190000 (4K blocks) = 976760000 KiB
* Used FS size = 158165624 (4K blocks) = 632662496 KiB
* Requested FS size = 634389176 KiB
The resize2fs figure:
* Minimum FS size = 171882113 (4K blocks) = 687528452 KiB
GParted uses the number of free blocks in the file system to determine
the minimum size it can shrink a file system to. However resize2fs uses
it's own internally calculated minimum size and won't shrink a file
system below that size, as seen in the above details. Resize2fs does
have a force flag, (-f) which overrides some safety checks which are
normally enforced, to allow it to try to shrink a file system smaller
than it's calculated minimum. GParted currently doesn't use the force
flag and it seems unwise for it to start to do so.
So for unmounted EXT2/3/4 file systems, change GParted to use
'resize2fs -P' to get the minimum file system size, rather than using
the number of free blocks direct from the super block, as reported by
'dumpe2fs -h'.
Mounted file systems still use statvfs() to provide file system usage.
As mounted EXT2/3/4 file systems can't be shrunk the fact that statvfs()
produces different, possibly smaller than minimum, figures than those
from 'resize2fs -P' doesn't matter.
Closes#8 - Shrinking an EXT4 partition does not respect resize2fs
limits
No functional change. Just work in FS block sized units until as late
as possible in ext2::set_used_sectors(), before converting to device
sector size units. This is to make the following change simpler and
easier to understand.
Closes#8 - Shrinking an EXT4 partition does not respect resize2fs
limits
This is functionally identical, but is just to follow established coding
pattern [1] of specifying the FSType when constructing struct FS, rather
and setting it afterwards. luks.cc was added after the aforementioned
commit, but was being developed in parallel so was created [2] following
the old coding pattern.
[1] 1a4cefb960
Initialise all struct FS members
[2] 070d734e57
Add busy detection of LUKS mapping (#760080)
Shrinking an LVM2 Physical Volume on CentOS 7 with the latest
lvm2 2.02.177 fails like this:
Shrink /dev/sda9 from 1.00 GiB to 768.00 MiB
* calibrate /dev/sda9
* check file system on /dev/sda9 for errors and (if possib...(SUCCESS)
* shrink file system (ERROR)
* lvm pvresize -v --setphysicalvolumesize 786432K '/dev/...(ERROR)
0 physical volume(s) resized / 1 physical volume(s) not resized
Wiping internal VG cache
Wiping cache of LVM-capable devices
/dev/sda9: Requested size 712.00 MiB is less than real size 1.00 GiB. Proceed? [y/n]:[n]
Physical Volume /dev/sda9 not resized.
This upstream change to lvm2 [1] makes pvresize prompt for confirmation
whenever the --setphysicalvolumesize option is used. (The change was
included in lvm2 2.02.171 and later, which is used in recent
distributions. The reporter found the issue on Ubuntu 18.04 LTS and I
reproduced the issue on RHEL/CentOS 7.5). The set size option has to be
used when shrinking the PV before shrinking the partition therefore fix
this issue by adding lvm common option --yes when using the set size
option.
[1] https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=cbc69f8c693edf0d1307c9447e2e66d07a04bfe9
pvresize: Prompt when non-default size supplied.
Closes#1 - Can't shrink LVM partition due to pvresize prompt
After a failed LUKS unlock attempt the password entry dialog shows the
error "Failed to open LUKS encryption". Improve the user experience by
clearing that error message at the start of the next attempt to avoid
contradictory information with the main windows status of "Opening
encryption on $PARTITION" whilst performing the next unlock attempt.
Bug 795617 - Implement opening and closing of LUKS mappings
When the wrong LUKS password is entered and the [Unlock] button clicked,
the wrong password is left in the entry box and focus remains on the
[Unlocked] button. Improve the user experience by selecting
(highlighting) the whole of the wrong password ready for deletion or
retyping and ensuring that the entry box always has focus.
Just for completeness also programmatically make the password entry box
have focus when the dialog box is created and first displayed, even
though it gets this by default.
Bug 795617 - Implement opening and closing of LUKS mappings
We previously migrated our web site from http://gparted.org to
https://gparted.org under:
bug 786707 - gparted.org does not use HTTPS
and updated URLs in the GParted Manual to match in commit:
a8172ecb04
Convert Manual links to HTTPS where possible and update version
Now update the URLs displayed in the GParted application too.
Bug 796411 - Enhancements request - URL links
The Change_UUID_Warning vectors were fat16 and ntfs class member
variables, but are only ever accessed in the get_custom_text() method.
Make them local variables in get_custom_text() instead. Static so that
references to them can be returned.
I completely missed that when reading XFS file system size and usage it
was using the '-r' read-only flag to xfs_db because it was at the end of
the string on the following line of code. Move it to the start of the
xfs_db command line, like it is when reading the file system label.
Same case as for FileSystem Label dialog before; the Partition Name
dialog only has a single line of just 2 widgets. Therefore switch to a
simpler horizontal box widget to lay them out.
The FileSystem Label dialog only has a single line of just 2 widgets; a
text label and entry box widget. There is no need to use a multi-line
capable table to hold this. Switch to a simpler horizontal box widget.
Note that this change is not related to porting to Gtk 3 and stopping
using deprecated APIs because both HBox [1] and Table [2] are deprecated
in Gtk 3.2 and Gtk 3.4 and replaced by Box with horizontal orientation
and Grid respectively.
[1] NEWS file from gtkmm 3.2, actually first released in gtkmm 3.1.6
(unstable):
https://git.gnome.org/browse/gtkmm/tree/NEWS?h=3.2.0#n91
"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."
[2] NEWS file from gtkmm 3.4, actually first released in gtkmm 3.3.2
(unstable):
https://git.gnome.org/browse/gtkmm/tree/NEWS?h=3.4.0#n162
"* Deprecate Gtk::Table in favour of Gtk::Grid."
Replace return by value of const strings from
FileSystem::get_custom_text() and get_generic_text() because that
implies duplication of those strings. Return a reference to constant
strings instead.
Compiling (with new enough g++) produces this warning:
PasswordRAMStore.cc: In member function 'void GParted::PWStore::erase_all()':
PasswordRAMStore.cc:177:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if ( protected_mem != NULL );
^~
PasswordRAMStore.cc:193:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
memset( protected_mem, '\0', ProtectedMemSize );
^~~~~~
Looks like a stray semicolon...
Bug 796293 - Fix null pointer check accidentally disabled
Replace the insert() method (which reports an error when inserting a
password with a key which already exists) with the store() method which
replaces or inserts the password depending on whether the key already
exists or not respectively. There is also an optimisation that nothing
is changed if the password to be replaced is the same as the one already
stored. The code in Win_GParted::open_encrypted_partition() is
simplified now it doesn't have to implement this pattern of behaviour
itself.
Bug 795617 - Implement opening and closing of LUKS mappings
Reports generic GParted error "Failed to open LUKS encryption" on any
failure unlocking the partition. Choosing not to display cryptsetup
reported errors because those messages and their translations are not
under GParted control.
Bug 795617 - Implement opening and closing of LUKS mappings
The underlying C coded Gtk Entry widget is careful to zero memory after
use, allowing the widget to be safely used for password entry [1].
However the C++ method Gtk::Entry::get_text() just takes the underlying
C string from the Gtk Entry widget and copies it when constructing a
Glib::ustring for the return value [2].
So directly use the Gtk/C API to get the C string instead.
[1] https://git.gnome.org/browse/gtk+/tree/gtk/gtkentrybuffer.c?h=3.22.28#n92
See function trash_area() which zeros memory and its use in
gtk_entry_buffer_normal_insert_text(),
gtk_entry_buffer_normal_delete_text() and
gtk_entry_buffer_finalize().
[2] https://git.gnome.org/browse/gtkmm/tree/gtk/src/entry.hg?h=3.22.2#n104
_WRAP_METHOD(Glib::ustring get_text() const, gtk_entry_get_text)
https://git.gnome.org/browse/glibmm/tree/docs/internal/using_gmmproc.txt?h=2.46.1#n53
_WRAP_METHOD(Glib::ustring METHOD const, FUNC) is processed to:
Glib::ustring METHOD() const
{
return Glib::convert_const_gchar_ptr_to_ustring(
FUNC(const_cast<GtkEntry*>(gobj())));
}
https://git.gnome.org/browse/glibmm/tree/glib/glibmm/utility.h?h=2.46.1#n82
Glib::ustring convert_const_gchar_ptr_to_ustring(const char* str)
{
return (str) ? Glib::ustring(str) : Glib::ustring();
}
So Gtk::Entry::get_text() calls Glib::ustring() constructor which
copies the C string to create the Glib::ustring object returned.
Bug 795617 - Implement opening and closing of LUKS mappings
To keep password dialog open, just keep running it in a loop performing
LUKS mapping unlock attempts with the entered passphrase until it
succeeds or the dialog is cancelled or closed. This is the same model
that is already used for the File Support System dialog and how the
[Rescan For Supported Actions] button is implemented.
Also any error from attempting to open the LUKS mapping is no longer
displayed in a separate error dialog or at all. Will add some sort of
error reporting into the password entry dialog in a following commit.
Creates new method Win_GParted::open_encrypted_partition() which handles
the non UI parts of attempting to open an encrypted partition. Running
"cryptsetup luksOpen" and updating the stored passphrase as needed.
Bug 795617 - Implement opening and closing of LUKS mappings
Initial addition of a password entry dialog. Looks like:
+------------------------------------------------+
| LUKS Passphrase /dev/sdb1 |
+------------------------------------------------+
| Enter LUKS passphrase to open /dev/sdb1 |
| Passphrase: [ ] |
| |
| [ Cancel ] [ Unlock ] |
+------------------------------------------------+
A standard Gtk Dialog is used to accept the password once, with any
errors displayed in a separate error dialog afterwards. This is poor UI
design. A password dialog should remain open for all authentication
attempts and only close when successful or the dialog is cancelled or
closed. This UI design issue will be improved in following commits.
Bug 795617 - Implement opening and closing of LUKS mappings
Implement Close Encryption partition menu item.
The Open Encryption action is not yet implemented and instead reports an
error detailing the open encryption command. A dialog needs to be
written to accept the password entry and pass it to the open encryption
command.
Bug 795617 - Implement opening and closing of LUKS mappings
Add new item to the partition menu to allow the user to open and close
the LUKS mapping. However for now the menu item is always disabled and
there is no implementation behind it to actually open or close the LUKS
mapping. Fragment of the partition menu is now:
...
Format to >
-----------------
Open Encryption <- New menu item
Mount
-----------------
Name Partition
...
Has to be two separate menu items to clearly represent to the user that
LUKS mappings and file system mounting are two separate busy states.
And also in the case of an open but unmounted file system to offer both
actions; close encryption and mount file system.
The text of the menu item automatically changes similarly to how it does
for the Mount/Unmount, Swapon/Swapoff, Activate/Deactivate item
depending on the state of the LUKS mapping. For open LUKS mappings it
will show "Close Encryption" and for all other cases (closed LUKS
mapping or partition is not encrypted) "Open Encryption". Again similar
to how the default of "Mount" is shown for unallocated and unknown
partitions.
Bug 795617 - Implement opening and closing of LUKS mappings
In preparation for adding the ability to toggle the encryption busy
state (open/close the encryption volume), rename existing members to
reflect that they are related to changing the file system state. (Swap
and LVM2 Physical Volumes are handled as file systems by GParted).
class Win_GParted renaming:
MENU_TOGGLE_BUSY -> MENU_TOGGLE_FS_BUSY
allow_toggle_busy_state() -> allow_toggle_fs_busy_state()
toggle_busy_state() -> toggle_fs_busy_state()
check_toggle_busy_allowed() -> check_toggle_fs_busy_allowed()
Bug 795617 - Implement opening and closing of LUKS mappings
Replace echoing "dm" into jfs_debugfs via a shell command to directly
writing "dm" to the input of the jfs_debug command. One less use of the
shell.
Bug 795617 - Implement opening and closing of LUKS mappings
As discussed in "LUKS password handling, threats and preventative
measures" [1] GParted must be able to pass LUKS passphrases to
cryptsetup via standard input to avoid having to write passwords to the
file system and deal with additional security requirements. Therefore
add a way to write input into created child processes. For small
amounts of input, writing up to the pipe buffer capacity won't block
[2]. This is 64K on versions of Linux in any currently supported
distributions.
[1] LUKS password handling, threats and preventative measures
https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56
GParted must not become a password manage so it must never save
LUKS passwords to disk across separate invocations of GParted.
...
GParted should avoid writing a temporary file containing the LUKS
password as it introduces extra complexity with trying to safely
handle and erase file content. Instead GParted must
programmatically pass the LUKS password via standard input to the
cryptsetup command.
[2] pipe(7) manual page:
Pipe capacity
A pipe has a limited capacity. If the pipe is full, then a
write(2) will block or fail, depending on whether the O_NONBLOCK
flag is set (see below). ...
In Linux versions before 2.6.11, the capacity of a pipe was the
same as the system page size (e.g., 4096 bytes on i386). Since
Linux 2.6.11, the pipe capacity is 65536 bytes.
Bug 795617 - Implement opening and closing of LUKS mappings
Mike Fleetwood