1. 18 Sep, 2021 1 commit
  2. 17 Sep, 2021 3 commits
    • Mike Fleetwood's avatar
      Fix warning from double assigning to gscreen · 1b85bf00
      Mike Fleetwood authored
      Compiling GParted on an older distribution with gtk+-3.0 < 3.22.0, where
      HAVE_GTK_SHOW_URI_ON_WINDOW is undefined, produces this warning message:
          Win_GParted.cc: In member function 'void GParted::Win_GParted::show_help(const Glib::ustring&, const Glib::ustring&)':
          Win_GParted.cc:1822:56: warning: operation on 'gscreen' may be undefined [-Wsequence-point]
            GdkScreen *gscreen = gscreen = gdk_screen_get_default();
                                                                  ^
      
      Found on Ubuntu 16.04 LTS with gtk+ 3.18.0.
      
      Stop double assigning to gscreen.  Fixes commit:
          26f4dc50
          Replace deprecated gtk_show_uri() method for help window (!82)
      1b85bf00
    • Mike Fleetwood's avatar
      Replace /proc/mounts grep with Mount_Info cache reload and query (!89) · ba1bafc5
      Mike Fleetwood authored
      Creating a grep process to check if a particular mount is still mounted
      is an unnecessary overhead.  All that is needed is for the Mount_Info
      module to refresh it's copy of /proc/mounts and query that.
      
      To keep the code as simple as possible just reload the whole of the
      Mount_Info module and query the mount cache to determine if the
      particular block device is still mounted at this particular mount point.
      This therefore re-reads /proc/mounts (necessary) and /proc/swaps and
      /etc/fstab (unnecessary).  This is still much less overhead than
      creating a separate grep process.
      
      Closes !89 - Fix unmount error when unmounting below a bind mount point
      ba1bafc5
    • Movie Ma's avatar
      Fix unmount error when unmounting below a bind mount point (!89) · 6f811cfa
      Movie Ma authored
      Bind mounts duplicate part of the file system hierarchy to an additional
      mount point [1].  When mounting and unmounting a second file system
      below a duplicating bind mount Linux automatically presents this lower
      file system as being mounted multiple times.  GParted displays these
      multiple mount points.  However using GParted to unmount this lower file
      system reports an error that the second mount point is no longer
      mounted, because all were unmounted by the first unmount command.
      
      Setup:
      
      1.  Mount an upper file system
      
          # mkdir /mnt/1
          # mount /dev/sdb1 /mnt/1
          # fgrep sdb /proc/mounts
          /dev/sdb1 /mnt/1 ext4 rw,seclabel,relatime,data=ordered 0 0
      
      2.  Bind mount it to a second directory
      
          # mkdir /mnt/b1
          # mount --bind /mnt/1 /mnt/b1
          # fgrep sdb /proc/mounts
          /dev/sdb1 /mnt/1 ext4 rw,seclabel,relatime,data=ordered 0 0
          /dev/sdb1 /mnt/b1 ext4 rw,seclabel,relatime,data=ordered 0 0
      
      3.  Mount a file system below the first
      
          # mkdir /mnt/1/lower
          # mount /dev/sdb2 /mnt/1/lower
          # fgrep sdb /proc/mounts
          /dev/sdb1 /mnt/1 ext4 rw,seclabel,relatime,data=ordered 0 0
          /dev/sdb1 /mnt/b1 ext4 rw,seclabel,relatime,data=ordered 0 0
          /dev/sdb2 /mnt/1/lower xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
          /dev/sdb2 /mnt/b1/lower xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
      
          Two mount records for sdb2 were added to /proc/mounts from one mount
          command.
      
      Then use GParted to unmount sdb2.  It reports this error dialog:
          +-------------------------------------+
          |                                     |
          | Could not unmount /dev/sdb2         |
          |                                     |
          | # umount -v '/mnt/b1/lower'         |
          | umount: /mnt/b1/lower: not mounted. |
          +-------------------------------------+
          |            [  OK  ]                 |
          +-------------------------------------+
      
      Fix by checking that the file system is still mounted before each
      unmount attempt.
      
      [1] mount (8), Description, Bind mount operation
          https://man7.org/linux/man-pages/man8/mount.8.html#DESCRIPTION
      
      Closes !89 - Fix unmount error when unmounting below a bind mount point
      6f811cfa
  3. 11 Sep, 2021 1 commit
  4. 10 Sep, 2021 1 commit
  5. 08 Sep, 2021 1 commit
  6. 07 Sep, 2021 1 commit
  7. 06 Sep, 2021 1 commit
  8. 05 Sep, 2021 1 commit
  9. 04 Sep, 2021 1 commit
  10. 28 Aug, 2021 1 commit
  11. 14 Aug, 2021 6 commits
    • Mike Fleetwood's avatar
      Remove (N/A) from comment in FileSystem::rm_temp_dir() · d123d36b
      Mike Fleetwood authored
      Extra hint of warning status being represented by enumeration constant
      STATUS_N_A is no longer needed since commit:
          8c5c13d6
          Rename OperationDetailStatus STATUS_N_A to STATUS_WARNING
      d123d36b
    • Mike Fleetwood's avatar
      Add missing includes to Mount_Info.cc · 48fd3cba
      Mike Fleetwood authored
      48fd3cba
    • Mike Fleetwood's avatar
      Reorder parameters to add_mountpoint_entry() · a7f9ec65
      Mike Fleetwood authored
      To match the order of the members in struct MountEntry.
      a7f9ec65
    • Mike Fleetwood's avatar
      Extract common code into Mount_Info::lookup_uuid_or_label() (#162) · f5e62394
      Mike Fleetwood authored
      Closes #162 - It is no longer possible to mount a LUKS encrypted file
                    system
      f5e62394
    • Mike Fleetwood's avatar
      Resolve UUID= and LABEL= refs when searching Mount_Info (#162) · 49747f65
      Mike Fleetwood authored
      Implemented the second half of the solution described in the previous
      commit.  Resolve UUID= and LABEL= references when searching in the
      Mount_Info cache so that mount points of encrypted file systems listed
      in /etc/fstab can be found using the later added FS_Info details.
      
      Closes #162 - It is no longer possible to mount a LUKS encrypted file
                    system
      49747f65
    • Mike Fleetwood's avatar
      Load unresolved UUID= and LABEL= refs into Mount_Info cache (#162) · 5bede18e
      Mike Fleetwood authored
      ISSUE DETAILS
      
      GParted no longer enables Partition > Mount on, for unmounted encrypted
      file systems listed in /etc/fstab.
      
      Steps to reproduce:
      
      1. Create LUKS mapping and open.
         # cryptsetup luksFormat /dev/sdb1 -
         # cryptsetup luksOpen /dev/sdb1 sdb1_crypt
      
      2. Create any file system.
         # mkfs.ext4 /dev/mapper/sdb1_crypt
         # uuid=`blkid -o value -s UUID /dev/mapper/sdb1_crypt`
      
      3. Add /etc/fstab entry.
         # mkdir /mnt/1
         # echo "UUID=$uuid /mnt/1 ext4 defaults 0 0" >> /etc/fstab
      
      4. Run GParted and try Partition > Mount on.
      
      With GParted >= 1.3 no mount point is available.  With GParted <= 1.2
      mount point /mnt/1 is available.
      
      EXPLANATION
      
      Up until GParted 1.2.0 it worked like this:
      1. Ran blkid and loaded the details for every file system into the
         FS_Info cache.  This included results for file systems in open LUKS
         mappings, such as /dev/mapper/sdb1_crypt in the above example.
      2. Read /etc/fstab, resolved UUID= and LABEL= references into block
         device names and added those into the Mount_Info cache.
      3. Looped through all partitions adding mount points known by the
         Mount_Info cache.
      
      After the changes for issue #131 "GParted hangs when non-named device is
      hung" and issue #148 "Encrypted file systems are no longer recognised"
      it works like this instead:
      1. Runs blkid for specified devices and partitions only and loads file
         system details into the FS_Info cache.  Does not include open LUKS
         mappings so no results for those file systems.
      2. Loading of /etc/fstab into the Mount_Info cache is unable to resolve
         UUID= and LABEL= references for file systems in LUKS mappings, so
         they aren't included.
      3. No mount points known for encrypted file systems.
      
      Note that currently when an encrypted file system is added into the data
      model it extends the FS_Info cache <2>, but this is after the Mount_Info
      cache has been loaded <1>.  Call flow is like this:
      
        GParted_Core::set_devices_thread()
          FS_Info::clear_cache()
          FS_Info::load_cache_for_paths()
      1>  Mount_Info::load_cache()
          ...
          set_device_from_disk()
            set_device_one_partition() / set_device_partitions()
              set_luks_partition()
                detect_filesystem_in_encryption_mapping()
      2>          FS_Info::load_cache_for_paths()
                ...
                set_mountpoints()
                  partition.add_mountpoints(Mount_Info::get_fstab_mountpoints())
      
      SOLUTION
      
      Also save unresolved UUID= and LABEL= references from /etc/fstab into
      the Mount_Info cache.  Then when searching the Mount_Info /etc/fstab
      cache resolve encountered UUID= and LABEL= references.
      
      THIS COMMIT
      
      Also save unresolved UUID= and LABEL= references into the Mount_Info
      cache.
      
      Closes #162 - It is no longer possible to mount a LUKS encrypted file
                    system
      5bede18e
  12. 07 Aug, 2021 1 commit
  13. 30 Jul, 2021 6 commits
    • Mike Fleetwood's avatar
      7d3a504b
    • Mike Fleetwood's avatar
      cf5a264b
    • Mike Fleetwood's avatar
      Add labelling of mounted ext2/3/4 (#163)(#600496) · e4427b03
      Mike Fleetwood authored
      E2label works the same way whether an ext2/3/4 file system is mounted or
      not, by directly reading and writing the superblock from the partition
      block device.  (Technically the superblock will already be in the kernel
      device buffer cache because the kernel has the ext2/3/4 file system
      mounted and a reference to the superblock in the device buffer cache).
      This is safe and supported as confirmed here [1].  As this method has
      always worked, even on the oldest distributions, unconditionally enable
      this feature.
      
          # mkfs.ext4 -L label_1 /dev/sdb3
          # mount /dev/sdb3 /mnt/3
          # e2label /dev/sdb3 label_2
          # blkid /dev/sdb3
          /dev/sdb3: LABEL="label_2" ...
      
      [1] Is labelling a mounted ext2/3/4 file system safe and supported?
          https://lore.kernel.org/linux-ext4/CAMU1PDgNvW_3Jr91iii-Nh=DCuRytVG8ka3-J+a43gKwigx8Yg@mail.gmail.com/T/#u
      
      Bug 600496 - Allow changing ext2/3 label without unmounting
      Closes #163 - Feature request: set label on a mounted btrfs
      e4427b03
    • Mike Fleetwood's avatar
      Add labelling of mounted xfs (#163) · 0c13855d
      Mike Fleetwood authored
      XFS also supports labelling of the file system while it is mounted.
      This was added into Linux kernel 4.18 [1] and xfsprogs 4.17.0 [2].
      These versions are newer than available in older but still supported
      distributions so we'll need to detect versions before enabling support.
      These are the oldest releases of distributions which meet the
      requirements.
      
          Distro             EOL        Linux kernel   xfsprogs
          Debian 10          2024-Jun   4.19.0         4.20.0
          RHEL 8             2029-May   4.18.0         5.0.0
          Ubuntu 20.04 LTS   2030-Apr   5.4            5.3.0
      
      As with btrfs a mounted XFS is labelled via it's mount point:
          # mkfs.xfs -L label_1 /dev/sdb2
          # mount /dev/sdb2 /mnt/2
          # xfs_io -c 'label -s mnt_label_2' /mnt/2
          label = "mnt_label_2"
          # blkid /dev/sdb2
          /dev/sdb2: LABEL="mnt_label_2" ...
      
      And cleared with:
          # xfs_io -c 'label -c' /mnt/2
          label = ""
      
      Note that in some error situations xfs_io reports exit status zero and
      writes the failure message to stdout.
          # xfs_io -c 'label -s "mnt label 3"' /mnt/2
          bad argument count 4 to label, expected between 0 and 3 arguments
          # echo $?
          0
      Therefore determine success based on stdout starting with 'label = "'
      reporting the new label or not.
      
      Also note that as seen in this failure case, it is not possible to set
      an XFS label which contains a space character using xfs_io.  However
      that is nothing new as that can't be done using the existing xfs_admin
      command for an unmounted XFS either.
          # umount /mnt/2
          # xfs_admin -L 'umnt label 4' /dev/sdb2
          Usage: xfs_admin [-efjlpuV] [-c 0|1] [-L label] [-U uuid] device
          # echo $?
          2
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7664b31975bd893190708e76b2c424328f0c49b
          xfs: implement online get/set fs label
      [2] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=cfa10b0f972005b38ed294bca66cebf2f65298ec
          xfs_io: add label command
      
      Closes #163 - Feature request: set label on a mounted btrfs
      0c13855d
    • Mike Fleetwood's avatar
      Show online file system labelling in the Features dialog (#163) · 47960037
      Mike Fleetwood authored
      Show support for online labelling using a second tick mark in the
      Features dialog.  This matches how online grow and shrink are shown.
      
      Closes #163 - Feature request: set label on a mounted btrfs
      47960037
    • Mike Fleetwood's avatar
      Add labelling of mounted btrfs (#163) · eb034b17
      Mike Fleetwood authored
      Btrfs supports labelling of the file system while it is mounted.  This
      was added into Linux kernel 3.10 [1] and btrfs-progs 3.12 [2].  As the
      oldest supported distributions have the needed versions or newer,
      unconditionally enable without any checking for availability.
      
          Distro             EOL        Linux kernel   btrfs-progs
          Debian 9           2022-Jun   4.19           4.7.3
          RHEL / CentOS 7    2024-Jun   3.10.0         4.9.1
          Ubuntu 18.04 LTS   2023-Apr   4.15.0         4.15.1
      
      Unmounted btrfs is labelled via the block device containing it, where as
      a mounted btrfs is labelled via it's mount point.
      
          # mkfs.btrfs -L initial_label /dev/sdb1
          # blkid /dev/sdb1
          /dev/sdb1: LABEL="initial_label" ...
      
          # btrfs filesystem label /dev/sdb1 unmounted_label_2
          # blkid /dev/sdb1
          /dev/sdb1: LABEL="unmounted_label_2" ...
      
          # mount /dev/sdb1 /mnt/1
          # btrfs filesystem label /dev/sdb1 mounted_label_3
          # blkid /dev/sdb1
          /dev/sdb1: LABEL="mounted_label_3" ...
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a8bfd4abea3da0e28f215e2a2b8c2f1ca27ebe80
          Btrfs: set/change the label of a mounted file system
      [2] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=619dc61cae1420da2dec48f689d49b9b346abc15
          Btrfs-progs: Change the label of a mounted file system
      
      Closes #163 - Feature request: set label on a mounted btrfs
      eb034b17
  14. 19 Jul, 2021 2 commits
  15. 15 Jul, 2021 1 commit
  16. 14 Jul, 2021 3 commits
  17. 13 Jul, 2021 2 commits
  18. 12 Jul, 2021 2 commits
  19. 06 Jun, 2021 2 commits
    • Mike Fleetwood's avatar
      Copy XFS UUID when copying the file system (!85) · 39e71566
      Mike Fleetwood authored
      For the same reason as in the previous commit, the UUID is copied when
      copying every file system type except for XFS, where a new XFS is
      created with a new UUID.
      
      Again preview of the copy operation expects the UUID to be copied.
      (Look in Partition > Information of the source and pasted partitions
      before the operation is applied).
      
      Fix as before by specifying the desired file system UUID when creating
      the new XFS as part of the copy operation.
      
      However there is an extra complication.  The XFS kernel driver refuses
      to mount a file system with a duplicate UUID of an already mounted XFS.
      
          # mkfs.xfs -L xfs_copy /dev/sdb1
          # mount /dev/sdb1 /mnt/1
          # tail -2 /var/log/messages
          Jun  3 21:41:24 localhost kernel: XFS (sdb1): Mounting V5 Filesystem
          Jun  3 21:41:24 localhost kernel: XFS (sdb1): Ending clean mount
      
          # /dev/sdb1: LABEL="xfs_copy" UUID="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" TYPE="xfs"
          # mkfs.xfs -L xfs_copy -m uuid="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" /dev/sdb2
          # mount /dev/sdb2 /mnt/2
          mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
                 missing codepage or helper program, or other error.
      
                 In some cases useful info is found in syslog - try
                 dmesg | tail or so.
          # echo $?
          32
          # tail -1 /var/log/messages
          Jun  3 21:41:31 localhost kernel: XFS (sdb2): File system has duplicate UUID d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8 - can't mount
      
      Handle this specifying the needed option [1] when mounting the second
      XFS during the copy.
      
          # mount -o nouuid /dev/sdb2 /mnt/2
          # mount | grep /dev/sdb
          /dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
          /dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,noquota)
      
      Duplicating the UUID may seem troublesome, but it is being done:
      1.  To make the GParted copied XFS be as much a clone as possible, to
          match what is does with other file systems.
      2.  It has a valid use case; of cloning a Linux installation to a new
          drive or restoring a partition image backup.  In these cases it is
          much simpler if the UUID of the copy remains the same because it
          avoids having to edit GRUB2 configuration and fstab file system
          mounting which is nearly always done via UUID.
      3.  GParted has the new UUID operation, to change the UUID for cases
          when a copied file system needs to be mounted at the same time as
          the source.
      
      [1] xfs(5) - xfs - layout, mount options, and supported file attributes
          for the XFS filesystem
          https://man7.org/linux/man-pages/man5/xfs.5.html
          "MOUNT OPTIONS
          ...
          nouuid Don't check for double mounted file systems using the file
                 system uuid.
          "
      
      Closes !85 - Make XFS copy duplicate the file system label and UUID
      39e71566
    • Mike Fleetwood's avatar
      Copy XFS label when copying the file system (!85) · 36e43ed7
      Mike Fleetwood authored
      As GParted performs block copy of partitions then the label, which is
      stored in the file system superblock, is also copied.  This is true for
      copies performed using the GParted internal block copy and for EXT2/3/4
      and NTFS which are copied using the file system specific commands
      e2image and ntfsclone respectively.  However when an XFS file system is
      copied the label is not copied because a new file system is created
      using mkfs.xfs and the files copied using xfsdump | xfsrestore.
      
      Preview of the copy operation in GParted also reflects the fact that the
      label will be copied.
      
      Fix this by simply specifying the desired label when creating the new
      destination XFS.
      
      Closes !85 - Make XFS copy duplicate the file system label and UUID
      36e43ed7
  20. 31 May, 2021 2 commits
  21. 23 May, 2021 1 commit