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
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)
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
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
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
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
Usage of members label_device_info1 and label_device_info2 was removed
in this commit from 2004.
8ae5ebb2e6
several (mostly) i18n related fixes/cleanups
The CUSTOM_TEXT enumeration is exclusively used as the type of one of
the parameters to the functions get_generic_text() and get_custom_text()
in the FileSystem class and derived classes. The definition of the
enumeration therefore belongs in FileSystem.h. Move it.
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
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.
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.
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
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
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
Use private access into the PasswordRAMStore class to directly obtain
the address of the locked memory, rather than inferring it from the
address of the first stored password. This simplifies
PasswordRAMStoreTest::SetUpTestCase() and avoids encoding most of the
implementation knowledge that the first password will be stored at the
start of the protected memory.
Bug 795617 - Implement opening and closing of LUKS mappings
Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the
same method as used in the PasswordRAMStore destructor.
Bug 795617 - Implement opening and closing of LUKS mappings
Application level requirements for secure password management were set
out in "LUKS password handling, threats and preventative measures" [1].
The requirements are:
1) Passwords are stored in RAM and are not allowed to be paged to swap.
(However hibernating with GParted still running will write all of RAM
to swap).
2) Passwords are wiped from RAM when no longer needed. When each
password is no longer needed and when GParted closes.
3) Passwords are referenced by unique key. Recommend using LUKS UUIDs
as the unique key.
(Each LUKS password should only ever need to be entered once for each
execution of GParted. Therefore the passwords can't be stored in any
of the existing data structures such as Partitions or LUKS_Info cache
because all of these are cleared and reloaded on each device
refresh).
There seems to be two possible implementation methods: use an existing
library to provide secure memory handling, or write our own.
Libgcrypt [2] and libsodium [3] cryptographic libraries both provide
secure memory handling. (Secure memory is quite simple really, some
virtual memory locked into RAM which is zeroed when no longer needed).
Linking to an encryption library just to provide secure memory seems
like using a sledge hammer to crack a nut. Also because of requirement
(3) above a module is needed to "own" the pointers to the passwords in
the secure memory. Managing the secure memory ourselves is probably no
more code that that needed to interface to libgcrypt. Therefore handle
the secure memory ourselves.
So far the module is only compiled. It is not used anywhere in GParted.
[1] LUKS password handling, threats and preventative measures
https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56
[2] libgcrypt general purpose cryptographic library, as used in GNU
Privacy Guard
https://gnupg.org/related_software/libgcrypt/
[3] libsodium crypto library
https://download.libsodium.org/doc/
Bug 795617 - Implement opening and closing of LUKS mappings
PATCHSET OVERVIEW:
As of 31 March 2017 RHEL / CentOS 5 reached the end of their support
[1][2]. Therefore remove code which supports them. This makes RHEL /
CentOS 6 the oldest supported distribution. So the minimum required
versions of glibmm and gtkmm can be increased dropping some autoconf
checks and conditional code supporting older versions of these
libraries. This will undo the bulk of these these previous bug fixes:
* GParted 0.21.0
Bug 738706 - Add support for ext4 on RHEL/CentOS 5.x
* GParted 0.16.1
Bug 695279 - Fix GParted doesn't compile on RHEL / CentOS 5.9
[1] Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates
[2] Subject: CentOS Linux 5 EOL
https://lists.centos.org/pipermail/centos-announce/2017-April/022350.html
THIS PATCH:
Remove checks for e4fsprogs commands, removing support for ext4 on
RHEL / CentOS 5.x. This is reverting earlier commit:
f672f68863
Check for e4fsprogs commands for ext4 support on RHEL/CentOS 5.x (#738706)
Mkfs_cmd member variable is being kept as a convenience so that it is
created once rather than on each use. Also note that as it is a
Glib::ustring type object, it's constructor will be called which will
initialise it to the empty string so it doesn't need initialising to the
empty string in the initialiser list of the ext2() constructor itself.
Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required
versions to glibmm 2.14.0 and gtkmm 2.16.0
Struct FS and struct FS_Limits are strongly related to the FileSystem
class, both being return values from members and associated with storing
file system attributes. Move their definitions from Utils.h into
FileSystem.h.
There are too many different types of things named "filesystem" in the
GParted code with the potential to cause confusion. Namely:
std::vector<FS> FILESYSTEMS
Vector of file system capabilities.
class FileSystem Base class interfacing to file system
specific executables for querying and
modification.
enum FILESYSTEM Symbolic constants representing each file
system type.
Many recent written or re-written functions already used a variable
named fstype. Rename enum FILESYSTEM to enum FSType to clearly
distinguish it from the other things with very similar names. Only
changing the name of the enumeration, not the name of variables of that
type too because that is a lot more lines of code and those can be
changed when the relevant code is re-written.
There are multiple repetitions of the same code getting a FileSystem
object, checking for NULL and then calling the file system specific
get_filesystem_limits(). Extract that into a common function.
GParted_Core::get_filesystem_limits() can't use the file system from the
passed Partition object because that is the current file system which
will be different from the intended file system for new and format
operations. So would look up the wrong derived FileSystem specific
object and call the wrong get_filesystem_limits(). Hence still needing
fstype as a separate parameter to pass the intended file system.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
UDF file system minimum and maximum size limits are defined in terms of
numbers of file system blocks. So when resizing an existing file system
compute the byte size limits from the existing UDF file system's block
size. Alternatively when creating a new UDF file system use the
device's sector size as the multiplier instead.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
As described in the previous commit, this is so that file system
specific implementations can dynamically determine size limits based on
Partition object attributes: such as the device sector size and the file
system block size. (Assuming set_used_sectors() sets
partition.fs_block_size for the type of file system in question).
Bug 787204 - Minimum and maximum size of the UDF partition/disk
All the code has been switched to call get_filesystem_limits() and use
struct FS_Limits. Remove struct FS members .MIN & .MAX.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
Change Dialog_Partition_New to use a fs_limits rather than struct FS
and .MIN and .MAX. No passing of struct FS_Limits required. Just use
the FILESYSTEMS vector of struct FS to provide the file system type and
look up it's size limits each time the selection changes.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
Mike Fleetwood