Commit Graph

3828 Commits

Author SHA1 Message Date
Mike Fleetwood 8280f3eedc Correctly const and assert detect_filesystem() parameters (#152)
As discussed in the previous commit "Don't crash probing libparted
unrecognised encrypted file system (#152)", detect_filesystem() accepted
a NULL lp_device pointer and dereferenced it leading to the crash.
Document the requirement for lp_device parameter to be non-NULL via an
assert and also correctly const the parameters.

This forces needing to const the lp_partition parameter to
get_partition_path() too.  Also assert it's non-NULL requirement.

Closes #152 - GParted crashed when trying to probe an encrypted
              partition containing content that libparted doesn't
              recognise
2021-04-15 16:33:01 +00:00
Mike Fleetwood 09df074a92 Don't crash probing libparted unrecognised encrypted file system (#152)
Create a LUKS encrypted partition and open it.  Then either leave the
contents blank or create a file system which libparted doesn't
recognise, such as: exfat, f2fs, lvm2 pv, minix or reiser4.  When
GParted probes the disk device it crashes.

    # echo -n badpassword | cryptsetup luksFormat /dev/sdb11
    # echo -n badpassword | cryptsetup luksOpen /dev/sdb11 sdb11_crypt
    # ./gpartedbin /dev/sdb
    GParted 1.2.0-git
    configuration (none)
    libparted 3.1
    /dev/mapper/sdb11_crypt: unrecognised disk label
    Segmentation fault (core dumped)

Backtrace:
    #0  0x0000000000460f68 in GParted::GParted_Core::detect_filesystem(_PedDevice*, _PedPartition*, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
        (lp_device=0x0, lp_partition=0x0, messages=std::vector of length 0, capacity 0)
        at GParted_Core.cc:1235
    #1  0x00000000004615a6 in GParted::GParted_Core::detect_filesystem_in_encryption_mapping(Glib::ustring const&, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
        (path=..., messages=std::vector of length 0, capacity 0)
        at GParted_Core.cc:1096
    #2  0x00000000004647c8 in GParted::GParted_Core::set_luks_partition(GParted::PartitionLUKS&)
        (this=this@entry=0x7fff43f974e0, partition=...)
        at GParted_Core.cc:1011
    #3  0x000000000046511b in GParted::GParted_Core::set_device_partitions(GParted::Device&, _PedDevice*, _PedDisk*)
        (this=this@entry=0x7fff43f974e0, device=..., lp_device=0x7efc780008c0, lp_disk=0x7efc78000d10)
        at GParted_Core.cc:883
    #4  0x00000000004658e3 in GParted::GParted_Core::set_device_from_disk(GParted::Device&, Glib::ustring const&)
        (this=this@entry=0x7fff43f974e0, device=..., device_path=...)
        at GParted_Core.cc:704
    #5  0x0000000000465fff in GParted::GParted_Core::set_devices_thread(std::vector<GParted::Device, std::allocator<GParted::Device> >*)
        (this=0x7fff43f974e0, pdevices=0x7fff43f96bc8)
        at GParted_Core.cc:266
    #6  0x00007efc99ba413d in call_thread_entry_slot ()
        at /lib64/libglibmm-2.4.so.1
    #7  0x00007efc97dc8555 in g_thread_proxy ()
        at /lib64/libglib-2.0.so.0
    #8  0x00007efc96ab4ea5 in start_thread () at /lib64/libpthread.so.0
    #9  0x00007efc967dd9fd in clone () at /lib64/libc.so.6

The relevant sequence of events goes like this:
    detect_filesystem_in_encryption_mapping(path, ...)
      lp_device = NULL
      get_device(path, lp_device)
        lp_device = ped_device_get(path.c_str())
        return true
      lp_disk = NULL
      lp_partition = NULL
      get_disk(lp_device, lp_disk)  // + default parameter strict=true
        lp_disk = ped_disk_new(lp_device)
          // No libparted recognised disk label or file system found, so
          // NULL returned.
        destroy_device_and_disk(lp_device, lp_disk)
          ped_device_destroy(lp_device)
          lp_device = NULL
        return false
      detect_filesystem(lp_device, lp_partition, ...)
        path = lp_device->path

The key points are:
1. get_device() created a PedDevice object pointed to by lp_device;
2. get_disk() didn't find a libparted recognised disk label or file
   system but also unexpectedly destroyed the PedDevice object and
   assigned NULL to lp_device;
3. detect_filesystem() dereferenced lp_device assuming it was still
   valid.

Implement the simplest possible fix by telling get_disk() to not
destroy the needed PedDevice object when there's no recognised content.
This is the same as how get_disk() is called in set_device_from_disk().

Closes #152 - GParted crashed when trying to probe an encrypted
              partition containing content that libparted doesn't
              recognise
2021-04-15 16:33:01 +00:00
Hugo Carvalho 20a06d00b5 Update Portuguese translation 2021-04-14 21:02:58 +00:00
Mike Fleetwood 1adb28b0c4 Also use libparted to probe for encrypted file systems (#148)
Even though blkid is considered mandatory [1] GParted should still
perform reasonably when blkid is not available, provided that is not too
onerous a task.  Also use libparted file system identification inside
encryption mappings.

[1] 749a249571
    Document blkid command as a mandatory requirement (#753436)

Closes 148 - Encrypted file systems are no longer recognised
2021-04-03 17:02:04 +00:00
Mike Fleetwood 555cea10cf Probe encryption mappings as needed using blkid (#148)
GParted no longer recognises file systems inside LUKS encryption, apart
from the few recognised by GParted's internal detection.  Bisected to
this commit:
    8b35892ea5
    Pass device and partition names to blkid (#131)

Prior to this commit blkid was run querying all known block devices
including active encryption mappings, hence prior recognition.  With
this commit blkid was run only for named or found disk devices and
associated found partitions from /proc/partitions, so no more
recognition of encrypted file systems.

Fix by running blkid on the encryption mapping just before querying for
the file system.  This restores the level of functionality that existed
before.

Closes 148 - Encrypted file systems are no longer recognised
2021-04-03 17:02:04 +00:00
Mike Fleetwood 1e91cb831b Extract some code into detect_filesystem_in_encryption_mapping() (#148)
To avoid making set_luks_partition() more complicated extract the file
system detection portion into a new function.

Closes 148 - Encrypted file systems are no longer recognised
2021-04-03 17:02:04 +00:00
Mike Fleetwood 1e813d83a5 Make FS_Info (blkid) cache incrementally loadable (#148)
Since changes for issue #131 "GParted hangs when non-named device is
hung" FS_Info cache is initialised, cleared and loaded via one call to
load_cache_for_paths().  It runs blkid for named or found disk devices
and associated found partitions from /proc/partitions, rather than
running blkid and letting it report for all block devices.

To avoid the possibility of using blkid on an encryption mapping on a
non-specified and possibly hung block device GParted can't just specify
all encryption mappings.  Instead only encryption mappings which belong
to the above identified block devices should be probed.  That requires
identifying LUKS encryption data in the block devices first so will
require subsequently loading additional data into the FS_Info cache and
running blkid again.

To accommodate this make the FS_Info cache incrementally loadable,
rather than doing everything in a single call to load_cache_for_paths().
Have a separate clear_cache() call which initialises and clears the
cache and make load_cache_for_paths() just run blkid and insert data for
the named paths.

Closes 148 - Encrypted file systems are no longer recognised
2021-04-03 17:02:04 +00:00
Nathan Follens 5cacb02015 Update Dutch translation 2021-04-02 14:41:55 +00:00
Anders Jonsson 64ea7abcd3 Update Swedish translation 2021-03-27 20:46:31 +00:00
Hugo Carvalho cacfe88d39 Update Portuguese translation 2021-03-25 22:11:30 +00:00
Mike Fleetwood 7e441c8d87 Update HACKING file with coding style hints and tips 2021-03-24 16:22:41 +00:00
Mike Fleetwood 690fedfff9 Explicitly read the reiser4 volume UUID when present
Reiser4 has introduced new disk format which includes support for
spanning the file system over multiple block devices (subvolumes)
[1][2].  As such the output of the debugfs.reiser4 for the UUID has
changed slightly.  So far the new reiser4progs package (version 2.0.x)
is only available as a Debian experimental package.

Using reiser4progs 1.2.1 the old output was like this:

    $ debugfs.reiser4 test.img
    debugfs.reiser4 1.2.1
    Format release: 4.0.2
    Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.

    Master super block (16):
    magic:          ReIsEr4
    blksize:        4096
    format:         0x0 (format40)
    uuid:           1116afce-99fd-4a6e-94cb-2d9f19c91d67
    label:          <none>

    ...

With reiser4progs 2.0.4 the new output is like this:

    $ debugfs.reiser4 test.img
    debugfs.reiser4
    Package Version: 2.0.4
    Software Framework Release: 5.1.3
    Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
    Master super block (16):
    magic:          ReIsEr4
    blksize:        4096
    volume:         0x1 (asym)
    distrib:        0x1 (fsx32m)
    format:         0x1 (format41)
    description:    Standard layout for logical volumes.
    stripe bits:    14
    mirror id:      0
    replicas:       0
    volume uuid:    9538bfa3-5694-4abe-864c-edc288a9d801
    subvol uuid:    d841c692-2042-49e6-ac55-57e454691782
    label:          <none>

    ...

GParted happens to read the correct UUID just because the first matching
"uuid" string in the output is the volume UUID.  Make the code more
robust by explicitly reading the volume uuid when labelled as such.

[1] Logical Volumes Howto
    https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Howto
[2] Logical Volumes Background
    https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Background
2021-03-24 16:22:41 +00:00
Mike Fleetwood 2a76af5beb Refactor reiser4::read_uuid() into if fail return early pattern 2021-03-24 16:22:41 +00:00
Mike Fleetwood 975d9ecdc9 Ignore test failure when reiser4 reports null UUID (#145)
The GitLab CI ubuntu_test job has occasionally been failing like this,
perhaps once every few weeks or so.

    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
    test_SupportedFileSystems.cc:569: Failure
    Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4, where GetParam() = 24 (17 ms)
    [----------] 1 test from My/SupportedFileSystemsTest (17 ms total)

Turns out there are 2 bugs in resier4progs.  One causes debugfs.reiser4
to report a null UUID if the first byte of the UUID happens to be zero
[1], and the other cases mkfs.resier4 to write a corrupted UUID,
sometimes a null (all zeros) UUID [2].

There is a 1 in 256 chance of getting a null UUID [2] when creating and
reading a reiser4 file system, hence the occasional failure of the CI
job.  The centos_test job isn't affected because CentOS doesn't have the
reiser4progs package.

Fix this by detecting when reiser4 reports a null UUID and assign a
dummy UUID to make the test pass.  This does mean that there is a 1 in
256 chance of not detecting a true failure.  However that still means
there is a 255 in 256 chance of detecting a true failure.  That's good
odds.  When a null UUID is detected for a reiser4 file system the test
output looks like this:

    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
    test_SupportedFileSystems.cc:580: Ignore test failure of a null UUID.
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 (46 ms)

[1] 4802cdb18a
    Fix up repair_master_print()

[2] 44cc024f39
    Stop occasionally making file systems with null UUIDs

Closes #145 - Sporadic failure of test case
              My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
2021-03-24 16:22:41 +00:00
Jordi Mas 3d7c5db355 Update Catalan translation 2021-03-13 21:53:11 +01:00
Mike Fleetwood b3f5213207 Print kernel version, etc in GitLab CI (#147)
Print the kernel version and supported file systems inside the GNOME
GitLab CI jobs as a debugging aid.  Kernel version helps identify the
CI job runner's distribution to identify kernel features.  Supported
file systems identifies which ones can be mounted, should that be
possible in future.  Print supported file systems before and after the
tests because checking for support may load additional modules.  See
calls to Utils::kernel_supports_fs() for: btrfs, jfs, nilfs2 and xfs.

Closes #147 - GitLab CI test failure from *.CreateAndGrow/jfs
2021-03-11 16:44:50 +00:00
Mike Fleetwood 30ff497c6e Exclude more GitLab CI file system tests needing loop devices (#147)
For the first time ever the ubuntu_test GitLab CI job failed running the
JFS grow test like this.  Fragment from tests/test-suite.log:

    [ RUN      ] My/SupportedFileSystemsTest.CreateAndGrow/jfs
    test_SupportedFileSystems.cc:387: Failure
    Failed
    create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
    losetup: cannot find an unused loop device
    create_loopdev(): Losetup failed with exit status 1
    create_loopdev(): Failed to create required loop device
    Error: Could not stat device  - No such file or directory.
    test_SupportedFileSystems.cc:446: Failure
    Value of: lp_device != NULL
      Actual: false
    Expected: true
    test_SupportedFileSystems.cc:649: Failure
    Value of: m_fs_object->create(m_partition, m_operation_detail)
      Actual: false
    Expected: true
    Operation details:
    mkfs.jfs -q -L '' ''    00:00:00  (ERROR)
    mkfs.jfs version 1.1.15, 04-Mar-2011

    The system cannot find the specified device.

    detach_loopdev(): Execute: losetup --detach ''
    losetup: : failed to use device: No such device
    detach_loopdev(): Losetup failed with exit status 1
    detach_loopdev(): Failed to detach loop device.  Test NOT affected
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndGrow/jfs, where GetParam() = 17 (24 ms)

JFS can only be grown when mounted by the kernel and GParted only
enables JFS grow support when, among other things, kernel support is
detected.

Unknowingly the JFS grow test had always previously been skipped, even
in the ubuntu_test CI job which installs jfsutils, because the kernel
didn't support JFS.  Capture of this test from another run of the
ubuntu_test CI job:

    [ RUN      ] My/SupportedFileSystemsTest.CreateAndGrow/jfs
    test_SupportedFileSystems.cc:641: Skip test.  grow not supported or support not found
    [       OK ] My/SupportedFileSystemsTest.CreateAndGrow/jfs (0 ms)

Plus additional debug added into the job based on what
Utils::kernel_supports_fs() does to identify kernel support:

    $ fgrep jfs /proc/filesystems || true
    $ modprobe jfs || true
    modprobe: FATAL: Module jfs not found in directory /lib/modules/3.10.0-1160.11.1.el7.x86_64
    $ fgrep jfs /proc/filesystems || true

Therefore until now every GitLab job runner machine kernel didn't
support JFS, but for the first time ever this ubuntu_test job ran on a
runner machine where the kernel did support JFS, hence the attempt to
use losetup.

Examining test_SupportFileSystems.cc there are 24 file system tests
which specify SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS(), but only
17 exclusions in .gitlab-ci.yaml [1].  The 7 tests without exclusions
are:

    *.CreateAndReadLabel/lvm2pv
    *.CreateAndReadUUID/lvm2pv
    *.CreateAndWriteLabel/lvm2pv
    *.CreateAndWriteUUID/lvm2pv
    *.CreateAndGrow/jfs
    *.CreateAndGrow/nilfs2
    *.CreateAndShrink/nilfs2

For LVM2 PVs reading and writing of labels and UUIDs aren't implemented
(only reading of UUIDs could be supported as the others are impossible)
so those tests are always skipped.  Add unit test exclusions just for
completeness.

JFS grow is this case.  NILFS2 grow and shrink are more cases where
kernel support is needed.  Add unit test exclusions to stop attempting
to run JFS and NILFS2 resizing tests, which don't currently work because
losetup doesn't work in the GitLab CI docker images [1].

[1] 39fdfe51da
    Exclude unit tests needing losetup in Docker CI image (!59)

Closes #147 - GitLab CI job failure from *.CreateAndGrow/jfs
2021-03-11 16:44:50 +00:00
Mike Fleetwood a41e8b03ec Pass constant string by reference to lvm2_pv_size_to_num()
It is common C++ practice to pass a constant object by reference to
avoid constructing a duplicate object for pass by value [1].

[1] How to pass objects to functions in C++?
    https://stackoverflow.com/questions/2139224/how-to-pass-objects-to-functions-in-c/2139254#2139254
2021-03-10 16:40:44 +00:00
Mike Fleetwood c0a7aa438a Install gpartedbin into @libexecdir@ (#85)
Executables which are not intended for execution by users, but by other
programs, should be installed into /usr/libexec [1][2].  gpartedbin
falls into this category.  Update it's installation accordingly.

Standard Autotools details: gpartedbin will be installed into
EPREFIX/libexec by default.  To install gpartedbin into a different
directory set libexecdir when configuring the build system.  Like this
from git:
    ./autogen.sh --libexecdir=DIR
or like this from tar release:
    ./configure --libexecdir=DIR

[1] Filesystem Hierarchy Standard, version 3.0,
    4.7. /usr/libexec : Binaries run by other programs (optional)
    https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
    "/usr/libexec includes internal binaries that are not intended to be
    executed directly by users or shell scripts.
    "

[2] GNU Coding Standards, June 12, 2020,
    7.2.5 Variables for Installation Directories
    https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
    "libexecdir
    The directory for installing executable programs to be run by other
    programs rather than by users.  This directory should normally be
    /usr/local/libexec, but write it as $(exec_prefix)/libexec.  (If you
    are using Autoconf, write it as '@libexecdir@'.)
    "

Closes #85 - Please install gpartedbin under /usr/libexec instead of
             /usr/sbin
2021-03-10 16:40:44 +00:00
Aurimas Černius 2dd2aa5ebb Updated Lithuanian translation 2021-03-08 22:34:43 +02:00
Kukuh Syafaat a7c35420ad Update Indonesian translation 2021-03-05 12:22:22 +00:00
Mike Fleetwood 4a6e79daa3 Update "Detecting BitLocker" URL code comment
The document has moved on the Microsoft website.  Update the URL
accordingly, and add an Internet Archive URL too, for good measure.
2021-03-04 16:55:06 +00:00
Mike Fleetwood a11c16445b Rename member variable to default_fs
... in class Dialog_Partition_New and slightly refactor the code in
build_filesystems_combo() method which sets it.

Change the name from first_creatable_fs to default_fs to be more
immediately obvious what the variable represents.  As default_fs is used
to index the items in the combo_filesystem derived ComboBox, make it's
type an int to match the type of the parameter passed to
Gtk::ComboBox::set_active() [1].  Initialise default_fs to -1 (no
selection) in the class constructor [2], which also allows removal of
local variable set_first just used to track whether first_creatable_fs
had been assigned yet or not.

[1] gtkmm: Gtk::ComboBox Class Reference, set_active()
    https://developer.gnome.org/gtkmm/stable/classGtk_1_1ComboBox.html#a4f23cf08e85733d23f120935b235096d

[2] C++ FAQ / Should my constructors use "initialization lists" or
    "assignment"?
    https://isocpp.org/wiki/faq/ctors#init-lists
2021-03-04 16:55:06 +00:00
Mike Fleetwood a97f1240fb Don't rely on unformatted being the last file system type
... in Dialog_Partition_New::build_filesystems_combo().  set_data()
populates this->FILESYSTEMS[] vector with supported file systems with
cleared, unformatted and extended added to the end.  Then
build_filesystems_combo() adds those items to combo_filesystem, skipping
extended.  It then makes the last item in the combobox sensitive,
relying on the fact that it is unformatted.

Refactor the code so build_filesystems_combo() no longer relies on
unformatted being the last item in combo_filesystem to always enable it.
2021-03-04 16:55:06 +00:00
Mike Fleetwood eb5ad50fef Remove unnecessary call to combobox_changed(false)
... in Dialog_Partition_New::set_data().  As the change signal for
combo_filesystem has already been connected, combo_changed(false) is
automatically called by setting the active selection.  Therefore remove
the unnecessary call.
2021-03-04 16:55:06 +00:00
Mike Fleetwood 400fc8397e Rename combobox_change() parameter to combo_type_changed
"Type" was rather a generic name.  Use "combo_type_changed" which makes
it clear that the boolean parameter indicates whether a change to
combo_type or one of the other ComboBoxes triggered this callback.
2021-03-04 16:55:06 +00:00
Mike Fleetwood e91db19e30 Fix crash in Create New Partition dialog when changing type (#101)
On an MSDOS partitioned drive, open the Create New Partition dialog and
change "created as" from Primary Partition to Extended Partition and
back to Primary Partition.  On Fedora and RHEL/CentOS 8, which builds
packages with FORTIFY_SOURCE [1][2] and GLIBXX_Assertions [3][4]
enabled, GParted will crash.

Run GParted built with the default compilation options under valgrind
and repeat the test.  Multiple out of bounds reads are reported like
this:
  # valgrind --track-origins=yes ./gpartedbin
  ...
  ==232613== Invalid read of size 8
  ==232613==    at 0x441AF6: GParted::Dialog_Partition_New::combobox_changed(bool) (Dialog_Partition_New.cc:354)
  ==232613==    by 0x443DBD: sigc::bound_mem_functor1<void, GParted::Dialog_Partition_New, bool>::operator()(bool const&) const (mem_fun.h:2066)

Coming from Dialog_Partition_New.cc:
  328  void Dialog_Partition_New::combobox_changed(bool type)
  329  {
  ...
  351      // combo_filesystem and combo_alignment
  352      if ( ! type )
  353      {
> 354          fs = FILESYSTEMS[combo_filesystem.get_active_row_number()];

When the partition type is changed to Extended the file system is forced
to be "Extended" too.  This is done in ::combobox_changed() method by
modifying combo_filesystem to add "Extended", making that the selected
item and setting the widget as inactive.

Then when the partition type is changed back to primary the file system
combobox is returned to it's previous state.  This is done by first
removing the last "Extended" item, making the widget active and setting
the selected item.  However as "Extended" is the currently selected
item, removing it forces their to be no selected item and triggers a
change to combo_filesystem triggering a recursive call to
::combobox_changed() where combo_filesystem.get_active_row_number()
returns -1 (no selection) [5] and on line 354 the code accesses item -1
of the FILESYSTEMS[] vector.

Fix by setting the new combo_filesystem selection before removing the
currently selected "Extended" item.  This has the added benefit of only
triggering a change to combo_filesystem once when the default item is
selected rather than twice when the currently "Extended" item is removed
and again when the default item is selected.

[1] [Fedora] Security Features, Compile Time Buffer Checks
    (FORTIFY_SOURCE)
    https://fedoraproject.org/wiki/Security_Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29

[2] Enhance application security with FORTIFY_SOURCE
    https://access.redhat.com/blogs/766093/posts/1976213

[3] Security Features Matrix (GLIBXX_Assertions)
    https://fedoraproject.org/wiki/Security_Features_Matrix

[4] GParted 1.2.0-1.fc33 package build.log for Fedora 33
    https://kojipkgs.fedoraproject.org/packages/gparted/1.2.0/1.fc33/data/logs/x86_64/build.log
    CXXFLAGS='-O2 -g ... -Wp,-D_FORTIFY_SOURCE=2
    -Wp,-D_GLIBCXX_ASSERTIONS ...'

[5] gtkmm: Gtk::ComboBox Class Reference, get_active_row_number()
    https://developer.gnome.org/gtkmm/stable/classGtk_1_1ComboBox.html#a53531bc041b5a460826babb8496c363b

Closes #101 - Crash changing Partition type in "Create new partition"
              dialog
2021-03-04 16:55:06 +00:00
Yuri Chornoivan 85c76b75d2 Fix minor typos in comments (!71)
Closes !71 - Fix minor typos in comments
2021-02-26 14:20:16 +00:00
Anders Jonsson 93baad9bfe Update Swedish translation 2021-02-23 16:48:15 +00:00
Yuri Chornoivan 95b389ae46 Update Ukrainian translation 2021-02-22 16:58:19 +00:00
Mike Fleetwood 4a2e63d60a Update SystemRescue name and URL in the GParted Manual
SystemRescue have dropped CD from their name and URL.  Update the
GParted Manual to reflect this.
2021-02-22 16:14:35 +00:00
Mike Fleetwood b711bcbfd5 Re-enable PipeCapture read NUL byte unit tests in GitLab CI jobs (#136)
This reverts commit:
    e9223207e6.
    Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60)
now that PipeCapture has been fixed to read NUL characters again.

Closes #136 - 1.2.0: test suite is failing in test_PipeCapture
2021-02-22 16:14:35 +00:00
Mike Fleetwood 7dbf0691f1 Accept NUL as a valid UTF-8 character again (#136)
On newer distributions the PipeCapture tests have been failing like
this:
    $ ./test_PipeCapture
    ...
    [ RUN      ] PipeCaptureTest.ReadEmbeddedNULCharacter
    test_PipeCapture.cc:336: Failure
          Expected: inputstr
         Of length: 6
    To be equal to: capturedstr.raw()
         Of length: 5
    With first binary difference:
    < 0x00000000  "ABC.EF"            41 42 43 00 45 46
    --
    > 0x00000000  "ABCEF"             41 42 43 45 46
    [  FAILED  ] PipeCaptureTest.ReadEmbeddedNULCharacter (0 ms)
    [ RUN      ] PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character
    test_PipeCapture.cc:353: Failure
          Expected: expectedstr
         Of length: 7
    To be equal to: capturedstr.raw()
         Of length: 6
    With first binary difference:
    < 0x00000000  "._45678"           00 5F 34 35 36 37 38
    --
    > 0x00000000  "_45678"            5F 34 35 36 37 38
    [  FAILED  ] PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character (0 ms)
    ...

Found that test_PipeCapture succeeds on Fedora 31 and fails on
Fedora 32.  Also test_PipeCapture binary from Fedora 31 and 32 both pass
on Fedora 31 and both fail on Fedora 32.  So something outside of the
GParted code and tests is the cause.

Confirmed that this GLib change "Add a missing check to
g_utf8_get_char_validated()" [1], first released in GLib 2.63.0, made
the difference.  On Fedora 32 with GLib 2.64.6, rebuilt GLib with that
change reverted and the tests passed.  Anyway fix the wrapper GParted
has around g_utf8_get_char_validated() to also handle this case of
reading a NUL character.

[1] 568720006c
    Add a missing check to g_utf8_get_char_validated()

Closes #136 - 1.2.0: test suite is failing in test_PipeCapture
2021-02-22 16:14:35 +00:00
Mike Fleetwood b1cad17a14 Refactor ::OnReadable() creating get_utf8_char_validated() (#136)
Extract call to GLib's g_utf8_get_char_validated() and the associated
workaround to also read NUL characters into a separate function to make
PipeCapture::OnReadable() a little smaller and simpler, so easier to
understand.

Add max_len > 0 clause into get_utf8_char_validated() like this:
    if (uc == UTF8_PARTIAL && max_len > 0)
so that the NUL character reading workaround is only applied when
max_len specifies the maximum number of bytes to read, rather than
when -1 specifies reading a NUL termination string.  This makes
get_utf8_char_validated() a complete wrapper of
g_utf8_get_char_validated() [1], even though GParted always specifies
the maximum number of bytes to read.

No longer describe the inability to read NUL characters as a bug [2]
since the GLib author's said it wasn't [3].

[1] GLib Reference Manual, Unicode Manipulation Functions,
    g_utf8_get_char_validated ()
    https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-get-char-validated

[2] 8dbbb47ce2
    Workaround g_utf8_get_char_validate() bug with embedded NUL bytes
    (#777973)

[3] Bug 780095 - g_utf8_get_char_validated() stopping at nul byte even
    for length specified buffers
    https://bugzilla.gnome.org/show_bug.cgi?id=780095#18
        "If g_utf8_get_char_validated() encounters a nul byte in the
        middle of a string of given longer length, it returns -2,
        indicating a partial gunichar.  That is not the obvious
        behaviour, but since g_utf8_get_char_validated() has been API
        for a long time, the behaviour cannot be changed.
        "

Closes #136 - 1.2.0: test suite is failing in test_PipeCapture
2021-02-22 16:14:35 +00:00
Yuri Chornoivan 0bcb224bdc Add Ukrainian screenshot (!70)
Closes !70 - Add Ukrainian screenshot
2021-02-19 22:07:10 +02:00
Mike Fleetwood 72cd1bc29c Rename SupportedFileSystemsTest method to create_image_file()
... from extra_setup() to provide a more meaningful description of what
it does.
2021-02-17 17:16:48 +00:00
Mike Fleetwood ec9b39cc9c Update allow partition deletion comment in set_valid_operations()
This previous commit [1] suggested that in future partition deletion
might be allowed even while a LUKS mapping was active in that partition.
To allow deletion of a partition while it has active content is wrong.
That is a significant reason GParted has busy detection of otherwise
unrecognised file systems [2] and recognition and busy detection of, but
otherwise not controllable support for, Linux Software RAID [3] and
ATARAID [4][5] arrays.

To automatically close the LUKS partition first would be against the
pattern of behaviour that GParted has established, of requiring explicit
deactivation of file systems, swap and volume groups before allowing
deletion.  Therefore update the comment accordingly.

[1] f1e3d42b56
    Prevent deletion of open LUKS mappings (#774818)

[2] 49a2e19462
    Restore busy detection of unknown mounted file systems (#723842)

[3] d2e1130ad2
    Detect busy status of Linux Software RAID members (#709640)

[4] 6e990ea48a
    Detect busy status of mdadm started ATARAID members (#75)

[5] caec22871e
    Detect busy status of dmraid started ATARAID members (#75)
2021-02-17 17:16:48 +00:00
Mike Fleetwood b7c9b3e5a6 Add support for updating the exFAT UUID (!67)
Also with exfatprogs 1.1.0 [1], tune.exfat and exfatlabel gained the
capability to report and set the exFAT Volume Serial Number [2][3][4].
This is what blkid and therefore GParted reports as the UUID.

Report serial number:

    # tune.exfat -i /dev/sdb1
    exfatprogs version : 1.1.0
    volume serial : 0x772ffe5d
    # echo $?
    0

    # blkid /dev/sdb1
    /dev/sdb1: LABEL="test exfat" UUID="772F-FE5D" TYPE="exfat" PTTYPE="dos"

Set serial number:

    # tune.exfat -I 0xf96ef190 /dev/sdb1
    exfatprogs version : 1.1.0
    New volume serial : 0xf96ef190
    # echo $?
    0

tune.exfat exists in earlier releases of exfatprogs so check it has the
capability by searching for "Set volume serial" in the help output
before enabling this capability.

    # tune.exfat
    exfatprogs version : 1.1.0
    Usage: tune.exfat
            -l | --print-label                    Print volume label
            -L | --set-label=label                Set volume label
            -i | --print-serial                   Print volume serial
            -L | --set-serial=value               Set volume serial
            -V | --version                        Show version
            -v | --verbose                        Print debug
            -h | --help                           Show help

(Note the cut and paste error reporting the set volume serial flag as
'-L' rather than actually '-S').

[1] exfatprogs-1.1.0 version released
    http://github.com/exfaoprogs/exfatprogs/releases/tag/1.1.0

[2] [tools][feature request] Allow To Change Volume Serial Number ("ID")
    #138
    https://github.com/exfatprogs/exfatprogs/issues/138

[3] exfatlabel:add get/set volume serial option
    b4d9c9eeb5

[4] exFAT file system specification, 3.1.11 VolumeSerialNumber Field
    https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification#3111-volumeserialnumber-field

Closes !67 - Add support for reading exFAT usage and updating the UUID
2021-02-17 17:16:48 +00:00
Mike Fleetwood 57507e21e2 Add exFAT file system usage reporting (!67)
exfatprogs 1.1.0 released 2021-02-09 [1] has gained support for
reporting file system usage [2][3] so add that capability to GParted.
It works like this:

    # dump.exfat /dev/sdb1 | egrep 'Volume Length\(sectors\):|Sector Size Bits:|Sector per Cluster bits:|Free Clusters:'
    Volume Length(sectors):                 524288
    Sector Size Bits:                       9
    Sector per Cluster bits:                3
    Free Clusters:                          23585

Unfortunately dump.exfat returns a non-zero status on success so that
can't be used to check for failure:

    # dump.exfat /dev/sdb1
    exfatprogs version : 1.1.0
    -------------- Dump Boot sector region --------------
    Volume Length(sectors):                 524288
    ...
    # echo $?
    192

dump.exfat only writes errors to stderr, so use this to identify failure:

    # dump.exfat /dev/sdb1 1> /dev/null
    # echo $?
    192

    # dump.exfat /dev/zero 1> /dev/null
    invalid block device size(/dev/zero)
    bogus sector size bits : 0
    # echo $?
    234

[1] exfatprogs-1.1.0 version released
    http://github.com/exfaoprogs/exfatprogs/releases/tag/1.1.0

[2] [feature request] File system usage reporting
    https://github.com/exfatprogs/exfatprogs/issues/139

[3] exfatprogs: add dump.exfat
    7ce9b2336b

Closes !67 - Add support for reading exFAT usage and updating the UUID
2021-02-17 17:16:48 +00:00
Anders Jonsson 7c9a7cb297 Update Swedish translation 2021-02-16 20:30:30 +00:00
Yuri Chornoivan 6c236f2755 Update Ukrainian translation 2021-02-16 11:43:33 +00:00
Yuri Chornoivan 4d5a0085d2 Add Ukrainian translation of docs (!69)
Closes !69 - Add Ukrainian translation of docs
2021-02-16 11:12:40 +00:00
Yuri Chornoivan 536bd4e244 Fix minor typos in docs (!68)
Closes !68 - Fix minor typos in docs
2021-02-16 10:01:19 +00:00
Balázs Úr 89ce41aee8 Update Hungarian translation 2021-02-15 00:23:44 +00:00
Mike Fleetwood 4a84952058 Avoid detecting exfat-utils commands as exfatprogs commands (#137)
A user had exfat-utils installed and tried to use GParted to create an
exfat file system.  GParted ran this command but it failed:
    # mkfs.exfat -L '' '/dev/sdb1'
    mkexfatfs 1.3.0
    mkfs.exfat: invalid option -- 'L'
    Usage: mkfs.exfat [-i volume-id] [-n label] [-p partition-first-sector] [-s sectors-per-cluster] [-V] <device>

The problem is that both exfat-utils and exfatprogs packages provide
mkfs.exfat and fsck.exfat commands but they have incompatible command
line options and GParted is programmed for exfatprogs.  So far GParted
just checks the executable exists, hence the mis-identification.

Reported version of exfat-utils commands:
    $ mkfs.exfat -V 2> /dev/null
    mkexfatfs 1.3.0
    Copyright (C) 2011-2018  Andrew Nayenko
    $ fsck.exfat -V 2> /dev/null
    exfatfsck 1.3.0
    Copyright (C) 2011-2018  Andrew Nayenko

Reported versions of exfatprogs commands:
    $ mkfs.exfat -V 2> /dev/null
    exfatprogs version : 1.0.4
    $ fsck.exfat -V 2> /dev/null
    exfatprogs version : 1.0.4

Fix this by only enabling exfat support also when the version string of
each command starts "exfatprogs version".  Note that this extra checking
is not needed for tune.exfat because only exfatprogs provides that
executable.

Closes #137 - Creating exfat partition with a label fails with error
2021-02-10 16:51:19 +00:00
Mike Fleetwood 2e927d4bc4 Make gparted shell wrapper report exit status from gpartedbin
gparted shell wrapper always exits with a 0 status even if gpartedbin
fails.  For example make gpartedbin fail with a non-zero exit status
like this:
    $ (unset DISPLAY; unset XAUTHORITY; /usr/sbin/gpartedbin)

    (gpartedbin:3936): Gtk-WARNING **: 16:36:06.263: cannot open display:
    $ echo $?
    1

However the gparted shell wrapper instead exits with successful status
0:
    $ (unset DISPLAY; unset XAUTHORITY; gparted)

    (gpartedbin:4282): Gtk-WARNING **: 16:39:23.514: cannot open display:
    $ echo $?
    0

Fix this.
2021-02-10 16:30:14 +00:00
Mike Fleetwood 25b7382d03 Replace Win_GParted::hbox member with local variables
hbox is a very generic name for a member variable and used as a local
variable in two methods.  Change to local variables instead.
2021-02-10 16:30:14 +00:00
Mike Fleetwood f3740c7ac9 Remove now unused return value from run_blkid_load_cache() (#131)
Closes #131 - GParted hangs when non-named device is hung
2021-02-10 16:30:14 +00:00
Mike Fleetwood e9d4a21bfb Remove now superfluous load_fs_info_cache() (#131)
This method is now only called from one location in the code so put it's
two lines of code there.

Closes #131 - GParted hangs when non-named device is hung
2021-02-10 16:30:13 +00:00
Mike Fleetwood 52ed42de28 Ensure FS_Info (blkid) cache is populated before first use (#131)
Now we always want to run blkid naming all paths, ensure the FS_Info
cache is explicitly loaded first.  Report an error if not done so and
remove the cache loading code from running blkid without naming all
paths.  Fewer code paths to consider and reason about.

Closes #131 - GParted hangs when non-named device is hung
2021-02-10 16:30:13 +00:00