# Generated by Makefile. Do not edit.

2021-05-03  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-1.3.0   ==========

2021-05-01  Jiri Grönroos <jiri.gronroos@iki.fi>

    Update Finnish translation

2021-05-01  Piotr Drąg <piotrdrag@gmail.com>

    Update Polish translation

2021-04-27  Ngọc Quân Trần <vnwildman@gmail.com>

    Update Vietnamese translation

2021-04-26  Fran Dieguez <frandieguez@gnome.org>

    Update Galician translation

2021-04-26  Kukuh Syafaat <kukuhsyafaat@gnome.org>

    Update Indonesian translation

2021-04-26  Fran Dieguez <frandieguez@gnome.org>

    Update Galician translation

2021-04-26  Hannie Dumoleyn <hannie@ubuntu-nl.org>

    Update Dutch translation

2021-04-26  Hannie Dumoleyn <hannie@ubuntu-nl.org>

    Update Dutch translation

2021-04-26  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2021-04-26  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2021-04-26  Baurzhan Muftakhidinov <baurthefirst@gmail.com>

    Update Kazakh translation

2021-04-25  Claude Paroz <claude@2xlibre.net>

    Updated French translation

2021-04-25  Rafael Fontenelle <rafaelff@gnome.org>

    Update Brazilian Portuguese translation

2021-04-25  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

2021-04-25  Yuri Chornoivan <yurchor@ukr.net>

    Update Ukrainian translation

2021-04-25  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

2021-04-25  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Mark remaining get_filesystem_*() methods as returning const strings

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Comment differences between FileSystem::execute_command() methods

2021-04-02  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Report this LUKS passphrase request reason as resize (#59)
    
    So far when prompting for the LUKS passphrase the dialog always looks
    like this:
    
        +------------------------------------------------+
        |           LUKS Passphrase /dev/sdb1            |
        +------------------------------------------------+
        | Enter LUKS passphrase to open /dev/sdb1        |
        | Passphrase:    [                             ] |
        |                                                |
        |                                                |
        |                          [ Cancel ] [ Unlock ] |
        +------------------------------------------------+
    
    Specifically the first line of the dialog says the reason to provide the
    passphrase is to open the encryption mapping.  Now the passphrase may
    also be requested when resizing the encryption mapping, as part of a
    resize of check operation, show the appropriate reason in the password
    dialog.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-07  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Also prompt for LUKS password as required for check operation (#59)
    
    A check operation involves (1) checking the file system, (2) growing the
    encryption volume and (3) growing the file system.  Therefore prompt for
    the LUKS passphrase as required when composing a check operation too.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Pass LUKS password as needed when resizing open mapping (#59)
    
    This is the final piece which enables GParted to pass the LUKS
    passphrase when resizing an open LUKS encryption mapping when
    'cryptsetup resize' will prompt for it.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add ability for small writes to stdin of operation tracked child processes (#59)
    
    This is the equivalent to what was previously done when adding opening
    of LUKS mappings.  Namely to add a way to pass the LUKS passphrase to
    'cryptsetup luksOpen' via standard input.  Previously the functionality
    was added to Utils::execute_command() [1].  Now it is also needed to
    pass the LUKS passphrase to 'cryptsetup resize', which is executed as
    part of applying resize and check operations to an encrypted file
    system.  So add this functionality to FileSystem::execute_command().
    
    For now writing to stdin is only needed for the one variant of
    FileSystem::execute_command() which doesn't have progress tracking
    callbacks.  Writing to stdin can easily be added to the other progress
    tracking callback variants of execute_command() when needed.
    
    [1] 8dff80edc65b2923b400ddadebacf9bcf378d09f
        Add ability for small writes to stdin of child processes (#795617)
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Extract common code into generate_encryption_mapping_name() (#59)
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-03-26  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Ask for LUKS passphrase for resize operation as required (#59)
    
    When composing a resize operation on an open encryption mapping, use the
    existing LUKS password dialog to prompt for the passphrase, if and only
    if 'cryptsetup resize' will prompt and GParted doesn't already have a
    password.  'cryptsetup resize' will prompt for a LUKS passphrase when
    the passphrase was stored in the kernel keyring service,
    key_loc == KEYLOC_KeyRing.  See the previous commit "Capture LUKS
    mapping master encryption key location (#59)" for more details.
    
    As commented in the code GParted specifically doesn't support the case
    where the LUKS passphrase is changed while GParted is running and it
    knew the old passphrase.  When resizing an open encryption mapping
    GParted will just pass the old out of date passphrase it knows and the
    resize will fail like this:
    
        # cryptsetup status sdb2_crypt | egrep 'type|key location'
          type:         LUKS2
          key location: keyring
        # dmsetup table --target crypt
        sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
    
        # echo -n oldpassword | cryptsetup -v --size 491520 resize sdb2_crypt
        No key available with this passphrase.
        Command failed with code -2 (no permission or bad passphrase).
        # echo $?
        2
    
    To work around this either close and restart GParted or close and reopen
    the encryption mapping.  The former because GParted doesn't save
    passwords across a restart so will prompt and the latter because GParted
    will use the wrong old passphrase to try to open the mapping and then
    prompt for the correct passphrase until successfully opened.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-03-26  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Capture LUKS mapping master encryption key location (#59)
    
    ISSUE OVERVIEW
    
    When GParted tries to resize an open LUKS encryption mapping and the
    volume (master) key was stored in the kernel keyring service [1] it
    fails like this:
    
        Check and repair file system ([Encrypted] ext4) on /dev/...(ERROR)
        + calibrate /dev/sdd1                                      (SUCCESS)
        + check file system on /dev/mapper/sdd1_crypt for errors...(SUCCESS)
        + grow encryption volume to fill the partition             (ERROR)
          + cryptsetup -v resize 'sdd1_crypt'                      (ERROR)
              Command failed with code -1 (wrong or missing parameters).
              Nothing to read on input.
    
    This error occurs with cryptsetup >= 2.0, kernel >= 4.10 and LUKS2
    format because the crypt Device-Mapper target no longer has the volume
    key so cryptsetup resize prompts for a passphrase, but GParted doesn't
    provide it.
    
    THIS COMMIT
    
    Additionally capture the location of the volume (master) key location
    for active encryption mappings.  Do this the using the same method that
    cryptsetup uses [2][3].  Namely if the first character of the KEY is a
    ":" then the key *was* stored in the kernel keyring service, otherwise
    it *is* store in the Device-Mapper crypt target as previously.
    
        # echo -n badpassword | cryptsetup luksFormat --type luks1 /dev/sdb1 -
        # echo -n badpassword | cryptsetup luksOpen /dev/sdb1 sdb1_crypt
        # cryptsetup status sdb1_crypt | egrep 'type|key location'
          type:         LUKS1
          key location: dm-crypt
    
        # echo -n badpassword | cryptsetup luksFormat --type luks2 /dev/sdb2 -
        # echo -n badpassword | cryptsetup luksOpen /dev/sdb2 sdb2_crypt
        # cryptsetup status sdb2_crypt | egrep 'type|key location'
          type:         LUKS2
          key location: keyring
    
        # dmsetup table --target crypt
        sdb1_crypt: 0 520192 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:17 4096
        sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
                                                   ^
    First character of the KEY field --------------'
    
    [1] Integration with the kernel keyring service
        https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/Keyring.txt
        "
        Starting with cryptsetup 2.0 we load [Volume Key] VK in kernel
        keyring by default for LUKSv2 devices ...
    
        In summary, the key description visible in dm-crypt table line is a
        reference to VK that usually no longer exists in kernel keyring
        service if you used cryptsetup to for device activation.
        "
    
    [2] cryptsetup/v2.3.5/lib/libdevmapper.c:_dm_target_query_crypt()
        https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/lib/libdevmapper.c#L2031
            if (key_[0] == ':')
                *act_flags |= CRYPT_ACTIVATE_KEYRING_KEY;
    
    [3] cryptsetup/v2.3.5/src/cryptsetup.c:action_status()
        https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/src/cryptsetup.c#L839
            log_std("  key location: %s\n", (cad.flags & CRYPT_ACTIVATE_KEYRING_KEY) ? "keyring" : "dm-crypt");
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-11  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Ignore libparted unrecognised disk label message from encryption mappings (#152)
    
    When GParted probes an open encryption mapping which is either blank or
    contains a file system which libparted doesn't recognise, such as:
    exfat, f2fs, lvm2 pv, minix or reiser4, then the partition also gets
    this warning message:
        /dev/mapper/sdb11_crypt: unrecognised disk label
    
    Clear the message so that it isn't shown in the GUI.
    
    Note that the message is still written to stderr by GParted, like all
    libparted exceptions are.  This is done by GParted's libparted exception
    handler:
        GParted_Core::ped_exception_handler()
          _ped_exception_handler()
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Reorder cases in set_device_and_disk() and use if fail return early (#152)
    
    The previous commit "Resolve empty drive displayed as blank minor logic
    issue (#152)" left the code in set_device_and_disk() some what
    unsightly.
    
    Refactor the whole function.  Use if fail return early pattern for
    failure of the get_device() call at the start of the function.  Reorder
    the 4 cases into a single depth if then else if chain.  Hopefully this
    is a little easier to follow.
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Resolve empty drive displayed as blank minor logic issue (#152)
    
    The previous commit "Remove coding landmine in get_disk() (#152)" made
    an empty drive without a disk label (partition table) display as
    nothing, instead of the normal single unallocated partition with warning
    "unrecognised disk label".
    
    The previous commit said:
        3. The two remaining direct calls to get_disk() where the strict
           parameter is explicitly set to false, from set_device_from_disk()
           and detect_filesystem_in_encryption_mapping(), are when scanning.
           As the pass strict=false they don't allow the PedDevice deletion
           to occur if no recognised disk label is found.
    
    This is true, but get_disk(..., strict=false) additionally returned true
    even if there was no disk label.  And in set_device_from_disk() the
    empty drive case is inside the if branch of the get_disk() call
    returning true.
    
    Simply fix this by calling get_disk(), ignoring the return value.
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Remove coding landmine in get_disk() (#152)
    
    get_disk() is the wrapper around libparted's ped_disk_new() which reads
    a disk label from the specified device and if successful creates the in
    memory PedDisk object to represent it.  In the case that libparted
    doesn't recognise a disk label or a file system, having get_disk() go
    and destroy the passed in PedDevice object via parameter lp_device is
    very unexpected behaviour hence describing it as a coding landmine.
    
    BACKGROUND
    
    1. Early on GParted only worked with devices with valid disk labels.
       FileSystem.h:open_device_and_disk() required both ped_device_get()
       and ped_disk_new() to succeed or neither to succeed.
    2. Commit [1] added support for devices which didn't yet have a disk
       label.  open_device_and_disk() had default parameter strict=true
       added.  While scanning strict=false was passed which allowed
       open_device_and_disk() to return success if only ped_device_get()
       succeeded and ped_disk_new() failed when the disk was empty.  All
       other times open_device_and_disk() was called with default
       strict=true, still requiring both or neither to succeed.
    3. Commit [2] added support for whole disk file systems.  The now named
       get_device_and_disk() had it's functionality split between
       get_device() and get_disk().  This result in the code landmine being
       left behind: get_disk() destroying the passed device object if
       default parameter strict=true and no disk label or file system was
       detected.
    
    ANALYSIS
    
    1. Since support for whole disk file systems [2] all current calls to
       get_device_and_disk() let the strict parameter default to true and
       are only called on known partitions within disk labels when applying
       a change to that partition.  Therefore they don't care about the
       behaviour of get_disk(), just that get_device_and_disk() maintains
       that both ped_device_get() and ped_disk_new() succeed or neither
       succeed.
    2. Two direct calls to get_disk() where the strict parameter defaults to
       true, from calibrate_partition() and erase_filesystem_signatures(),
       only do so on known partitions within disk labels as part of applying
       a change to that partition.  Therefore ped_disk_new() will succeed
       and so PedDevice isn't deleted when not wanted.
    3. The two remaining direct calls to get_disk() where the strict
       parameter is explicitly set to false, from set_device_from_disk() and
       detect_filesystem_in_encryption_mapping(), are when scanning.  As the
       pass strict=false they don't allow the PedDevice deletion to occur if
       no recognised disk label is found.
    
    FIX
    
    Remove the strict parameter from get_disk() and get_device_and_disk() as
    it's no longer needed.  Remove the code landmine by removing the side
    affect of destroying the PedDevice object if a disk label isn't found.
    Make sure get_device_and_disk() maintains the all or nothing behaviour.
    
    Also don't pass lp_device by reference to a pointer to get_disk() so the
    code can't change where lp_device points.
    
    [1] 038c5c5d99ad842f1a57f12222c884be29f4df4f
        P (special thanks to mantiena-baltix for bringing this issue to my
    
    [2] 51ac4d56489653854cd22787238a14bfa66a6ad4
        Split get_device_and_disk() into two (#743181)
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-14  Hugo Carvalho <hugokarvalho@hotmail.com>

    Update Portuguese translation

2021-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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] 749a2495716a82a7287fad943109b6cfb927245c
        Document blkid command as a mandatory requirement (#753436)
    
    Closes 148 - Encrypted file systems are no longer recognised

2021-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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:
        8b35892ea59958aa1eec596a48a36b0fa7950dca
        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-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02  Nathan Follens <nfollens@gnome.org>

    Update Dutch translation

2021-03-27  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation

2021-03-25  Hugo Carvalho <hugokarvalho@hotmail.com>

    Update Portuguese translation

2021-03-19  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Update HACKING file with coding style hints and tips

2021-03-20  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-20  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Refactor reiser4::read_uuid() into if fail return early pattern

2021-03-18  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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] https://github.com/edward6/reiser4progs/commit/4802cdb18ae03031d0e51a58b6655f3b99021ec2
        Fix up repair_master_print()
    
    [2] https://github.com/edward6/reiser4progs/commit/44cc024f398f60adef1519426d65f3f081ee826a
        Stop occasionally making file systems with null UUIDs
    
    Closes #145 - Sporadic failure of test case
                  My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4

2021-03-13  Jordi Mas <jmas@softcatala.org>

    Update Catalan translation

2021-03-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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] 39fdfe51da4bddecb2c99a9b544b270130423e72
        Exclude unit tests needing losetup in Docker CI image (!59)
    
    Closes #147 - GitLab CI job failure from *.CreateAndGrow/jfs

2021-03-06  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-01  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-08  Aurimas Černius <aurisc4@gmail.com>

    Updated Lithuanian translation

2021-03-05  Kukuh Syafaat <kukuhsyafaat@gnome.org>

    Update Indonesian translation

2021-02-23  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02-28  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02-28  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02-28  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02-28  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02-28  Mike Fleetwood <mike.fleetwood@googlemail.com>

    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-02-20  Yuri Chornoivan <yurchor@ukr.net>

    Fix minor typos in comments (!71)
    
    Closes !71 - Fix minor typos in comments

2021-02-23  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation
