Commit Graph

735 Commits

Author SHA1 Message Date
Luca Bacci 7fd39932a3 modern-gtk2: Use Cairo for drawing the partition info (!17)
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
2018-11-12 21:50:42 +00:00
Luca Bacci d17d129044 modern-gtk2: Use Cairo for drawing the partition resizer (!17)
GdkGC has been deprecated in the underlying C / GTK+ 2.22 library.  It
is less clearly stated but Gdk::GC is also deprecated in C++ / gtkmm.
Cairo based rendering should be used instead.
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html
https://gitlab.gnome.org/GNOME/gtk/blob/2.22.0/NEWS#L124
https://developer.gnome.org/gtkmm/2.24/classGdk_1_1GC.html

First commit in a series to convert Gdk::GC based drawing to Cairo based
drawing.  This specific commit makes the transition for the graphical
partition resizing widget that is used in the "Create New Partition",
"Paste" creating new partition and "Resize/Move" dialogs.

Cairo is not pixel based but instead uses a continuous coordinate space.
To draw in a pixel aligned way follow the guidance in the Cairo FAQ.
https://www.cairographics.org/FAQ/#sharp_lines

Additional references:
https://developer.gnome.org/gdk2/stable/gdk2-Drawing-Primitives.html#gdk-draw-line
https://developer.gnome.org/gdk2/stable/gdk2-Drawing-Primitives.html#gdk-draw-rectangle

Closes !17 - Gtk2 modernisation
2018-11-12 21:50:42 +00:00
Luca Bacci c602170faa modern-gtk2: Delay construction of Gtk::TreeModel* objects (!17)
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-use

Closes !17 - Gtk2 modernisation
2018-11-12 21:50:42 +00:00
Luca Bacci 6bfa95d427 modern-gtk2: Rename callback after OptionComboBox class switch (!17)
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
2018-11-12 21:50:42 +00:00
Luca Bacci 48d2fd2120 modern-gtk2: Use OptionComboBox class for file system combobox (!17)
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
2018-11-12 21:50:42 +00:00
Luca Bacci cf5e9c863f modern-gtk2: Use OptionComboBox class for partition type combobox (!17)
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
2018-11-12 21:50:42 +00:00
Luca Bacci 83b98885f6 modern-gtk2: Use OptionComboBox class for alignment combobox (!17)
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
2018-11-12 21:50:42 +00:00
Luca Bacci 5407e8346b modern-gtk2: Introduce OptionComboBox class (!17)
Gtk::OptionMenu is a combobox type widget that is constructed from a
Gtk::Menu rather than a Gtk::TreeModel.  However Gtk::OptionMenu was
deprecated in gtkmm 2.4.1.

In GParted the Gtk::OptionMenu widget is used for:
- partition alignment combobox
- partition type combobox
- file system combobox

While they consist only of text we cannot use Gtk::ComboBoxText because
it doesn't expose functionality in its interface to make items inactive.

Create OptionComboBox helper class that builds a combobox consisting of
only text items, much like Gtk::ComboBoxText, but has the added
functionality to set items as inactive.

References:
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1OptionMenu.html#details
https://gitlab.gnome.org/GNOME/gtkmm/blob/GTKMM_2_10_1/ChangeLog#L3515
bba503b047
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1ComboBoxText.html

Closes !17 - Gtk2 modernisation
2018-11-12 21:50:42 +00:00
Luca Bacci 430ac9240c modern-gtk2: Use Gtk::Widget::set_tooltip_text() (!17)
GParted was using Gtk::Tooltips widgets for tooltips, but they were
deprecated in gtkmm 2.12 in favour of Gtk::Tooltip widgets.  (Note the
spelling difference, with and without a trailing 's').

As GParted's tooltips are all text only continue to use the shortcut,
which is now Gtk::Widget::set_tooltip_text().

References:
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Tooltips.html#details
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Tooltip.html#details
https://gitlab.gnome.org/GNOME/gtkmm/blob/2.20.0/NEWS#L740

Closes !17 - Gtk2 modernisation
2018-11-12 21:50:42 +00:00
Mike Fleetwood 69c1537a38 Recognise APFS (Apple File System) (#23)
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=2

Closes #23 - GParted doesn't detect APFS (Apple File System)
2018-11-12 20:39:55 +00:00
Mike Fleetwood f8512506ae Prevent online resizing of file systems mounted read-only (#10)
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
2018-09-20 16:30:15 +00:00
Mike Fleetwood c82883d6a7 Add and set read-only mount flag in the Partition object (#10)
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
2018-09-20 16:30:15 +00:00
Mike Fleetwood 441b39347a Add parsing of read-only mount option into mount maps (#10)
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
2018-09-20 16:30:15 +00:00
Mike Fleetwood f4994a2b63 Add read-only flag to mounted file system entries (#10)
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
2018-09-20 16:30:15 +00:00
Mike Fleetwood 9c35d91453 Refactor get_filesystem_object()
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.
    "
2018-09-17 15:36:09 +00:00
Mike Fleetwood d3ef32096a Re-assign UFS to be a basic supported file system (!13)
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
2018-09-17 15:36:09 +00:00
Mike Fleetwood 9a66139eff Add "other" file system type (!13)
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
2018-09-17 15:36:09 +00:00
Mike Fleetwood ba79ddaf72 Limit FILESYSTEM_MAP entries to supported and basic supported FSs (!13)
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
2018-09-17 15:36:09 +00:00
Mike Fleetwood f61481f3ae Separate unknown file system type from unsupported actions (!13)
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
2018-09-17 15:36:09 +00:00
Mike Fleetwood 03e89b1289 Add support for minix file system (!12)
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
2018-08-24 20:22:08 +01:00
Mike Fleetwood 73e7367ef7 Remove unused member Win_GParted::menu_item
Usage of menu_item was removed in this commit from 2006.

    fb672f5219
    happy new year ;) fixed some alignment issues removed confirmation dialogs
2018-08-01 19:03:01 +01:00
Mike Fleetwood 5d6f405b41 Remove unused members Win_GParted::label_device_info[12]
Usage of members label_device_info1 and label_device_info2 was removed
in this commit from 2004.

    8ae5ebb2e6
    several (mostly) i18n related fixes/cleanups
2018-08-01 19:03:01 +01:00
Mike Fleetwood fc167a71a3 Move enum CUSTOM_TEXT into FileSystem.h
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.
2018-07-19 19:26:30 +00:00
Mike Fleetwood a2af9d4a34 Clear previous LUKS unlock failure error before next attempt (#795617)
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
2018-06-19 10:54:48 -06:00
Mike Fleetwood a9e85698f2 Rework scope of fat16:: and ntfs::Change_UUID_Warning vectors
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.
2018-06-18 14:47:17 -06:00
Mike Fleetwood eab54260a4 Simplify from Gtk::Table to HBox in Partition Name dialog
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.
2018-06-18 10:15:33 -06:00
Mike Fleetwood f760c16ba6 Simplify from Gtk::Table to HBox in FileSystem Label dialog
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."
2018-06-18 10:15:33 -06:00
Mike Fleetwood d948cbcb91 Make get_custom_text() and get_generic_text() return by reference
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.
2018-06-18 10:15:33 -06:00
Mike Fleetwood 957216f06c Change to insert or replace PasswordRAMStore::store() interface (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 1bbb81f920 Report LUKS unlock errors into the password dialog (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 3d49fdc2e4 Stop copying password into insecure memory when getting entry (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 307472489d Keep password dialog open until successful unlock or cancellation (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood f4d47fe5a5 Add password entry dialog and attempt LUKS unlock once (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood e4959c520f Add unimplemented open/close encryption to the partition menu (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood f898910e90 Rename some Win_GParted members to *toggle_fs_busy* (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 8dff80edc6 Add ability for small writes to stdin of child processes (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 9b52666bdb Simplify obtaining address of password memory for unit tests (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood d2a2ebe4a1 Add unit testing of erasing all passwords (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 04637a3426 Add PasswordRAMStore module (#795617)
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
2018-04-30 09:10:48 -06:00
Mike Fleetwood 6c4ab5dc28 Remove checks for e4fsprogs commands (#794253)
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
2018-03-26 10:16:45 -06:00
Mike Fleetwood a3b47ca14a Move struct FS and FS_Limits into FileSystem.h
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.
2018-01-28 10:09:35 -07:00
Mike Fleetwood 175d27c55d Rename enum FILESYSTEM to FSType
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.
2018-01-28 10:09:35 -07:00
Mike Fleetwood 46bf5a383e Extract common code into GParted_Core::get_filesystem_limits() (#787204)
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
2018-01-28 10:09:35 -07:00
Mike Fleetwood ae2a8723b5 Set dynamic UDF file system size limits (#787204)
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
2018-01-28 10:09:35 -07:00
Mike Fleetwood 668957c0a4 Pass Partition object to get_filesystem_limits() (#787204)
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
2018-01-28 10:09:35 -07:00
Mike Fleetwood e234df6b2e Remove struct FS members .MIN & .MAX (#787204)
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
2018-01-28 10:09:35 -07:00
Mike Fleetwood 4fa262d7e3 Switch to using struct FS_Limits inside Dialog_Partition_New (#787204)
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
2018-01-28 10:09:35 -07:00
Mike Fleetwood 53b7a75894 Query and pass struct FS_Limits into Dialog_Partition_Resize_Resize_Move (#787204)
Refactor Win_GParted::activate_resize() to query the file system size
limits using the new get_filesystem_limits() method and pass those
limits into the dialog class as struct FS_Limits.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood 285c24a82a Query and pass struct FS_Limits into Dialog_Partition_Copy (#787204)
Refactor Win_GParted::activate_paste() to query the file system size
limits using the new get_filesystem_limits() method and pass those
limits into the the dialog class as struct FS_Limits.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood fc436595fd Switch to using struct FS_Limits inside Dialog_Partition_Copy (#787204)
Adds working copy fs_limits member into common Dialog_Base_Partition
class.  Changes the internal code in Dialog_Partition_Copy class to use
fs_limits instead of fs.MIN and fs.MAX.  The limits are still passed
into the constructor via object of struct FS and it's members .MIN and
.MAX but immediately used to assign to the fs_limits member.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood 04535c48b3 Create separate file system limits structure and getter method (#787204)
PATCH SET OVERVIEW:

Currently the supported actions of each file system and their size
limits are stored in struct FS objects.  These are created by calling
file system specific derived implementations of
FileSystem::get_filesystem_support().  This happens when GParted is
started or when a when a rescan for supported actions is performed.  The
file system size limits are expressed as a fixed number of bytes.

The maximum UDF file system size is specified in terms of file system
block size units.  Also the file system block size must match the sector
size of the underlying device.  Typically 2K for optical media and 512
bytes or 4K for hard drives.

Therefore GParted can't properly express the true UDF file system size
limits because they depend on the block size of an existing UDF file
system or the sector size of the device for new UDF file systems.  In
fact other file systems such as EXT2/3/4 and XFS actually express their
maximum file system size in terms of numbers of file system blocks but
these tend to always be 4K and don't have to match the sector size of
the underlying device, so fixed byte values tend to suffice.

To update GParted for this, first separate file system size limits from
struct FS into struct FS_Limits and provide new
FileSystem::get_filesystem_limits() method to allow the limits to be
queried independently of the calls to get_filesystem_support().
Second, pass Partition objects and allow derived get_filesystem_limits()
implementations.

THIS PATCH:

Just creates a separate structure storing fixed value file system
minimum and maximum size limits along with getter method
get_filesystem_limits().

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Pali Rohár 2f532be9f9 Use external tools udfinfo and udflabel for UDF file system (#792052)
Those external tools were introduced in version 2.0 of udftools package
and can show or change UDF label, UDF uuid and can provide information
needed for counting total/free sectors.

Bug 792052 - Add support for changing UDF label/uuid and show disk usage
2018-01-04 17:02:53 +00:00
Mike Fleetwood b04dbbc357 Rename function and reword text for rollback of failed file system move
To better reflect specifically that it is a failed (internally
implemented) file system move which is being rolled back.
2018-01-02 10:34:52 -07:00
Mike Fleetwood 0b5bf83b22 Enable failed partition change rollback for selected steps (#791875)
The general rule is that:
1) For a partition change step BEFORE a file system change step,
   rollback on failure;
2) For a partition change step AFTER a file system change step, don't
   rollback on failure.

Examining every case where resize_move_partition() is called and whether
rollback on failure is wanted or not:

* In resize_move()
    Resize / move extended partition.  No associated file system change.
  NO ROLLBACK
    Just to keep possibly applied operation.

* #1 in move()
    Making all encompassing partition before moving file system.
  ROLLBACK
    To restore partition boundaries back to those of the file system.

* #2 in move()
    Recreating original partition boundaries after file system move
    failed or was cancelled and has been rolled back.
  NO ROLLBACK
    To keep updated partition boundaries to match restored file system
    data.

* #3 in move()
    Replacing all encompassing partition with final partition after
    successful file system move.
  NO ROLLBACK
    Keep new partition boundaries to match moved file system.

* #1 in resize_encryption()
    Making the partition larger before growing closed LUKS encrypted
    data.
  ROLLBACK
    Restore partition boundaries back to those of the closed LUKS
    encrypted data.

* #2 in resize_encryption()
    Shrinking the partition after open LUKS mapping has been shrunk, but
    before swap is re-created (smaller).
  NO ROLLBACK
    Difficult case because the partition shrink is in the middle of a
    LUKS shrink and a swap shrink (re-create).  If swap was actually
    shrunk like other types of file system, rather than re-created, then
    the operation sequence would be (1) shrink swap, (2) shrink LUKS
    encryption, (3) shrink partition.  In this hypothetical case and the
    actual case no rollback is preferred to try to keep the new
    partition boundaries match the shrunk open LUKS encryption mapping.

* #3 in resize_encryption()
    Grow the partition before growing open LUKS mapping and re-creating
    swap larger.
  ROLLBACK
    Restore partition boundaries back to those of the smaller open LUKS
    encryption mapping.

* #4 in resize_encryption()
    Shrink the partition after shrinking the file system and open LUKS
    encryption mapping.
  NO ROLLBACK
    Keep new smaller partition boundaries to match shrunk encrypted file
    system.

* #5 in resize_encryption()
    Grow the partition before growing the open LUKS encryption mapping
    and file system.
  ROLLBACK
    Restore partition boundaries back to those of the not yet grown
    encrypted file system.

* #1 in resize_plain()
    Resize partition before re-creating swap a different size.
  ROLLBACK
    Restore partition boundaries back to those of the not yet resized
    (re-created) swap space.

* #2 in resize_plain()
    Shrink partition after shrinking the file system.
  NO ROLLBACK
    Keep new smaller partition boundaries to match shrunk file system.

* #3 in resize_plain()
    Grow partition before growing the file system.
  ROLLBACK
    Restore partition boundaries back to those of the not yet grown
    file system.

Removes the default value from the rollback_on_fail parameter so
rollback or not has to be explicitly specified for every call of
resize_move_partition().

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood 0f16703bbb Implement rollback of failed partition resize/move steps (#791875)
Even after implementing a fix for bug 790418 "Unable to inform the
kernel of the change message may lead to corrupted partition table"
GParted/libparted can still encounter errors informing the kernel of the
new partition layout.  This has been seen with GParted on CentOS 7 with
libparted 3.1.

In such a case the partition has been successfully written to the disk
but just informing the kernel failed.  This is a problem because when a
partition is being moved in advance of a file system move step, failure
to inform the kernel leaves the partition boundaries not matching the on
disk limits of the file system.  For a move to the left this leaves the
partition reported as unknown, apparently losing the user's data.

For example start with a 512 MiB partition containing an XFS file
system.  This is recognised by blkid and parted, hence also by GParted.

    # blkid /dev/sdb1
    /dev/sdb1: UUID=... TYPE="xfs" PARTUUID="37965980-01"
    # parted /dev/sdb unit s print
    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
     1      1048576s  2097151s  1048576s  primary  xfs

Now move the partition 100 MiB to the left and have it fail to inform
the kernel after the first partition change step.  Operation details:

    Move /dev/sdb1 to the left                                 (ERROR)
    * calibrate /dev/sdb1                                      (SUCCESS)
    * check file system on /dev/sdb1 for errors and (if poss...(SUCCESS)
    * grow partition from 512.00 MiB to 612.00 MiB             (ERROR)
        old start: 1048576
        old end: 2097151
        old size: 1048576 (512.00 MiB)
        requested start: 843776
        requested end: 2097151
        requested size: 1253376 (612.00 MiB)
      * libparted messages                                     (ERROR)
          Error informing the kernel about modifications to partition
          /dev/sdb1 -- Device or resource busy.  This means Linux won't
          know about any changes you made to /dev/sdb1 until you reboot
          -- so you shouldn't mount it or use it in any way before
          rebooting.  Failed to add partition 1 (resource temporarily
          unavailable)

Now because the start of the partition is 100 MiB before the start of
the file system, the file system is no longer recognised, and apparently
the user's data has been lost.

    # blkid /dev/sdb1
    /dev/sdb1: PARTUUID="37965980-01"
    # parted /dev/sdb unit s print
    ...
    Number  Start    End       Size      Type     File system  Flags
     1      843776s  2097151s  1253376s  primary

It doesn't matter why updating the partition failed, even if it was
because of an error writing to the disk.  Rollback of the change to the
partition should be attempted.  The worst case scenario is that rollback
of the change fails, which is the equivalent to how the code worked
before this patch set.

However in other cases where the partition boundaries are being updated
after a file system move or shrink step then the partition should be
updated to match the new location of the file system itself.  And no
rollback is wanted.  If the failure was only informing the kernel then
in fact the partition has actually been updated on disk after all.

So each partition resize/move step needs examining on a case by case
basis to decide if rolling back the change to the partition is wanted or
not.

This patch only adds partition change rollback into
resize_move_partition().  Rollback remains disabled until all cases are
examined in the following patch.

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood 93ccc79e3a Extract common code into update_dmraid_entry() (#791875)
Extract common code which updates a DMRaid device mapper entry into a
sub-function.  This will also be needed when adding rollback of a
partition change on failure.

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood 890d5a93a7 Extract code into resize_move_partition_implement() (#791875)
Extract the code which actually implements the partition change into a
sub-function ready for adding rollback of the change on failure.

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood 8c5c13d613 Rename OperationDetailStatus STATUS_N_A to STATUS_WARNING
Make the enumeration name match it's use as indicating a warning.  Also
spell SUCCESS correctly.  Follow on to icon variable names too.
2017-11-26 10:53:52 -07:00
Mike Fleetwood 0688662055 Identify libparted messages as either success or error (#790842)
All libparted messages were reported as informational, even for a step
which failed.  Instead identify libparted messages as either
informational or errors depending on whether this step was successful
or not respectively.

Bug 790842 - Report libparted messages into operation details at the
             point at which they occur
2017-11-26 10:53:24 -07:00
Mike Fleetwood 23939331f6 Capture libparted messages via callback at top-level only (#790842)
Replace the explicit adding of libparted exception messages with a
callback to do it instead, and fire the callback just once per operation
by only changing the very top-level OperationDetail to use the new
set_success_and_capture_errors().  Therefore this still produces exactly
the same operation details with libparted messages at the end of each
operation.

Bug 790842 - Report libparted messages into operation details at the
             point at which they occur
2017-11-26 10:53:18 -07:00
Mike Fleetwood 2ed7feb2f5 Add mechanism to capture exception messages into an OperationDetail (#790842)
All code implementing a step of an operation follows this pattern:

    od.add_child(OperationDetail("Step heading"));
    od.get_last_child().add_child(OperationDetail("More details"));
    // Do step
    success = ...
    od.get_last_child().set_status(success ? STATUS_SUCCESS
                                           : STATUS_ERROR);

At this point any libparted messages reported via exceptions need to be
added into the OperationDetail tree.  Also adding further children into
the tree after collecting those errors needs to be prohibited (as much
as the previous patch prohibited it).

Add a new method which will replace the final set_status() call above
like this which set the status, captures the errors and flags that
further children shouldn't be added:

    ...
    od.get_last_child().set_success_and_capture_errors(status);

It emits a callback to capture the errors to provide flexibility and so
that the OperationDetail class doesn't have to get into the details of
how GParted_Core saves libparted exception messages.

Bug 790842 - Report libparted messages into operation details at the
             point at which they occur
2017-11-26 10:52:54 -07:00
Mike Fleetwood f8f9a72de6 Add mechanism to stop adding more child OperationDetails (#790842)
Want functionality to prevent further child details being added to an
OperationDetail.  This is so that the captured libparted error messages
are always the last child in the list, and more details (at that point
in the tree) can't be added.

For example we want GParted to report like this:

  Move /dev/sdb3 to the right and shrink it from 1.14 GiB to...(SUCCESS)
  ...
  * shrink partition from 1.14 GiB to 1.00 GiB                 (SUCCESS)
    * old start: 4464640
      old end: 6856703
      old size: 2392064 (1.14 GiB)
    * new start: 4464640
      new end: 6561791
      new size: 2097152 (1.00 GiB)
    * libparted messages                                       (INFO)
      * DEBUG: GParted generated synthetic libparted excepti...

and not like this:

  Move /dev/sdb3 to the right and shrink it from 1.14 GiB to...(SUCCESS)
  ...
  * shrink partition from 1.14 GiB to 1.00 GiB                 (SUCCESS)
    * old start: 4464640
      old end: 6856703
      old size: 2392064 (1.14 GiB)
    * libparted messages                                       (INFO)
      * DEBUG: GParted generated synthetic libparted excepti...
    * new start: 4464640
      new end: 6561791
      new size: 2097152 (1.00 GiB)

So actually preventing the addition of more child details would stop
users seeing information they should see.  So instead just report a bug
message into the operation details.  This doesn't stop anything, but the
bug message will be seen and allow us to fix GParted.

So far nothing is enforced.  This patch just adds the mechanism to
report a bug when a new child detail is added when prohibited.

Bug 790842 - Report libparted messages into operation details at the
             point at which they occur
2017-11-26 10:06:37 -07:00
Mike Fleetwood 33a535390e Extract common code into new method get_lp_partition() 2017-10-03 08:22:19 -06:00
Mike Fleetwood ea269cc929 Switch from whole_device flag to TYPE_UNPARTITIONED (#788308)
Remove whole_device flag and replace with new partition type
TYPE_UNPARTITIONED.  Minimally adapt the remaining code to compile and
run.

Bug 788308 - Remove whole_device partition flag
2017-10-03 08:22:19 -06:00
Mike Fleetwood c10d80a295 Add TYPE_UNPARTITIONED partition type (#788308)
Just adds the enumeration.  Using it will follow.

Bug 788308 - Remove whole_device partition flag
2017-10-03 08:22:19 -06:00
Mike Fleetwood 400864a65e Add and use Partition::set_unpartitioned() method (#788308)
PATCHSET OVERVIEW:

When unpartitioned drive read-write support was added this commit added
a whole_device flag:
   5098744f9a
   Add whole_device flag to the partition object (#743181)

Using a whole_device flags now seems not the correct way to model
unpartitioned drives.  GParted models an uninitialised drive as:
    .path         = _("uninitialized")
    .type         = TYPE_UNALLOCATED
    .whole_device = true
    .filesystem   = FS_UNALLOCATED
and a whole drive file system, using ext4 for example, as:
    .path         = "/dev/sdb"
    .type         = TYPE_PRIMARY
    .whole_device = true
    .filesystem   = FS_EXT4
No partitioning changed yet the type of the partition in the model
changed between TYPE_UNALLOCATED and TYPE_PRIMARY depending on whether
the whole drive contains a recognised file system or not.

The partition object describing a file system within a LUKS encryption
mapping is another case of the model not matching reality.
    .path         = /dev/mapper/crypt_sdb1_crypt
    .type         = TYPE_PRIMARY
    .whole_device = true
    .filesystem   = FS_EXT4
There is no partition table within the encryption mapping, the file
system fills it, but GParted records it as a primary partition.

Make TYPE_UNALLOCATED and TYPE_PRIMARY be reserved for representing
unallocated space and primary partitions within a partitioned disk drive
and introduce new TYPE_UNPARTITIONED for all cases of an unpartitioned
whole disk drive.

The GParted UI does differentiate between an unallocated whole disk
device and anything else by requiring a partition table to be created
first, even if that is just the loop partition table.  That
determination can simply look for the partition object containing file
system type FS_UNALLOCATED instead.

THIS PATCH:

Create set_unpartitioned() helper method to set a partition object to
represent a whole disk drive and use everywhere such an object is
modelled.  This matches what existing methods Set_Unallocated() and
indeed Set() do for unallocated space and any type of partition
respectively.

For now the partition type is still set to either TYPE_UNALLOCATED or
TYPE_PRIMARY so the rest of the code base remains the same.
TYPE_UNPARTITIONED will be introduced later.

Bug 788308 - Remove whole_device partition flag
2017-10-03 08:22:06 -06:00
Pali Rohár e8f0504b13 Make sure that FS_Info cache is loaded for all named paths (#787181)
Naming a file system image file on the command line is shown by GParted
as unknown.

    $ truncate -s 100M /tmp/fat.img
    $ mkfs.vfat /tmp/fat.img
    $ sudo ./gpartedbin /tmp/fat.img

Currently the FS_Info cache is loaded for all devices reported by
blkid (plus all whole disk devices identified from /proc/partitions even
if blkid reports nothing).  However file system images named on the
command line are not queried so GParted can't identify them.

Fix by ensuring that the FS_Info blkid cache is loaded for all named
devices, including named file system image files.

Note that Mount_Info::load_cache() depends on the contents of the
FS_Info cache to lookup UUID= and LABEL= device names from /etc/fstab.
However only file systems in block devices can be mounted like this, and
never file system image files, so the fact that the cache may be
extended afterwards by FS_Info::load_cache_for_paths() does not matter.

History

Prior to version 0.22.0, when unpartitioned drive support was added,
GParted could recognise some file system image files using loop
partition handling in libparted.  However libparted before version 3.2
reported the loop partition name as the whole disk device name appended
with "1" so all the query commands were provided a non-existent name to
use.  Therefore no file system usage or the label was displayed.

Bug 787181 - Fix detection of file system images
2017-09-12 19:10:20 +01:00
Mike Fleetwood 73fe1dbf5c Support /etc/fstab using Unicode labels as mount points (#786502)
So far GParted is still loading the default non-reversible encoded
labels from blkid in the initial loading of the FS_Info module cache.
This encoded label is used to match LABEL=<label> when reading
/etc/fstab, via the get_path_by_label() call, so works for ASCII only
labels.  This prevents GParted enabling the "mount on >" partition menu
item when non-ASCII labels are used.

To fix this:
1) Stop reading the labels the wrong way.
   Via the blkid command used to initially load the FS_Info module cache
   and is subject to default non-reversible encoding of non-printable
   ASCII bytes.
2) Read all the labels the right way, but only when needed.
   Only when /etc/fstab file contains LABEL=<label> and
   get_path_by_label() is called, read all the labels from blkid without
   encoding them via run_blkid_update_cache_one_label().
3) Return label from the cache.
   get_label() returns the cached label, loading it into the cache first
   if needed with run_blkid_update_cache_one_label().

In the worst case scenario of having a LABEL=<label> in /etc/fstab blkid
will be run for every partition containing a recognised file system to
read the label.  On my desktop with 5 hard drives, 4  SWRaid arrays and
31 recognised file systems running 'blkid -o value -s LABEL ...' 31
times took 0.074 seconds of a total scan time of 9.072 seconds.  Less
that 1% of the total scanning time.  When LABEL=<label> is not used in
/etc/fstab individual blkid executions are only used to read labels for
file systems where there is no file system specific tool available
reducing the impact further.  Blkid itself caches the data in it's
blkid.tab cache file rather than reading all file systems on each
invocation.  Also the Linux file system cache will already contain the
blkid executable file, needed libraries files and the blkid.tab cache
file itself.  Hence why repeated execution of blkid is so fast.

Further to the updated comment in set_partition_label_and_uuid().
Matching LABEL=<label> from /etc/fstab uses the label obtained from
blkid run in the C locale so this kind of assumes it returns the label
correctly and it does for my limited testing on Unicode enabled
desktops.  Just not sure if it would be true for all cases in all
locales compared to the FS specific command run in the users default
locale.

Bug 786502 - Support reading Unicode labels when file system specific
             tools aren't available
2017-09-02 13:25:26 -06:00
Mike Fleetwood b022c1e3a9 Update FS_Info cache with Unicode safe labels read from blkid (#786502)
Move the code which reads the Unicode label from FS_Info::get_label()
into new function run_blkid_update_cache_one_label() which also replaces
the non-reversibly encoded copy loaded during the initial cache load.

This is mainly a bit of code refactoring ready for the following change.
It deliberately keeps the initial loaded labels so that reading
/etc/fstab and decoding LABEL=<label> to block special device names via
FS_Info::get_path_by_label() continues to works, at least for ASCII only
labels.

Bug 786502 - Support reading Unicode labels when file system specific
             tools aren't available
2017-09-02 13:25:26 -06:00
Mike Fleetwood a0c44d766d Refactor UDF label manipulation code (#784533)
Make especially the Volume Identifier length limit code simpler to
understand and therefore easier to maintain.

Bug 784533 - Add support for UDF file system
2017-07-30 09:50:09 +01:00
Pali Rohár 861bc8df5d Add support for long UDF labels and check for old versions of mkudffs (#784533)
UDF label is stored in the Logical Volume Identifier which has space for
either 126 Latin1 or 63 UCS-2 characters.  For compatibility reasons
with older versions of blkid, the possibly truncated UDF label is also
stored in the Volume Identifier which only has space for 30 Latin1 or 15
UCS-2 characters.

Because versions of mkudffs prior to 1.1 damage the label if it contains
non-ASCII characters, make sure GParted does not call such versions of
mkudffs with a non-ASCII character label.

Bug 784533 - Add support for UDF file system
2017-07-30 09:50:09 +01:00
Pali Rohár 5f327feb25 Add support for UDF file system (#784533)
Add support for detecting UDF file systems and formatting hard disks
with revision 2.01 UDF file systems using udftools.  Formatting optical
disks or any other media types is not supported yet.  Changing label or
UUID after formatting is not supported as the tools do not yet exist.

Bug 784533 - Add support for UDF file system
2017-07-10 19:17:05 +01:00
Mike Fleetwood 25780c611b Further improve speed of PipeCapture for non-watched output (#777973)
For large output a lot of time is used copying capturebuf to callerbuf
to provide a Glib::ustring copy of the buffer for the update callback.
However update callbacks are only used when commands are run to apply
operations by FileSystem::execute_command() and their output is
incrementally displayed in the UI.  Whereas update callbacks are never
used when commands are used to query information via
Utils::execute_command().

Stop performing interim copying of capturebuf to callerbuf when there
are no update callbacks registered as it is unnecessary.

Time to read portions of the recorded fsck.fat output via
fat16::set_used_sectors() and intermediate copies aren't required:

                     1 MiB     10 MiB   122 MiB
    old code :   0.074 sec   1.41 sec   210 sec [3:30]
    new code :   0.063 sec   0.56 sec     6.57 sec

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood 8dbbb47ce2 Workaround g_utf8_get_char_validate() bug with embedded NUL bytes (#777973)
If PipeCapture reads a NUL byte in the middle of what is expected to be
a multi-byte UTF-8 character then PipeCapture either returns the
captured characters to the previous update or loops forever depending on
whether the end of the stream is encountered before the read buffer is
full or not.  This is equivalent to saying whether the NUL byte occurs
within the last 512 bytes of the output or not.

This is caused by a bug in g_utf8_get_char_validated() reporting that a
partial UTF-8 character has been found when the NUL byte is encountered
in the middle of a multi-byte character even though more bytes are
available in the length specified buffer.  g_utf8_get_char_validated()
is always stopping at the NUL byte assuming it is working with a NUL
terminated string.

Workaround this by checking for g_utf8_get_char_validated() claiming a
partial UTF-8 character has been found when in fact there are at least
enough bytes in the read buffer to instead determine that it is really
an invalid UTF-8 character.

Reference:
    Bug 780095 - g_utf8_get_char_validated() stopping at nul byte even
                 for length specified buffers
    https://bugzilla.gnome.org/show_bug.cgi?id=780095

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood b5b3d199f8 Improve the performance of PipeCapture for large output (#777973)
A user had a very corrupted FAT file system such that fsck.fat produced
122 MiB of output.  GParted has to read this output to get the file
system usage information.  However GParted takes more than 48 hours to
read the 122 MiB of output, while using 100% CPU time and is
unresponsive for the duration.

Modified fsck.fat to output just the first 1 MiB of output and used perf
to capture performance data from GParted reading that output:
    # perf -g -F 1999 -- ./gpartedbin
    # perf report --stdio
      67.84% Glib::ustring::replace      [4.23s]
      17.67% g_utf8_pointer_to_offset    [1.10s]
       8.48% g_utf8_offset_to_pointer    [0.53s]
    [  6.01% (everything else)       ]   [0.38s]
    [100.00% TOTAL                   ]   [6.24s]

And to read the first 10 MiB of output the performance figures are:
      92.95% Glib::ustring::replace      [257.44s]
       4.35% g_utf8_pointer_to_offset    [ 12.05s]
       2.13% g_utf8_offset_to_pointer    [  5.90s]
    [  0.58% (everything else)       ]   [  1.61s]
    [100.00% TOTAL                   ]   [277.00s]

See how the total time is increasing non-linearly, 44 times longer for
only 10 times as much data.  This is because of the exponential increase
in time spent in Glib::ustring::replace.

After a lot of experimentation I came to the conclusion that
Glib::ustrings are not appropriate for storing and editing large buffers
of data, sizes megabytes and above.  The issues are that iterators are
invalid after the content changes and replacing UTF-8 characters by
index gets exponentially slower as the size of the string increases.
Hence the > 48 hours of 100% CPU time to read and apply the line
discipline to the 122 MiB of fsck.fat output.  See code comment for a
more detailed description of the issues found.

Rewrote OnReadable() to use Glib::ustrings as little as possible.
Instead using buffers and vectors of fixed width data types allowing for
fast access using pointers and indexes (converted to pointers by the
compiler with simple arithmetic).  Again see code comment for a more
detailed description of the implementation.

Repeating the performance capture with the new code for the first 1 MiB
of fsck.fat output:
      63.34% memcpy                      [0.35s]
    [ 36.66% (everything else)       ]   [0.21s]
    [100.00% TOTAL                   ]   [0.56s]

And for the first 10 MiB of fsck.fat output:
      96.66% memcpy                      [63.60s]
    [  3.34% (everything else)       ]   [ 2.20s]
    [100.00% TOTAL                   ]   [65.80s]

Simple timings taken to read portions of the fsck.fat output (when not
using perf):

                   1 MiB    10 MiB      122 MiB
    old code :   6.2 sec   277 sec   > 48 hours
                            (4:37)
    new code :   0.6 sec    66 sec    17262 sec
                            (1:06)    (4:47:42)

Performance of the code is still non-linear because of the assignment
of the ever growing capturebuf to callerbuf for every block of input
read.  This is required to generate a consistent Glib::ustring copy of
the input for the update callback.  However this is much faster than
before, and I have a plan for further improvements.

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood 69d1bbcf8f Remove old .cvsignore files
As the source code is managed in GIT and there is a .gitignore file in
the top level directory specifying file names to exclude from version
control, then the old per-directory .cvsignore files for CVS are
redundant.

Add the only missing and applicable entry from src/.cvsignore of '.libs'
to .gitignore and remove all the .cvsignore files.
2017-06-02 10:47:35 -06:00
Mike Fleetwood 75131d85a5 Fix snap-to-alignment of operations creating partitions (#779339)
Using the default MiB alignment, creating an MSDOS logical partition
between two other existing logical partitions fails with this error
dialog:

    (-) <b>An error occurred while applying the operations</b>
        See the details for more information.
        <b>IMPORTANT</b>
        If you want support, you need to provide the saved details!
        See http://gparted.org/save-details.htm for more information.
                                                               [ OK ]

and these operation details:

    + libparted messages
      - Unable to satisfy all constraints on the partition.

This bug was introduced by this commit included in GParted 0.23.0:
    90e3ed68fc
    Shallow copy Device object into Operation object (#750168)

The commit message claimed that the deep copied Partition objects inside
the Device inside the Operation object are never accessed.  This turned
out not to be true.  Win_GParted::Add_Operation() uses them as part of
snap_to_alignment() which updates requested partition boundaries to
account for alignment requirements and the space needed for EBR
(Extended Boot Record) preceding logical partitions.

In this case the new logical partition was trying to be created over the
top of the EBR for the following logical partition because
snap_to_alignment() wasn't aware of its existence.

Fix by making Add_Operation() and snap_to_alignment() refer to the
current device, as displayed in the UI, rather than the shallow copy
included in the Operation object.  Hopefully now it is true that the
not copied vector of Partition objects in the Device object in each
Operation object are never accessed.

Bug 779339 - enforce at least 1 MiB "free space following"
2017-04-23 08:57:25 -06:00
Mike Fleetwood aa98107706 Create and use general find_extended_partition() function
The Operation class already provided find_index_extended() method and
 was used in the Operation and derived classes where required.  It
returns the index to the extended partition in the PartitionVector
object, or -1 when no extended partition exists.

There were several cases of the same functionality being open coded in
GParted_Core and Win_GParted.  Therefore move the implementation to
find_extended_partition() in PartitionVector compilation unit and use
this implementation everywhere.
2017-01-14 08:49:58 -07:00
Mike Fleetwood 786a53b43c Replace 2 Win_GParted member variables with local variables
Member variables fs and gpart_output were used in just one method each
as local variables.  Replace them with local variables.
2017-01-14 08:49:58 -07:00
Mike Fleetwood 0f76b8f8ff Remove unused clear_mountpoints parameter from add_mountpoint*()
The clear_mountpoints parameter has never been used since
add_mountpoint*() were first added [1][2].  clear_mountpoints() method
[3] is available to provide this functionality and used.  Therefore
removed unused parameter and code.

[1] add_mountpoints() added 2006-03-15
        9532c3cad1
        Made Partition::mountpoints private

[2] add_mountpoint() added 2011-12-16
        208083f11d84dbd4f186271a3cdbf5170db259f8b8
        Display LVM2 VGNAME as the PV's mount point (#160787)

[3] clear_mountpoint() added 2006-03-19
        ad9f2126e7
        fixed issues with copying (see also #335004) cleanups + added FIXME added
2017-01-14 08:49:58 -07:00
Mike Fleetwood 36804b9634 Implement maximize encryption volume as part of check repair operation (#774818)
Now that resizing of encrypted file systems is implemented add growing
of the open LUKS mapping as part of the check repair operation.

Resizing an encrypted file system requires the LUKS mapping to be open
to access the file system within; therefore it also requires libparted
and kernel support for online partition resizing.  This limits resizing
to the latest distributions with libparted >= 3.2 and kernel >= 3.6.
However growing an open LUKS mapping as part of a check repair operation
doesn't require resizing the partition.  Therefore route via offline
grow of LUKS to avoid those extra, unnecessary requirement.  This does
mean that offline LUKS grow artificially requires cryptsetup, but that is
not really significant as even opening LUKS requires cryptsetup.

So now checking an encrypted file system on even the oldest
distributions does:
1) runs FSCK on the encrypted file system;
2) grows the encryption volume to fill the partition;
3) grows the file system to fill the encryption mapping.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood 828f0d8ab3 Implement resize/move operation of encrypted file systems (#774818)
Moving of closed LUKS is simply enabled by luks .move capability being
set and requires no further coding.

Resizing of encrypted file systems requires both the LUKS mapping and
encrypted file system within to be resized in the right order for both
shrinking and growing.  To keep the code simple split resizing of plain
and encrypted into separate functions.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood ee1b2257d2 Preview resize/move operation of encrypted file systems (#774818)
Changing the Resize/Move dialog code to also handle PartitionLUKS
objects was considered too complicated.  Instead create an unencrypted
equivalent using clone_as_plain(), pass that to the Resize/Move dialog
and finally apply the change back using Partition*::resize().

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood 08e4ba4eca Add Partition object resizing method Partition*::resize() (#774818)
Add a resize() method to both Partition and PartitionLUKS classes.  They
take a reference Partition object, and update the position, size and
file system usage of *this Partition to match.  This is ready for taking
a partition returned from Resize/Move dialog and applying the change.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood 30a0f4506c Add specialist clone method PartitionLUKS::clone_as_plain() (#774818)
Implement a specialist PartitionLUKS clone method.  Creates a new
Partition object which has the same space usage as the source encrypted
file system, but is a plain file system.  Namely, the overhead of the
LUKS header has been added to the file system usage.  This is ready for
feeding this representation of the partition to the Resize/Move dialog.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood 88136c96d7 Extend functions generating encrypted file system string (#774818)
Already have:
    Utils::get_filesystem_string(FS_EXT2)          -> "ext2"
    virtual Partition::get_filesystem_string()     -> "ext2"
    virtual PartitionLUKS::get_filesystem_string() -> "[Encrypted] ext2"
Add these:
    Utils::get_encrypted_string()                  -> "[Encrypted]"
    Utils::get_filesystem_string(false, FS_EXT2)   -> "ext2"
    Utils::get_filesystem_string(true, FS_EXT2)    -> "[Encrypted] ext2"

This is ready for use of Utils::get_filesystem_string(true, FS_EXT2)
when composing the preview of a format of an encrypted file system by
Win_GParted::activate_format().

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood 3ba7128d55 Implement new UUID operation on encrypted file systems (#774818)
When composing, describing and implementing the operation just need the
code to query and set the Partition object directly containing the file
system, instead of the enclosing encryption mapping to make it work.

The operation details for setting a new UUID on an encrypted ext4 file
system become:

    Set a new random UUID on [Encrypted] ext4 file system on /dev/sdb4
    + calibrate /dev/sdb4
    + Set UUID on /dev/mapper/sdb4_crypt to a new, random value
      + tune2fs -U random /dev/mapper/sdb4_crypt
          tune2fs 1.41.12 (17-May-2010)

Also note the now documented rule in apply_operation_to_disk() which
says each operation must leave the status of the encryption mapping and
file system as it found it.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood bd6fc67afb Provide virtual Partition::get_filesystem_string() method (#774818)
Provide and use a single interface for getting the file system string
for display, regardless of whether the partition is encrypted or the
encryption mapping is active or not.

Example return values for get_filesystem_string() for different types
and states of Partition objects:
1)  Plain ext4 file system:          -> "ext4"
2)  Closed encrypted:                -> "[Encrypted]"
3)  Open encrypted ext4 file system: -> "[Encrypted] ext4"

This simplifies the code in TreeView_Detail::create_row() which sets the
file system type displayed in the main window.  The same method will
then also be used when setting the operation description as each
operation is updated to handle encrypted file systems.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood aa49b763e4 Remove virtual PartitionLUKS::get_filesystem_label() (#774818)
The previous commit changed how the code behind the main window
retrieved the file system label for display.  This is the relevant
changes in TreeView_Detail::create_row():

  + const Partition & filesystem_ptn = partition.get_filesystem_partition();
    ...
  - Glib::ustring temp_filesystem_label = partition.get_filesystem_label();
  + Glib::ustring temp_filesystem_label = filesystem_ptn.get_filesystem_label();
    treerow[treeview_detail_columns.label] = temp_filesystem_label;

In the case of an encrypted file system get_filesystem_label() is now
called on the Partition object directly rather than on the outer
Partition object containing the LUKS encryption.

The code behind the Information dialog always obtained and used the
Partition object directly containing the file system to call
get_filesystem_label() since read-only LUKS support was added.
Therefore the virtualised PartitionLUKS::get_filesystem_label() is no
longer needed, so remove it.

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood 53fd80e6ca Provide virtual Partition::get_filesystem_partition() method (#774818)
There are multiple cases of code wanting to work with the Partition
object directly containing the file system, regardless of whether it is
within a PartitionLUKS object or not.  The code had to do something
similar to this to access it:

    const Partition * filesystem_ptn = &partition;
    if ( partition.filesystem == FS_LUKS && partition.busy )
            filesystem_ptn = &dynamic_cast<const PartitionLUKS *>( &partition )->get_encrypted();
    ...
    // Access Partition object directly containing the file system
    filesystem_ptn-> ...

Implement and use virtual accessor get_filesystem_partition() which
allows the code to be simplified like this:

    const Partition & filesystem_ptn = partition.get_filesystem_partition();
    ...
    // Access Partition object directly containing the file system
    filesystem_ptn. ...

Bug 774818 - Implement LUKS read-write actions NOT requiring a
             passphrase
2017-01-14 08:49:58 -07:00
Mike Fleetwood b2190372d0 Ensure blkid FS_Info cache has entries for all whole disk devices (#771244)
More recent versions of blkid don't report an ISO9660 file system on the
whole disk device if partitions can be reports for embedded partitions.
However when querying the whole disk device directly then the expected
ISO9660 file system is reported.  For example on CentOS 7 with the
previous ISO images:

    # wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/isosize/sample.iso.gz
    # dd if=/dev/zero bs=1M of=/dev/sdc
    # zcat sample.iso.gz | dd of=/dev/sdc

    # blkid -v
    blkid from util-linux 2.23.2  (libblkid 2.23.0, 25-Apr-2013)
    # blkid | fgrep /dev/sdc
    /dev/sdc1: UUID="2013-01-04-22-05-45-00" LABEL="ARCH_201301" TYPE="iso9660" PTTYPE="dos"
    # blkid /dev/sdc
    /dev/sdc: UUID="2013-01-04-22-05-45-00" LABEL="ARCH_201301" TYPE="iso9660" PTTYPE="dos"

    # wget http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/debian-8.6.0-amd64-netinst.iso
    # dd if=/dev/zero bs=1M of=/dev/sdc
    # dd if=debian-8.6.0-amd64-netinst.iso bs=1M of=/dev/sdc

    # blkid | fgrep /dev/sdc
    /dev/sdc1: UUID="2016-09-17-14-23-48-00" LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660" PTTYPE="dos"
    /dev/sdc2: SEC_TYPE="msdos" UUID="17F3-1162" TYPE="vfat"
    # blkid /dev/sdc
    /dev/sdc: UUID="2016-09-17-14-23-48-00" LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660" PTTYPE="dos"

This behavioural difference with blkid is probably as a result of newer
versions of udev informing the kernel of the partitions embedded within
the ISO9660 image, and not directly as a result of a change in blkid
itself.  Older distributions don't have partition entries for the above
ISO images, but CentOS 7 (with udev 219) and later distributions do have
partition entries:

    # fgrep sdc /proc/partitions
       8       16    8388608 sdc
       8       17     252928 sdc1
       8       18        416 sdc2

Fix by ensuring that the blkid FS_Info cache has entries for whole disk
devices, even if each entry has all empty attributes because there is a
partition table and not a recognised file system.

Calling blkid on whole disk devices containing partition tables produces
output like this, with newer versions of blkid:

    # blkid /dev/sda
    /dev/sda: PTTYPE="dos"
    # blkid /dev/sdb
    /dev/sdb: PTTYPE="gpt"

This will be loaded into the FS_Info cache as a blank entry for the
device by run_blkid_load_cache().  There will be a path name but all the
other attributes will be blank because there are no TYPE, SEC_TYPE, UUID
or LABEL name value pairs.  With older versions of blkid no output is
produced at all.  In that case load_fs_info_cache_extra_for_path() will
create the same blank entry with just the path name defined.

Bug 771244 - gparted does not recognize the iso9660 file system in
             cloned Ubuntu USB boot drives
2017-01-06 12:21:50 -07:00
Mike Fleetwood fd426cf36e Create new method GParted_Core::set_device_from_disk() (#771244)
Move code from GParted_Core::set_devices_thread() performing top level
population of each Device object during the scan of the drives into new
set_device_from_disk() method.

Bug 771244 - gparted does not recognize the iso9660 file system in
             cloned Ubuntu USB boot drives
2017-01-06 10:47:11 -07:00
Curtis Gedak f762c0cc34 Add detection of iso9660 file system (#771244)
Requires blkid.

Note that FS_LUKS was also moved to more closely match the order in
include/Utils.h

Bug 771244 - gparted does not recognize the iso9660 file system in
             cloned Ubuntu USB boot drives
2017-01-06 10:47:11 -07:00
Mike Fleetwood 029a8eb19d Stop providing a default for FileSystem::resize() fill_partition argument
FileSystem::resize() (and derived) is only ever called from a single
location and always with the fill_partition argument supplied [1].
Therefore providing a default for the argument is unnecessary.  So
remove it.

[1] Since these two commits from 2006-06-17, before GParted 0.3.0, which
    added resize_filesystem() and maximize_filesystem() methods to wrap
    calls to p_filesystem->resize() into a single location:

    08245cd08c
    cleanups in the core and the fs'es (resize)

    2d7fb5700b
    more cleanups in the core and the fs'es (these changelogs are getting
2016-12-12 13:15:34 -07:00
Mike Fleetwood 8979913a3f Remove "../include/" from GParted header #includes
It made the code look a little messy, is easily resolved in the build
system and made the dependencies more complicated than needed.  Each
GParted header was tracked via multiple different names (different
numbers of "../include/" prefixes).  For example just looking at how
DialogFeatures.o depends on Utils.h:

    $ cd src
    $ make DialogFeatures.o
    $ egrep ' [^ ]*Utils.h' .deps/DialogFeatures.Po
     ../include/DialogFeatures.h ../include/../include/Utils.h \
     ../include/../include/../include/../include/../include/../include/Utils.h \
     ../include/../include/../include/Utils.h \

After removing "../include/" from the GParted header #includes, just
need to add "-I../include" to the compile command via the AM_CPPFLAGS in
src/Makefile.am.  Now the dependencies on GParted header files are
tracked under a single name (with a single "../include/" prefix).  Now
DialogFeatures.o only depends on a single name to Utils.h:

    $ make DialogFeatures.o
    $ egrep ' [^ ]*Utils.h' .deps/DialogFeatures.Po
     ../include/DialogFeatures.h ../include/Utils.h ../include/i18n.h \
2016-12-12 13:15:34 -07:00
Mike Fleetwood 2740113dcb Refactor linux-swap recreation (#775932)
Linux-swap is recreated as part of copy, resize and move operations and
the code was special cased to implement that by calling the linux-swap
specific resize method.  However the displayed text always said "growing
file system" and then proceeded to recreate linux swap.  Example
operation:

    Copy /dev/sdb1 to /dev/sdb2
    ...
    + copy file system from /dev/sdb1 to /dev/sdb2
        Partition copy action skipped because linux-swap file system does not contain data
    + grow file system to fill the partition
      + create new linux-swap file system
        + mkswap -L"" -U "77d939ef-54d6-427a-a2bf-a053da7eed4c" /dev/sdb2
            Setting up swapspace version 1, size = 262140 KiB
            LABEL=, UUID=77d939ef-54d6-427a-a2bf-a053da7eed4c

Fix by writing recreate_linux_swap_filesystem() method with better
messaging and use everywhere maximise_filesystem() was previously used
to recreate linux-swap.  Also as this is a create step, erase the
partition first to prevent the possibility of any other file system
signatures being found afterwards.  Now the operation steps are more
reflective of what is actually being performed.

    Copy /dev/sdb1 to /dev/sdb2
    ...
    + copy file system from /dev/sdb1 to /dev/sdb2
        Partition copy action skipped because linux-swap file system does not contain data
    + clear old file system signatures in /dev/sdb2
    + create new linux-swap file system
      + mkswap -L"" -U "77d939ef-54d6-427a-a2bf-a053da7eed4c" /dev/sdb2
          Setting up swapspace version 1, size = 262140 KiB
          LABEL=, UUID=77d939ef-54d6-427a-a2bf-a053da7eed4c

Bug 775932 - Refactor mostly applying of operations
2016-12-12 13:15:34 -07:00
Mike Fleetwood a0158abbeb Refactor resizing file system apply methods (#775932)
resize_filesystem() was meeting two different needs:
1) when called with fill_partition = false it generated operation
   details;
2) when called from maximize_filesystem() with fill_partition = true it
   skipped generating any operation details;
then ran the switch statement to select the resize implementation.  So
extract the common switch statement into new method
resize_filesystem_implement().

Then observe that the only time resize_filesystem() was called to grow
the file system was when re-creating linux-swap.  Therefore change that
call to use maximize_filesystem() and rename to shrink_filesystem() and
modify the operation detail messages to match.

Bug 775932 - Refactor mostly applying of operations
2016-12-12 13:15:34 -07:00
Mike Fleetwood 0420159c1d Rename a few GParted_Core apply related methods (#775932)
Make the methods called below apply_operation_to_disk() follow a
standard naming convention:

 *  Contains "_partition"
    Uses libparted to query or change the partition in the disk label
    (partition table).
    E.g.:
        calibrate_partition()
        create_partition()
        delete_partition()
        name_partition()
        resize_move_partition()
        set_partition_type()

 *  Contains "_filesystem"
    Manipulates the file system within the partition, mostly using the
    FileSystem and derived class methods.
    E.g.:
        create_filesystem()
        remove_filesystem()
        label_filesystem()
        copy_filesystem()
        erase_filesystem_signatures()
        check_repair_filesystem()
        resize_filesystem()
        maximize_filesystem()

 *  Other
    Compound method calling multiple partition and file system related
    apply methods.
    E.g.:
        create()
        format()
        copy()
        resize_move()
        resize()
        move()

Rename:
    Delete()      -> delete_partition()
    change_uuid() -> change_filesystem_uuid()

Bug 775932 - Refactor mostly applying of operations
2016-12-12 13:15:34 -07:00
Mike Fleetwood 9f08875997 Make encrypted Partition objects look like whole disk device ones (#775932)
Until now an encryption mapping has been modelled as a Partition object
similar to a partition like this:
    .encrypted.device_path  = "/dev/sdb1"
    .encrypted.path         = "/dev/mapper/sdb1_crypt"
    .encrypted.whole_device = false
    .encrypted.sector_start = // start of the mapping in the partition
    .encrypted.sector_end   = // end of the mapping in the partition
However accessing device_path in the start to end sector range is not
equivalent to accessing the partition path as it doesn't provide access
to the encrypted data.  Therefore existing functions which read and
write partition data (GParted file system copying and signature erasure)
via libparted using the device_path won't work and will in fact destroy
the encrypted data.  This could be coded around with an extra case in
the device opening code, however it is not necessary.

An encrypted block special device /dev/mapper/CRYPTNAME looks just like
a whole disk device because it doesn't contain a partition and the file
system it contains starts at sector 0 and goes to the end.  Therefore
model an encryption mapping in the same way a whole disk device is
modelled as a Partition object like this:
    .encrypted.device_path  = "/dev/mapper/sdb1_crypt"
    .encrypted.path         = "/dev/mapper/sdb1_crypt"
    .encrypted.whole_device = true
    .encrypted.sector_start = 0
    .encrypted.sector_end   = // size of the encryption mapping - 1
Now GParted file system copy and erasure will just work without any
change.  Just need to additionally store the LUKS header size, which was
previous stored in the sector_start, for use in the
get_sectors_{used,unused,unallocated}() calculations.

Bug 775932 - Refactor mostly applying of operations
2016-12-12 13:15:34 -07:00
Mike Fleetwood 0b359a5490 Refactor GParted_Core::copy() (#775932)
Split out the switch statement selecting the copy implementation and
associated copy file system operation detail message into a separate
copy_filesystem() method, matching how a number of other operations are
coded.  This is why the previous copy_filesystem() methods needed
renaming.

Re-write the remaining copy() into if-operation-fails-return-false style
to simplify it.  Re-write final complicated conditional check repair and
maximise file system into separate positive if conditions for swap and
larger partition to make it understandable.

The min_size parameter to copy() was queried from the partition_src
parameter also passed to copy().  Drop the parameter and query inside
copy() instead.

Bug 775932 - Refactor mostly applying of operations
2016-12-12 13:15:34 -07:00