1. 11 Jun, 2019 1 commit
    • Mike Fleetwood's avatar
      Separate partition alignment from validation (#48) · 406beaae
      Mike Fleetwood authored
      A user had 2 adjacent partitions which were aligned to multiples of
      33553920 bytes (32 MiB - 512 bytes), not MiB or cylinders.  As far as
      GParted is concerned this is not aligned.  The second partition
      contained closed LUKS encrypted data.  Recreate this setup with:
          # truncate -s 200G /tmp/disk.img
          # losetup -f --show /tmp/disk.img
          # sfdisk -u S /dev/loop0 << EOF
          65535 2162655 83
          2228190 78904140 83
          # partprobe /dev/loop0
          # echo -n badpassword | cryptsetup luksFormat /dev/loop0p2 -
      When trying to move the second LUKS encrypted partition to the right by
      any amount, with the default MiB alignment, GParted displays this error
      dialog and fails to even queue the operation:
          Could not add this operation to the list
          A partition with used sectors (78907392) greater than its
          length (78905344) is not valid
          [                       OK                               ]
      Overview of the steps involved:
      1. The Resize/Move dialog composed a new partition to start a whole
         multiple of MiB after the end of the previous non-aligned partition.
         The new partition also had it's size increased to a whole multiple of
         MiB, to 78907392 sectors (38529 MiB) which was 1.59 MiB larger than
         before.  Neither the start or end of the new partition are aligned at
         this point.
      2. Win_GParted::activate_resize() applied the change back to the closed
         LUKS partition object, additionally making the used sectors equal to
         the partition size.
         (To match the fact that when opened the LUKS mapping it will
         automatically fill the new larger partition size).
      3. GParted_Core::snap_to_mebibyte() then aligned the partition start and
         end to whole MiB boundaries, reducing the partition size in the
         process to 78905344 (38528 MiB).
      4. GParted_Core::snap_to_alignment() reported the error saying that it
         couldn't add the operation to the list because it was invalid to have
         the file system used sectors larger than the partition size.
      Fix this by having the snap to alignment adjustments applied before the
      dialogs update any associated file system usage.  Specifically the
      Resize/Move, Paste (into new) and Create New dialogs as these are the
      only ones which either create or modify partition boundaries.
      Validation done by snap_to_alignment() will continue to occur at the
      current point when the operation is added to the list.
      snap_to_alignment() is doing two different jobs, it is (1) optionally
      adjusting the new partition boundaries for MiB or Cylinder alignment;
      and (2) checking that the partition boundaries and file system usage are
      Split those into two different functions (1) snap_to_alignment() and
      (2) valid_partition().  For now valid_partition() still calls
      snap_to_alignment() so there is no functional change with this commit.
      Closes #48 - Error when moving locked LUKS-encrypted partition
  2. 09 Jun, 2019 1 commit
  3. 06 Jun, 2019 1 commit
  4. 03 Jun, 2019 1 commit
  5. 31 May, 2019 1 commit
    • Salamandar's avatar
      Fix test (dentry->d_name is invalidated by closedir...) (!41) · cdba5cee
      Salamandar authored
      We have to copy the dentry->d_name before calling closedir().  If not,
      the string points to nothing and the test fails (It does not fail all
      the time, but only by chance).
      Confirmed using valgrind.  Selected output from running the unit test
      under valgrind:
        $ valgrind --track-origins=yes ./test_blockSpecial
        ==25110== Memcheck, a memory error detector
        ==25110== Command: ./test_BlockSpecial
        Running main() from src/gtest_main.cc
        [==========] Running 26 tests from 1 test case.
        [----------] Global test environment set-up.
        [----------] 26 tests from BlockSpecialTest
        [ RUN      ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches
        ==25110== Invalid read of size 1
        ==25110==    at 0x4C2C9B2: strlen (vg_replace_strmem.c:458)
        ==25110==    by 0x40E7C4: length (char_traits.h:259)
        ==25110==    by 0x40E7C4: append (basic_string.h:1009)
        ==25110==    by 0x40E7C4: operator+<char, std::char_traits<char>, std::allocator<char> > (basic_string.h:2468)
        ==25110==    by 0x40E7C4: get_link_name (test_BlockSpecial.cc:156)
        ==25110==    by 0x40E7C4: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247)
        =25110==  Address 0x1231ea93 is 115 bytes inside a block of size 32,816 free'd
        ==25110==    at 0x4C2ACBD: free (vg_replace_malloc.c:530)
        ==25110==    by 0x9F773AC: closedir (in /usr/lib64/libc-2.17.so)
        ==25110==    by 0x40E7AC: get_link_name (test_BlockSpecial.cc:153)
        ==25110==    by 0x40E7AC: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247)
        ==25110==  Block was alloc'd at
        ==25110==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
        ==25110==    by 0x9F77280: __alloc_dir (in /usr/lib64/libc-2.17.so)
        ==25110==    by 0x40E746: get_link_name (test_BlockSpecial.cc:134)
        ==25110==    by 0x40E746: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247)
        ==25110== Invalid read of size 1
        ==25110==    at 0x4C2E220: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022)
        ==25110==    by 0x953A997: std::string::append(char const*, unsigned long) (in /usr/lib64/libstdc++.so.6.0.19)
        ==25110==    by 0x40E7D2: append (basic_string.h:1009)
        ==25110==    by 0x40E7D2: operator+<char, std::char_traits<char>, std::allocator<char> > (basic_string.h:2468)
        ==25110==    by 0x40E7D2: get_link_name (test_BlockSpecial.cc:156)
        ==25110==    by 0x40E7D2: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247)
        ==25110==  Address 0x1231ea93 is 115 bytes inside a block of size 32,816 free'd
        ==25110==    at 0x4C2ACBD: free (vg_replace_malloc.c:530)
        ==25110==    by 0x9F773AC: closedir (in /usr/lib64/libc-2.17.so)
        ==25110==    by 0x40E7AC: get_link_name (test_BlockSpecial.cc:153)
        ==25110==    by 0x40E7AC: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247)
        ==25110==  Block was alloc'd at
        ==25110==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
        ==25110==    by 0x9F77280: __alloc_dir (in /usr/lib64/libc-2.17.so)
        ==25110==    by 0x40E746: get_link_name (test_BlockSpecial.cc:134)
        ==25110==    by 0x40E746: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247)
        [       OK ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (50 ms)
      Selected lines from test_BlockSpecial.cc:
        132  static std::string get_link_name()
        133  {
        134          DIR * dir = opendir( "/dev/disk/by-id" );
        141          bool found = false;
        142          struct dirent * dentry;
        143          // Silence GCC [-Wparentheses] warning with double parentheses
        144          while ( ( dentry = readdir( dir ) ) )
        145          {
        146                  if ( strcmp( dentry->d_name, "." )  != 0 &&
        147                       strcmp( dentry->d_name, ". " ) != 0    )
        148                  {
        149                          found = true;
        150                          break;
        151                  }
        152          }
        153          closedir( dir );
        155          if ( found )
        156                  return std::string( "/dev/disk/by-id/" ) + dentry->d_name;
      So the memory referred to by dentry was allocated on line 134, freed on
      153 and accessed after freed on 156.
      Closes !41 - Fix test (dentry->d_name is invalidated by closedir...)
  6. 29 May, 2019 4 commits
  7. 28 May, 2019 3 commits
    • Claude Paroz's avatar
      Update French translation · 7186e702
      Claude Paroz authored
    • Mike Fleetwood's avatar
      Fix reading NTFS usage after resize (#57) · 5e77368d
      Mike Fleetwood authored
      After an NTFS file system has been resized the command GParted currently
      uses to read the file system usage fails like this:
          # ntfsinfo --mft /dev/sdb1
          Volume is scheduled for check.
          Please boot into Windows TWICE, or use the 'force' option.
          NOTE: If you had not scheduled check and last time accessed this volume
          using ntfsmount and shutdown system properly, then init scripts in your
          distribution are broken. Please report to your distribution developers
          (NOT to us!) that init scripts kill ntfsmount or mount.ntfs-fuse during
          shutdown instead of proper umount.
          Failed to open '/dev/sdb1'.
      Fix by added the '--force' flag as described in the error message.
      Closes #57 - NTFS Resize results in Partition Information Warning on
    • Mike Fleetwood's avatar
      Report errors correctly on failure to read NTFS usage (#57) · fbcf4b56
      Mike Fleetwood authored
      GParted uses ntfsinfo to read the NTFS file system usage.  However when
      ntfsinfo fails with a non-zero exit status GParted reports stdout twice,
      rather than stdout and stderr.  Correct this.
      Closes #57 - NTFS Resize results in Partition Information Warning on
  8. 26 May, 2019 2 commits
  9. 25 May, 2019 1 commit
  10. 22 May, 2019 4 commits
  11. 15 May, 2019 2 commits
    • Luca Bacci's avatar
      Set the xalign property for Gtk::Labels (!40) · 12f08d38
      Luca Bacci authored
      With the same case as from the previous commit, the very long "Mounted
      on ..." text is now wrapped, but the text may not be left justified.
      Slowly adjust the dialog width and see how the text wrapping is updated
      to fit the size adjustment but the text is centred rather than left
      This is because setting the halign property to Gtk::ALIGN_START does not
      guarantee left alignment of text for wrapped or ellipsized Gtk::Labels.
      Use the xalign property instead.
      To set the xalign property there is a method in the GtkMisc (Gtk::Misc)
      base class:
        gtk_misc_set_alignment (Gtk::Misc::set_alignment)
      However, GtkMisc (Gtk::Misc) was deprecated in Gtk 3.14 (Gtkmm 3.14)
      and in Gtk 3.16 (gtkmm 3.16) set_alignment() was replaced with the
      introduction of two new methods:
        gtk_label_set_xalign (Gtk::Label::set_xalign)
        gtk_label_set_yalign (Gtk::Label::set_yalign)
      Add a check for Gtkmm method Gtk::Label::set_xalign() in configure.ac
      and use it when available.
      [1] Gtk3 Reference Documentation - gtk_misc_set_alignment()
          "gtk_misc_set_alignment has been deprecated since version 3.14 and
          should not be used in newly-written code. Use GtkWidget's alignment
          ("halign" and "valign") and margin properties or GtkLabel's
          "xalign" and "yalign" properties."
      [2] Gtkmm 3.16 Gtk::Misc Class Reference, set_alignment() method
      [3] GNOME BugZilla - EmptyBoxes: instructions_label's alignment is off
      [4] Gtk commit from 2014-09-16:
          GtkLabel: add x/yalign properties
      [5] Gtk3 Reference Documentation - gtk_label_set_xalign()
      [6] Gtkmm 3.16 Gtk::Label Class Reference, set_xalign() method
      Closes !40 - Limit wrapping labels
    • Luca Bacci's avatar
      Set a default max_width_chars for wrapping Gtk::Labels (!40) · 769d19e0
      Luca Bacci authored
      Opening the Partition Information dialog for a file system mounted on a
      very long mount point, or on openSUSE which mounts the OS from 10 btrfs
      subvolumes from the same partition, will cause the dialog to be very
      wide as the "Mounted on ..." text is not wrapped.
      Back in Gtk2, when width_chars / max_width_chars were not set, wrapping
      labels had a default width beyond which text wrapped onto a new line
      For Gtk3 this default width was first reworked a bit [2], and then was
      removed for the very early Gtk3 3.0.10 release [3].
      It is recommended that applications explicitly set default values,
      otherwise wrapping labels never wrap when requesting their natural
      [1] Gtk 2.24.32 source code - gtk/gtklabel.c:2975
              "This long string gives a good enough length for any line to
      [2] Gtk commit from 2010-04-21:
          Make sure not to base the minimum size on "max-width-chars", only
          the natural size.
              "This string is just about long enough."
      [3] Gtk commit from 2011-04-17:
          label: Don't try to guess a label's size
          People should use window default sizes or label
          width-chars/max-width-chars to find the ideal layout for a label
          instead of relying on magic.
      Closes !40 - Limit wrapping labels
  12. 13 May, 2019 1 commit
    • Luca Bacci's avatar
      Request natural width in Gtk::ScrolledWindows for Gtk >= 3.22 (!39) · eeffd505
      Luca Bacci authored
      Before Gtk 3.22 GtkScrolledWindow propagated natural size to its
      Children and so on to descendants.  In Gtk 3.22 this was changed to
      always request the minimum size.  This was done because it is believed
      to be a safer default (gives a better behaviour) in case of dynamic
      content inside the scrolled window, that is, content that may change
      allocated size. [1][2][3]
      When the scrolled window content is not dynamic the natural size is
      preferable because it gives a better looking layout and without any
      In the case of GParted content which is not dynamic, so request the
      scrolled windows to allocate children at natural sizes for Gtk >= 3.22.
      The benefits of natural size allocation are evident in presence of
      wrapping labels (for example inside the "Partition Info" dialog), that
      with the minimum size request likely end up taking a very small width.
      [1] Gtk commit from 2016-08-31:
          GtkScrolledWindow: Make propagation of natural child sizes optional
          "Making propagation of child natural sizes mandatory (or default,
          even) was evidently a mistake as this causes dynamic content in a
          scrolled window to resize it's parent when the scrolled window is
          competing for space with an adjacent widget."
      [2] Gtk 3.22 Reference Documentation -
      [3] Gtkmm 3.24 Gtk::ScrolledWindow Class Reference,
          set_propagate_natural_width() method
      [4] Gtkmm 3.21.6 NEWS
          "ScrolledWindow: Added get/set_propagate_natural_height/width() and
          the properties."
      Closes !39 - Always request natural size inside Gtk::ScrolledWindow
  13. 10 May, 2019 1 commit
  14. 01 May, 2019 1 commit
  15. 30 Apr, 2019 1 commit
  16. 27 Apr, 2019 15 commits