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
Mike Fleetwood