# Generated by Makefile. Do not edit.

2022-03-28  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-1.4.0   ==========

2022-03-28  Curtis Gedak <gedakc@gmail.com>

    Update copyright years

2022-03-27  Rūdolfs Mazurs <rudolfs.mazurs@gmail.com>

    Update Latvian translation

2022-03-27  Andika Triwidada <atriwidada@gnome.org>

    Update Indonesian translation

2022-03-25  Alan Mortensen <alanmortensen.am@gmail.com>

    Update Danish translation

2022-03-23  Kjell Cato Heskjestad <cato@heskjestad.xyz>

    Update Norwegian Bokmål translation

2022-03-18  Marek Černocký <marek@manet.cz>

    Updated Czech help translation

2022-03-17  A S Alam <aalam@fedoraproject.org>

    Update Punjabi translation

2022-03-16  Milo Casagrande <milo@milo.name>

    Update Italian translation

2022-03-13  Goran Vidović <trebelnik2@gmail.com>

    Update Croatian translation

2022-03-13  Goran Vidović <trebelnik2@gmail.com>

    Update Croatian translation

2022-03-10  Asier Sarasua Garmendia <asiersarasua@ni.eus>

    Update Basque translation

2022-01-27  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Disable unmount of busy jbds (#89)
    
    GParted automatically enables the Partition > Unmount action for busy
    partitions.  This is not going to be supported for jbds so disable it.
    
    Closes #89 - GParted doesn't recognise EXT4 fs journal partition

2022-01-25  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Suppress "Unable to find mount point" warning for jbds (#89)
    
    Closes #89 - GParted doesn't recognise EXT4 fs journal partition

2022-01-25  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Report busy status of jbds (#89)
    
    Continuing from the state in the previous commit, create an ext4 file
    system using the previously created external journal and mount it.
        # mke2fs -t ext4 -J device=/dev/sdb1 -L test-ext4 /dev/sdb2
        # mount /dev/sdb2 /mnt/2
    
    Did some experimenting with trying to create a second file system using
    the same external journal which is already in use.
        # mke2fs -t ext4 -J device=/dev/sdb1 -L 2nd-test-ext4 /dev/sdb3
        ...
        /dev/sdb1 is apparently in use by the system; will not make a journal here!
        # exit $?
        1
    
    Examined the source code of mke2fs and found that it performs an
    exclusive read-only open of the named journal block device to check if
    it is in use by the system or not [1].  Use the same method in GParted.
    
    Not used alternative method would be to mark the jbd active when the
    ext3/4 file system using it is active, but that requires working out the
    linkage between them.  That can be done using either blkid or dumpe2fs
    output but that involves parsing more fields and caching more data so is
    much more code than just testing the block device busy status using the
    same method which mke2fs uses.
    
    Matching UUIDs via blkid output.
        # blkid /dev/sdb1 /dev/sdb2
        /dev/sdb1: LABEL="test-jbd" UUID="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="jbd"
        /dev/sdb2: LABEL="test-ext4" UUID="cea5c2cd-b21c-4abf-a497-8c073bb12300" EXT_JOURNAL="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="ext4"
    
    Matching UUIDs via dumpe2fs output.
        # dumpe2fs -h /dev/sdb1 | egrep 'Filesystem UUID|Journal users'
        dumpe2fs 1.46.3 (27-Jul-2021)
        Filesystem UUID:          6e52858e-0479-432f-80a1-de42f9a4093e
        Journal users:            cea5c2cd-b21c-4abf-a497-8c073bb12300
        # dumpe2fs -h /dev/sdb2 | egrep 'Filesystem UUID|Journal UUID'
        dumpe2fs 1.46.3 (27-Jul-2021)
        Filesystem UUID:          cea5c2cd-b21c-4abf-a497-8c073bb12300
        Journal UUID:             6e52858e-0479-432f-80a1-de42f9a4093e
    
    If GParted was going to show the journal to file system linkage in the
    UI then doing this would be needed.  However so far there has only been
    a single reported case of a GParted user using an external journal,
    therefore adding the code complexity for this feature is not currently
    justified.  The simple busy detection method used by mke2fs is all that
    is needed.
    
    [1] mke2fs source code
        https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/
        misc/mke2fs.c:main()
            check_mount(journal_device, force, _("journal"));
        misc/util.c:check_mount()
            ext2fs_check_if_mounted(device, &mount_flags);
        lib/ext2fs/ismounted.c:ext2fs_check_if_mounted()
            ext2fs_check_mount_point(file, mount_flags, NULL, 0);
        lib/ext2fs/ismounted.c:ext2fs_check_if_mounted()
            if (stat(device, &st_buf) == 0 &&
                ext2fsP_is_disk_device(st_buf.st_mode)) {
                    int fd = open(device, O_RDONLY | O_EXCL);
                    if (fd >= 0) {
                            /*
                             * The device is not busy so it's
                             * definitelly not mounted. No need to
                             * to perform any more checks.
                             */
                            close(fd);
                            *mount_flags = 0;
                            return 0;
                    } else if (errno == EBUSY) {
                            busy = 1;
                    }
            }
    
    Closes #89 - GParted doesn't recognise EXT4 fs journal partition

2022-01-24  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Recognise jbd (journaling block device) (#89)
    
    A user reported that they were using an external journal with an ext4
    file system, but that GParted didn't recognise it.  (They had the jbd
    on an Intel Optane drive and the ext4 file system on an SSD).
    
    Create a jbd like this:
        # mke2fs -O journal_dev -L test-jbd /dev/sdb1
        # blkid /dev/sdb1
        /dev/sdb1: LABEL="test-jbd" UUID="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="jbd"
    
    Add recognition of jbd.  Use Blue Shadow colour, the same as ext4,
    because jbd is primarily used by ext3/4 [1][2].  jbd is also used by
    ocfs2 [1][3] and lustre [4][5] clustered file systems, but they are very
    unlikely to encountered by GParted users.  Also xfs [6] and jfs [7] can
    have external journals so if recognition of them is ever added they will
    get the same colour as their respective file systems too.
    
    [1] Journaling block device
        https://en.wikipedia.org/wiki/Journaling_block_device
        "JBD is filesystem-independent. ext3, ext4 and OCFS2 are known to
        use JBD"
    [2] https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_the_key_differences_between_jbd_and_jbd2.3F
    [3] OCFS2: The Oracle Clustered File System, Version 2
        https://www.kernel.org/doc/ols/2006/ols2006v1-pages-289-302.pdf
        "Metadata journaling is done on a per node basis with JBD"
    [4] Efficient Object Storage Journaling in a Distributed Parallel File
        System
        https://www.usenix.org/legacy/event/fast10/tech/full_papers/oral.pdf
    [5] Lustre Software Release 2.x Operations Manual
        https://doc.lustre.org/lustre_manual.pdf
        6.4.2. Choosing Parameters for an External Journal
    [6] mkfs.xfs(8) - construct an XFS filesystem
        https://man7.org/linux/man-pages/man8/mkfs.xfs.8.html
        "OPTIONS
        ...
        logdev=device
            This is used to specify that the log section should reside on
            the device separate from the data section.  The internal=1 and
            logdev options are mutually exclusive.
        "
    [7] jfs_mkfs(8) - create a JFS formatted partition
        https://manpages.debian.org/testing/jfsutils/jfs_mkfs.8.en.html
        "OPTIONS
        ...
        -j journal_device
            Create the external JFS journal on journal_device, ...
        "
    
    Closes #89 - GParted doesn't recognise EXT4 fs journal partition

2022-03-01  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Fix translation of DocBook markup tag of the GParted Manual (!98)
    
    As found by the GitLab Continuous Integration job on CentOS 7 with
    itstool 2.0.2, building the GParted Manual breaks on the Russian
    translation like this:
        $ ./autogen.sh
        $ make clean
        $ cd help
        $ make
        ...
        if ! test -d "ru/"; then mkdir "ru/"; fi
        if test -d "C"; then d="../"; else d="/home/mike/programming/c/gparted/help/"; fi; \
        mo="ru/ru.mo"; \
        if test -f "${mo}"; then mo="../${mo}"; else mo="/home/mike/programming/c/gparted/help/${mo}"; fi; \
        (cd "ru/" && itstool -m "${mo}" ${d}/C/index.docbook) && \
        touch "ru/ru.stamp"
        Error: Could not merge translations:
        'NoneType' object has no attribute 'node'
        make: *** [ru/ru.stamp] Error 1
    
    On Fedora 35 with itstool 2.0.6 building the GParted Manual merely
    reports a warning, leaving one paragraph untranslated, but the build
    completes successfully:
        $ ./autogen.sh
        $ make clean
        $ cd help
        $ make
        ...
        if ! test -d "ru/"; then mkdir "ru/"; fi
        if test -d "C"; then d="../"; else d="/home/fedora/programming/c/gparted/help/"; fi; \
        mo="ru/ru.mo"; \
        if test -f "${mo}"; then mo="../${mo}"; else mo="/home/fedora/programming/c/gparted/help/${mo}"; fi; \
        (cd "ru/" && itstool -m "${mo}" ${d}/C/index.docbook) && \
        touch "ru/ru.stamp"
        Warning: Could not merge translation for msgid:
        Set the <application>grub</application> root device by specifying the device returned by the <command>find</command> command. This should be the partition containing the boot directory. <_:screen-1/>
        ...
        $ echo $?
        0
    
    Fix translation of DocBook markup tag in the Russian translation of the
    GParted Manual by commit:
        17f4c3176d3be29d2867c080c0b292643d470627
        Update Russian translation
    
    Closes !98 - Fix translation of DocBook markup tag of the GParted Manual

2022-01-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Remove support for old volatile udev rules below /dev/.udev
    
    Udev stopped supporting volatile udev rules in /dev/.udev/rules.d in
    udev 176, released 2012-01-11 [1].  The oldest supported distributions
    use much more recent combined systemd and udev releases.
    
        Distro            EOL        udevadm -V
        Debian 9          2022-Jun   232
        RHEL / CentOS 7   2024-Jun   219
        Ubuntu 18.04 LTS  2023-Apr   237
    
    Now udev only reads volatile rules from /run/udev/ruled.d [2].  Simplify
    the code a little.
    
    [1] udev 176 NEWS
        https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/NEWS?h=176
        "A writable /run directory (ususally tmpfs) is required now for a
        fully functional udev, there is no longer a fallback to /dev/.udev."
    [2] man 7 udev
        "RULES FILES
        The udev rules are read from the files located in the system rules
        directory /usr/lib/udev/rules.d, the volatile runtime directory
        /run/udev/rules.d and the local administration directory
        /etc/udev/rules.d."

2022-01-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Prevent GParted probe starting stopped bcache (#183)
    
    From the setup in the previous commit, unregister (stop) all of the
    bcache backing and cache devices.
        # bcache unregister /dev/sdb2
        # bcache unregister /dev/sdb1
        # bcache unregister /dev/sdc1
        # bcache show
        Name        Type        State            Bname       AttachToDev
        /dev/sdb2   1 (data)    inactive         Non-Exist   Alone
        /dev/sdb1   1 (data)    inactive         Non-Exist   Alone
        /dev/sdc1   3 (cache)   inactive         N/A         N/A
    
    Run GParted.  Just the device scanning causes the stopped bcache devices
    to be restarted.
        # bcache show
        Name        Type        State            Bname       AttachToDev
        /dev/sdb2   1 (data)    clean(running)   bcache1     /dev/sdc1
        /dev/sdb1   1 (data)    clean(running)   bcache0     /dev/sdc1
        /dev/sdc1   3 (cache)   active           N/A         N/A
    
    This is nothing new with this patchset, but as a result of existing udev
    behaviour.  The chain of events goes like this:
    
    1. GParted calls ped_device_get() on each whole device;
    2. Libparted opens each partition read-write to flush the cache;
    3. When each is closed the kernel emits a block change event;
    4. Udev fires block rules to detect the possibly changed content;
    5. Udev fires bcache register (AKA start) rule.
    
    More details with the help of udevadm monitor, strace and syslog:
        GParted  | set_devices_thread()
        GParted  |   ped_device_get("/dev/sdb")
        Libparted|     ...
        Libparted|     openat(AT_FDCWD, "/dev/sdb1", O_WRONLY) = 9
        Libparted|     ioctl(9, BLKFLSBUF)        = 0
        Libparted|     close(9)
        KERNEL   | change   /devices/.../block/sdb/sdb1 (block)
        KERNEL   | add      /devices/virtual/bdi/250:0 (bdi)
        KERNEL   | add      /devices/virtual/block/bcache0 (block)
        KERNEL   | change   /devices/virtual/block/bcache0 (block)
        UDEV     | change   /devices/.../block/sdb/sdb1 (block)
        UDEV     | add      /devices/virtual/bdi/250:0 (bdi)
        UDEV     | add      /devices/virtual/block/bcache0 (block)
        UDEV     | change   /devices/virtual/block/bcache0 (block)
        SYSLOG   | kernel: bcache: register_bdev() registered backing device sdb1
    
        # grep bcache-register /lib/udev/rules.d/69-bcache.rules
        RUN+="bcache-register $tempnode"
    
    Fix this by temporarily adding a blank udev override rule to suppress
    automatic starting of bcache devices, just as was previously done for
    Linux Software RAID arrays [1].
    
    [1] a255abf3432ad106fac9c766f0816ada20be8e42
        Prevent GParted starting stopped Linux Software RAID arrays (#709640)
    
    Closes #183 - Basic support for bcache

2022-01-07  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Show bcache device as mount point of registered backing device (#183)
    
    A bcache device provides accelerated access to a backing device in a one
    to one relationship.  Multiple bcache backing devices can be attached to
    and accelerated by the same cache device.  Extending the setup from the
    previous commit, create an additional backing device and attach it to
    the same cache.
        # bcache make -B /dev/sdb2
        # bcache attach /dev/sdc1 /dev/sdb2
        # bcache show
        Name        Type        State            Bname     AttachToDev
        /dev/sdb2   1 (data)    clean(running)   bcache1   /dev/sdc1
        /dev/sdb1   1 (data)    clean(running)   bcache0   /dev/sdc1
        /dev/sdc1   3 (cache)   active           N/A       N/A
    
    List a couple of bcache specific sysfs files which identify registered
    (active) bcache devices (components).
        # ls -l /sys/block/sd?/sd??/bcache/{dev,set}
        lrwxrwxrwx. 1 root root 0 Jan  7 10:08 /sys/block/sdb/sdb1/bcache/dev -> ../../../../../../../../../../virtual/block/bcache0
        lrwxrwxrwx. 1 root root 0 Jan  7 11:53 /sys/block/sdb/sdb2/bcache/dev -> ../../../../../../../../../../virtual/block/bcache1
        lrwxrwxrwx. 1 root root 0 Jan  7 11:53 /sys/block/sdc/sdc1/bcache/set -> ../../../../../../../../../../../fs/bcache/9945e165-0604-4f29-94bd-b155d01080ad
    
    As was done with previous software block devices [1][2][3][4] show the
    bcache (access) device as the mount point of a backing device
    (component).  Use the /sys/block/DEV[/PTN]/bcache/dev sysfs symlinks to
    provide the bcache device names.  Bcache cache devices (components)
    don't get mount points because they aren't accessible.
    
    [1] commit 8083f11d84dbd4f186271a3cdbf5170db259f8b8
        Display LVM2 VGNAME as the PV's mount point (#160787)
    [2] commit f6c2f00df7858a7f4b97e699b9bcf1023bba850a
        Populate member mount point with SWRaid array device (#756829)
    [3] commit 538c866d099bc1f2bab3a41dc13a00b3d4336bbf
        Display array device as mount point of mdadm started ATARAID members
        (#75)
    [4] commit 538c866d099bc1f2bab3a41dc13a00b3d4336bbf
        Display array device as mount point of mdadm started ATARAID members
        (#75)
    
    Closes #183 - Basic support for bcache

2022-01-26  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Disable unmount of busy bcache devices (#183)
    
    GParted automatically enables the Partition > Unmount action for busy
    partitions.  Unregister (deactivate) bcache devices is not going to be
    supported so disable it.
    
    Closes #183 - Basic support for bcache

2022-01-07  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Report busy status of bcache (#183)
    
    Make (format as) bcache backing device (-B) and cache device (-C) and
    implicitly attach the backing device to the cache to enable caching, all
    in one.
        # bcache make -B /dev/sdb1 -C /dev/sdc1
        # bcache show
        Name        Type        State            Bname     AttachToDev
        /dev/sdb1   1 (data)    clean(running)   bcache0   /dev/sdc1
        /dev/sdc1   3 (cache)   active           N/A       N/A
    
    After experimenting with 'bcache unregister', 'bcache register' and
    stracing 'bcache show' the bcache kernel module creates the sysfs
    directory /sys/block/DEV[/PTN]/bcache and it's contents only when the
    bcache device is registered with the kernel (bcache component is
    active).  Use this to identify whether any bcache device (component)
    should be displayed as active or not in GParted.
        # ls -ld /sys/block/sd?/sd?1/bcache
        drwxr-xr-x. 6 root root 0 Jan  7 10:08 /sys/block/sdb/sdb1/bcache
        drwxr-xr-x. 2 root root 0 Jan  7 10:08 /sys/block/sdc/sdc1/bcache
    
    Closes #183 - Basic support for bcache

2022-01-07  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Also pass device_path into GParted_Core::is_busy() (#183)
    
    Will use this extra parameter when determining if a device or partition
    containing bcache is busy or not.
    
    Closes #183 - Basic support for bcache

2022-01-06  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Enable GParted to present bcache devices (#183)
    
    Add pattern to recognise block cache devices as valid devices for
    GParted to work with.  Devices are named by the Linux kernel device
    driver like /dev/bcache0 [1] with partitions named like /dev/bcache0p1
    [2].
    
    Note bcache devices can be partitioned but all the documents I have seen
    guide users to create file systems directly in a bcache device and not
    partition it [3][4] (plus all other Internet search results I looked
    at).  This might be because bcache is a specialist use case and the
    bcache backing device can be a partition itself.
    
    [1] linux 5.15 drivers/md/bcache/super.c bcache_device_init()
        https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/md/bcache/super.c?h=v5.15#n945
    [2] Contents of /proc/partitions for a bcache partitioned backing device
        $ grep bcache /proc/partitions
         251        0  524280 bcache0
         251        1  523256 bcache0p1
    [3] Linux kernel document: A block layer cache (bcache)
        https://www.kernel.org/doc/Documentation/bcache.txt
    [4] The Linux kernel user's and administrator's guide > A block layer
        cache (bcache)
        https://www.kernel.org/doc/html/latest/admin-guide/bcache.html
    
    Closes #183 - Basic support for bcache

2022-01-04  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add detection of bcache (#183)
    
    Use blkid to detect bcache formatted devices.  Requires blkid from
    util-linux >= 2.24 for detection of bcache devices [1].
    
    Use util-linux's FS images when testing GParted detection.
        # wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/bcache-B.img.xz
        # xzcat bcache-B.img.xz > /dev/sdb1
        # wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/bcache-C.img.xz
        # xzcat bcache-C.img.xz > /dev/sdc1
        # blkid /dev/sdb1 /dev/sdc1
        /dev/sdb1: UUID="8fb7f716-4c19-4517-bfbb-6f4a2becad60" TYPE="bcache" PARTUUID="f8f1485e-01"
        /dev/sdc1: UUID="7a343627-ac87-4bf0-b76f-46067cbc9b8c" TYPE="bcache" PARTUUID="f46e8c86-01"
    
    To tidy-up after testing GParted detection, stop the bcache device in
    case it was automatically started and wipe the signatures.  This is to
    prevent udev rules from automatically starting the bcache device on
    every subsequent reboot.
        # echo 1 > /sys/block/sdb/sdb1/bcache/stop
        # wipefs -a /dev/sdb1 /dev/sdc1
    
    Closes #183 - Basic support for bcache

2022-01-06  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Use face skin colours exclusively for software block devices (#183)
    
    Currently the Face Skin colour range from the GNOME palette represent a
    mixture of file systems and software block devices:
        JFS          - Face Skin Medium
        LVM2_PV      - Face Skin Dark
        NILFS2       - Face Skin Shadow
        LINUX_SWRAID - Dark Brown
        ATARAID      - Dark Brown
    
    We are about to add recognition of bcache [1][2][3], another software
    block device.  Reorganise the colour assignments so that Face Skin
    colour range is exclusively used by types of software block devices and
    assign JFS and NILFS2 new colours.
        Face Skin Light  (#EFE0CD) -
        Face Skin Medium (#E0C39E) - BCACHE         [New assignment]
        Face Skin Dark   (#B39169) - LVM2_PV
        Face Skin Shadow (#826647) - LINUX_SWRAID   [New assignment]
        Brown Dark       (#5A4733) - ATARAID
    
    NILFS2 has flash friendly characteristics [4] so use Accent Red colours
    along with F2FS.
        Accent Red      (#DF421E) - F2FS
        Accent Red Dark (#990000) - NILFS2   [New assignment]
    
    Move JFS to a group with XFS and UFS.  The hue of the GNOME palette
    Accent Yellow Dark colour, as used by UFS, was more Orange compared to
    Accent Yellow and a bit too close to the Orange used by BTRFS.  So use
    the hue of the GNOME Accent Yellow and extend the range and assign like
    this.
        Accent Yellow             (#EED680) - XFS
        Accent Yellow Dark        (#D6B129) - JFS   [Updated hue.
                                                     New assignment]
        Accent Yellow Shadow      (#AA8F2C) - UFS   [New colour.
                                                     New assignment]
        Accent Yellow Dark Shadow (#826F2B) -       [New colour]
    
    [1] bcache
        https://bcache.evilpiepirate.org/
    [2] Linux kernel document: A block layer cache (bcache)
        https://www.kernel.org/doc/Documentation/bcache.txt
    [3] The Linux kernel user's and administrator's guide > A block layer
        cache (bcache)
        https://www.kernel.org/doc/html/latest/admin-guide/bcache.html
    [4] NILFS, Relative performance
        https://en.wikipedia.org/wiki/NILFS#Relative_performance
    
    Closes #183 - Basic support for bcache

2022-02-25  Sergej A <sw@atrus.ru>

    Update Russian translation

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

    Remove unnecessary Glib::ustring::compose() of constant string

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

    Check copy destination instead of source (!95)(#723571)
    
    GParted currently performs these relevant steps for a copy operation:
    1.  Check source file system
    2.  Copy to destination
    3.  If destination partition is larger than source
    3.1.  check destination file system
    3.2.  grow destination file system
    
    Always checking the source was added by this commit:
        a54b52ea33abb1f5a44b52bcad5858ba41cd135d
        xfs copy now uses xfsdump and xfsrestore. icw some hacks in the other 2
        ...
        Also the source file system is now checked before the actual copy
        is performed.  If damaged beyond repair, the copy won't start.
    
    I think users have an expectation that a copy operation accesses the
    source read-only and performing a file system check on the source
    breaks that expectation.  Also uses may accidentally or deliberately try
    to copy a file system off a failing drive, where trying to check the
    source could lead to further data loss.  (ddrescue is the proper tool
    for recovering data from damaged drives but ddrescue is not a tool the
    user may know -- they know about GParted).
    
    For a failing drive, not checking the source first means the copy might
    fail instead, however a failed copy is preferable to greater chance of
    further damaging the source file system by checking it.
    
    In order to keep the new process as similar as possible to before,
    always check the destination instead.  This changes the copy operation
    from performing one or two file system checks to always performing only
    one check.  The new relevant copy operation steps are:
    1. Copy to destination
    2. check destination file system
    3. If destination partition is larger than source
    3.1.  grow destination file system
    
    This has exactly the same error handling as before, if the check of the
    destination file system fails the operation stops and any grow step
    won't be performed.  This represents the minimum change in behaviour
    from before.
    
    Bug 723571 - Copying ext4 partitions should not fix the source but the
                 destination
    Closes !95 - Check copy destination instead of source

2022-02-05  Luming Zh <lumingzh@qq.com>

    Update Chinese (China) translation

2021-11-23  Matej Urbančič <mateju@src.gnome.org>

    Update Slovenian translation

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

    Return and use constant reference from SWRaid_Info::get_label() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return constant reference from SWRaid_Info::get_uuid() (!94)
    
    Since the only use of SWRaid_Info::get_uuid() assign the returned value
    this doesn't actually save any copy construction.  Do it for consistency
    with the other get_*() methods in SWRaid_Info.
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from SWRaid::get_array() (!94)
    
    Have to use a second constant reference variable array_path_2 in
    GParted_Core::set_mountpoints() because by design C++ does not implement
    rebinding of references [1].
    
    [1] why doesn't C++ allow rebinding a reference?
        https://stackoverflow.com/questions/27037744/why-doesnt-c-allow-rebinding-a-reference
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return constant reference from OperationDetail::get_treepath() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return constant reference from OperationDetail::get_description() (!94)
    
    All uses of get_description() copy construct to a local variable, not
    assign to a reference, so this doesn't save anything.  It is just being
    done to be consistent with making other getters return a constant
    reference.
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Use constant reference from LVM2_PV_Info::get_vg_cache_entry_by_name() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from LVM2_PV_Info::get_vg_name() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Use constant reference from LVM2_PV_Info::get_pv_cache_entry_by_name() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Use constant reference from btrfs::get_cache_entry() (!94)
    
    Method already returned a constant reference.  Change local variables to
    constant references to avoid copy constructing them.
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from Partition::get_mountpoints() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from Partition::get_mountpoint() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from Partition::get_filesystem_label() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from Partition::get_path() (!94)
    
    Closes !94 - Make more getter methods use return-by-constant-reference

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

    Return and use constant reference from Device::get_path() (!94)
    
    A number of GParted methods named get_*() are returning properties and
    are return-by-value.  For objects this implies the returned value is
    copy constructed and later destroyed when it goes out of scope.  Change
    them to use return-by-constant-reference to avoid unnecessary object
    duplication.  Just have to make sure the reference goes out of scope
    before the referenced object is destroyed to avoid having a reference
    (pointer) to freed memory.  Assigning to a local variable instead of
    of a local reference still duplicates the object so can be used when the
    lifetime of the gotten object needs to be longer that the referenced
    object.
    
    Previously done for other getters here:
        d948cbcb9143dc975dd3c66defd7289eb4113b2c
        Make get_custom_text() and get_generic_text() return by reference
    
    This change just makes Device::get_path() return a constant reference
    and updates uses to match to avoid copy constructing the returned value.
    
    Closes !94 - Make more getter methods use return-by-constant-reference

2021-11-14  Matej Urbančič <mateju@src.gnome.org>

    Update Slovenian translation

2021-11-05  Yaron Shahrabani <sh.yaron@gmail.com>

    Update Hebrew translation

2021-11-05  Yaron Shahrabani <sh.yaron@gmail.com>

    Update Hebrew translation

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

    Make MB_Needed_for_Boot_Record() a static member function
    
    Because it doesn't access any member variables or call any member
    methods.

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

    Simplify logic in MB_Needed_for_Boot_Record() et al
    
    The first two clauses say is the partition object type unallocated
    inside an extended partition, or a logical partition (which only occur
    inside an extended partition).  As these are the only two partition
    object types which can occur inside an extended partition, this is
    equivalent to saying is the partition object inside an extended
    partition.  Simplify.

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

    Use previous unallocated partition when determining 1 MiB reservation in resize/move dialog
    
    The create new and paste into new dialogs are both composing a new
    partition into the unallocated selected_partition they are passed.  The
    starting sector of this unallocated partition is the first sector the
    newly composed partition could possibly have.  To ensure it doesn't
    overlay with the partition table or EBR (Extended Boot Records) it calls
    MB_Needed_for_Boot_Record() to indicate if the first 1 MiB needs to be
    reserved in the dialog or not.
    
    Code:
        Dialog_Partition_New::set_data(..., selected_partition, ...)
            ...
            MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(selected_partition);
    
        Dialog_Partition_Copy::set_data(selected_partition, ...)
            ...
            MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(selected_partition);
    
    However the resize/move dialog is different.  It is passed the existing
    selected_partition object and the vector of partitions from which it
    determines if there is a previous unallocated partition object or not.
    When there is no previous unallocated partition object, there is no need
    to reserve 1 MiB because the selected_partition can't be moved further
    to the left.  In the other case when there is a previous unallocated
    partition object the start of the existing selected_partition can be
    moved to the left.  However the code passes the selected_partition
    object to MB_Needed_for_Boot_Record() so doesn't have the first sector
    the newly composed partition could possibly have so doesn't reserve the
    first 1 MiB to prevent it overlapping with the partition table at the
    start of the drive.  These two commits addressed this limitation:
    * Ensure 1 MiB reserved when moving extended partition to start of drive
    * Ensure 1 MiB reserved when moving partition to start of disk
    
    Code:
        Dialog_Partition_Resize_Move::set_data(selected_partition, ...)
            new_partition = selected_partition.clone();
            if (selected_partition.type == TYPE_EXTENDED)
                Resize_Move_Extended(...);
            else
                Resoze_Move_Normal(...);
    
        Dialog_Partition_Resize_Move::Resize_Move_Normal(...)
            ...
            if (previous <= 0)
                MIN_SPACE_BEFORE_MB = 0;
            else
            {
                if (START < MEBIBYTE / new_partition->sector_size)
                    MIN_SPACE_BEFORE_MB = 1;
                else
                    MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(*new_partition);
            }
    
        Dialog_Partition_Resize_Move::Resize_Move_Extended(...)
            ...
            if (previous <= 0)
                MIN_SPACE_BEFORE_MB = 0;
            else
            {
                if (START < MEBIBYTE / new_partition->sector_size)
                    MIN_SPACE_BEFORE_MB = 1;
                else
                    MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(*new_partition);
            }
    
    So instead pass the previous unallocated partition object as that
    contains the left most start sector the newly composed partition could
    possibly have, therefore the check for overlapping the partition table
    in the first 1 MiB of the drive can succeed.

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

    Ensure 1 MiB reserved when moving extended partition to start of drive
    
    On an MSDOS partitioned drive, create an extended partition at least 2
    MiBs from the start of the drive.  Like this:
        dd if=/dev/zero bs=1M of=dev/sdb
        echo 4096,4096,5 | sfdisk -uS --force /dev/sdb
    
    The resize/move dialog appears to allow the extended partition to be
    moved and/or resized to the very start of the drive, over the top of the
    partition table, without reserving the first 1 MiB.  Ensure the dialog
    reserves the first 1 MiB, like it does when moving normal partitions.
    
    Reference:
        ceab9bde57fafbc96f9d90d2a86713cd07126f8b
        Ensure 1 MiB reserved when moving partition to start of disk

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

    Allow resize/move of partition to sector 2048 when following another (#172)
    
    This case is an extension of the setup in the previous commit.  Add a
    second partition several megabytes after the first.  It looks like this:
    
      [TABLE][PTN#1]                  [PTN#2]
      <-- 1st MiB -><- several MiBs ->
    
    Just need to make the gap 2 MiB or more so that it can be seen what the
    resize/move dialog is allowing.  Setup like this using an 8 MiB gap and
    8 MiB partition #2.
    
    For MSDOS use:
        dd if=/dev/zero bs=1M of=/dev/sdb
        (echo 1,2047; echo 18432,16384) | sfdisk -uS --force /dev/sdb
        mkswap /dev/sdb2
    
    For GPT use:
        sgdisk --zap-all /dev/sdb
        sgdisk --set-alignment=1 --new 1:34:2047 /dev/sdb
        sgdisk --new 2:18432:34815 /dev/sdb
        mkswap /dev/sdb2
    
    In GParted try to move partition sdb2 to the left as much as possible,
    or try to resize the start to the left as much as possible.  GParted
    insists on having a 1 MiB of padding before the start of sdb2, forcing
    it to start at sector 4096, even though sector 2048 is free and aligns
    to whole megabytes.
    
    Delete the preceding partition.  Now GParted allows sdb2 to be moved or
    resize to start at sector 2048.
    
    Fix another off by one error in the sector comparison for the
    resizing/moving of partitions.
    
    Closes #172 - GParted doesn't allow creation of a partition starting at
                  sector 2048 if there is a partition before it

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

    Allow creation of partition at sector 2048 when following another (#172)
    
    [This commit message and test case is written assuming a drive with a
    (logical) sector size of 512 bytes.  GParted equally well works with
    other sector sizes because the limit is expressed as 1 MiB / sector
    size.  Adjust the test case sector counts as needed when testing with
    different sector sized drives.]
    
    Prepare an MSDOS or GPT partitioned disk with the first partition within
    the first 1 MiB.
    
    For MSDOS use:
        dd if=/dev/zero bs=1M of=/dev/sdb
        echo 1,2047 | sfdisk -uS --force /dev/sdb
    
    For GPT use:
        sgdisk --zap-all /dev/sdb
        sgdisk --set-alignment=1 --new 1:34:2047 /dev/sdb
    
    In GParted create a new partition on /dev/sdb as near to the start of
    the drive as possible.  GParted insists on added an extra 1 MiB of space
    before the new partition, making it start at sector 4096, even though
    sector 2048 is free and aligns to whole megabytes.
    
    Delete the preceding partition.  Now GParted allows the new partition
    to be created starting at sector 2048.
    
    GParted only needs to add padding of 1 MiB to account for the partition
    table at the start of the drive when the possible start is within the
    first MiB, not already at the first MiB.  Fix this off by one error in
    the sector comparison.
    
    The reason this has bug has never occurred before is because it is very
    unusual to have the first partition entirely within the first 1 MiB.
    Normally either the (start of) the drive is free so GParted creates an
    unallocated partition object starting at sector 0, so adding 1 MiB of
    padding to preserve the partition table is correct; or the first
    partition starts at 1 MiB so the possible start for a second partition
    is much later in the drive.
    
    Closes #172 - GParted doesn't allow creation of a partition starting at
                  sector 2048 if there is a partition before it

2021-10-02  Pascal Engélibert <tuxmain@zettascript.org>

    Add accessibility relations (!92)
    
    Accessibility relations are essential for usage with screen readers.  It
    enables the screen reader to read the corresponding label along with the
    value of a widget when it gains focus, rather than just the value of the
    widget itself.
    
    Test by running Orca screen reader and tab around the elements of the UI
    and listen to what is read out.  For example before it would be
    "500 GiB", where as after it would be "Unused 500 GiB".
    
    Closes !92 - Add accessibility relations

2021-10-06  Dušan Kazik <prescott66@gmail.com>

    Update Slovak translation

2021-10-03  Aleksandr Melman <Alexmelman88@gmail.com>

    Update Russian translation

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

    Fix crash scrolling quickly in the drive selection combobox (#165)
    
    A user reported that scrolling the mouse wheel quickly crashes GParted
    [1].  The minimum setup required to reproduce this crash is 3 drives
    partitioned like this:
        sda - any
        sdb - some unallocated space
        sdc - no unallocated space
    Then move the pointer over the drive selection combobox and scroll the
    mouse wheel quickly downwards.
    
    The sequence of events goes like this:
    1.  The first scroll wheel down event causes the device combobox
        selection to change to the second entry (sdb), which calls
        combo_devices_changed() -> Refresh_Visual().
    2.  Refresh_Visual() sets selected_partition_ptr to point to the largest
        unallocated space partition object in sdb.
    3.  The first Gtk event processing loop in Refresh_Visual() comes
        across the next scroll wheel down event.  This changes the selection
        to the third entry (sdc), which makes a recursive call to
        combo_devices_changed() -> Refresh_Visual().
    4.  Refresh_Visual() sets selected_partition_ptr to NULL as sdc has no
        unallocated space and returns.
    5.  The first call to Refresh_Visual() resumes after the first Gtk event
        loop, continuing the processing for drive sdb.  As sdb has a
        largest unallocated space partition (largest_unalloc_size >= 0),
        DrawingAreaVisualDisk::set_selected() is called with the now
        NULL selected_partition_ptr.
    6.  One of the DrawingAreaVisualDisk::set_selected() methods
        dereferences the NULL pointer, crashing GParted.
    
    As a comment says of selected_partition_ptr "Lifetime:   Valid until the
    next call to Refresh_Visual()."  It just wasn't expected that the next
    call to Refresh_Visual() would be half way through Refresh_Visual()
    itself.
    
    Considered but rejected fixes:
    1.  Remove automatic selection of the largest unallocated space.
        Removes functionality.
    2.  Return at the top of Refresh_Visual() when called recursively.
        This causes GParted to not update the main window with the latest
        selected drive.  In the above example the combobox would show sdc,
        but the main window graphic and partition list would have only been
        updated once showing sdb, the first scrolled selection.
    
    Fix by only having a single Gtk event processing loop at the end of
    Refresh_Visual() with the optional calls to select the largest
    unallocated partition before that loop.  This makes it impossible to
    call the ::set_selected() methods with selected_partition_ptr modified
    by a recursive call.
    
    This fix reverts this earlier commit:
        0fb8cce6992f238b78272b603b69e070cfd46a00
        Reduce flashing redraw from automatic partition selection (#696149)
    
    That commit was in GParted 0.20.0 when Gtk 2 was still used.  Re-testing
    now doesn't see any flashing redrawing from the automatic partition
    selection, with GParted currently using Gtk 3.
    
