# Generated by Makefile. Do not edit.

2016-06-13  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-0.26.1   ==========

2016-06-13  Milo Casagrande <milo@ubuntu.com>

    Updated Italian translation

2016-06-11  GNOME Translation Robot <gnome-sysadmin@gnome.org>

    Updated Scottish Gaelic translation

2016-06-10  Marek Černocký <marek@manet.cz>

    Updated Czech translation

2016-06-09  A S Alam <aalam@users.sf.net>

    Completed Punjabi Translation

2016-06-09  Daniel Șerbănescu <daniel@serbanescu.dk>

    Updated Romanian translation

2016-06-08  A S Alam <aalam@users.sf.net>

    updated Punjabi Translation

2016-06-07  Wolfgang Stöggl <c72578@yahoo.de>

    Updated German translation

2016-06-07  Alexandre Franke <alexandre.franke@gmail.com>

    Updated French translation

2016-06-04  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Prevent assert failure from OperationDelete::get_partition_new() (#767233)
    
    Composing these operations caused GParted to abort on an assert failure:
    (1) Delete an existing partition,
    (2) Create a new partition,
    (3) Delete new partition.
    
    This is the equivalent issue as fixed in the previous commit, except with
    the delete operation rather than the check operation:
        Prevent assert failure from OperationCheck::get_partition_new() (#767233)
    
        # ./gpartedbin
        ======================
        libparted : 2.4
        ======================
        **
        ERROR:OperationDelete.cc:41:virtual GParted::Partition& GParted::OperationDelete::get_partition_new(): assertion failed: (false)
        Aborted (core dumped)
    
        # gdb ./gpartedbin core.19232 --batch --quiet --ex backtrace -ex quit
        [New Thread 19232]
        [New Thread 19234]
        [Thread debugging using libthread_db enabled]
        Core was generated by `./gpartedbin'.
        Program terminated with signal 6, Aborted.
        #0  0x000000361f2325e5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
        #0  0x000000361f2325e5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        #1  0x000000361f233dc5 in abort () at abort.c:92
        #2  0x0000003620a67324 in g_assertion_message (domain=<value optimized out>, file=<value optimized out>, line=<value optimized out>, func=0x50fcc0 "virtual GParted::Partition& GParted::OperationDelete::get_partition_new()", message=0x1b55f60 "assertion failed: (false)") at gtestutils.c:1358
        #3  0x0000003620a678f0 in g_assertion_message_expr (domain=0x0, file=0x50fa68 "OperationDelete.cc", line=41, func=0x50fcc0 "virtual GParted::Partition& GParted::OperationDelete::get_partition_new()", expr=<value optimized out>) at gtestutils.c:1369
        #4  0x000000000049aa0d in GParted::OperationDelete::get_partition_new (this=0x1b321b0) at OperationDelete.cc:41
        #5  0x00000000004c6700 in GParted::Win_GParted::activate_delete (this=0x7ffc91403670) at Win_GParted.cc:2068
        ...
    
    As before the crash is happened in Win_GParted::activate_delete() as it
    was going through the list of operations removing those which applied to
    the never created partition.  It came across the delete operation of an
    existing partition and called get_partition_new().  As partition_new was
    not set or used by the delete operation this asserted false and crashed
    GParted.
    
    Unlike the check operation case, the delete operation doesn't have a
    partition afterwards.  (As GParted represents unallocated space with
    partition objects then the delete operation could be populated with a
    new partition by constructing the correctly merged unallocated space
    partition object, but that is what OperationDelete::apply_to_visual()
    does and having a place holder doesn't seem like the right thing to do).
    Instead exclude delete operations, on existing partitions, when looking
    for operations applying to this not yet created partition as they are
    mutually exclusive.
    
    Bug 767233 - GParted core dump on assert failure in
                 OperationDelete::get_partition_new()

2016-06-04  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Prevent assert failure from OperationCheck::get_partition_new() (#767233)
    
    Composing these operations caused GParted to abort on an assert failure:
    (1) Check an existing partition,
    (2) Create a new partition,
    (3) Delete new partition.
    
        # ./gpartedbin
        ======================
        libparted : 2.4
        ======================
        **
        ERROR:OperationCheck.cc:40:virtual GParted::Partition& GParted::OperationCheck::get_partition_new(): assertion failed: (false)
        Aborted (core dumped)
    
        # gdb ./gpartedbin core.8876 --batch --quiet --ex backtrace -ex quit
        [New Thread 8876]
        [New Thread 8879]
        [Thread debugging using libthread_db enabled]
        Core was generated by `./gpartedbin'.
        Program terminated with signal 6, Aborted.
        #0  0x000000361f2325e5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
        #0  0x000000361f2325e5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        #1  0x000000361f233dc5 in abort () at abort.c:92
        #2  0x0000003620a67324 in g_assertion_message (domain=<value optimized out>, file=<value optimized out>, line=<value optimized out>, func=0x50f400 "virtual GParted::Partition& GParted::OperationCheck::get_partition_new()", message=0x1d37a00 "assertion failed: (false)") at gtestutils.c:1358
        #3  0x0000003620a678f0 in g_assertion_message_expr (domain=0x0, file=0x50f1a8 "OperationCheck.cc", line=40, func=0x50f400 "virtual GParted::Partition& GParted::OperationCheck::get_partition_new()", expr=<value optimized out>) at gtestutils.c:1369
        #4  0x0000000000498e21 in GParted::OperationCheck::get_partition_new (this=0x1d1bb30) at OperationCheck.cc:40
        #5  0x00000000004c66ec in GParted::Win_GParted::activate_delete (this=0x7fff031c3e30) at Win_GParted.cc:2068
        ...
    
    When Win_GParted::activate_delete() was stepping through the operation
    list removing operations (2 & 3 in the above recreation steps) which
    related to the new partition never to be created it called
    get_partition_new() on all operations in the list.  This included
    calling get_partition_new() on the check operation (1 in the above
    recreation steps).  As partition_new was not set or used by the check
    operation get_partition_new() asserted false and crashed GParted.
    
    Fix by populating the partition_new member in OperationCheck objects,
    thus allowing get_partition_new() to be called on the object.  As a
    check operation doesn't change any partition boundaries or file system
    attributes, just duplicate the new partition from the original
    partition.
    
    Bug 767233 - GParted core dump on assert failure in
                 OperationDelete::get_partition_new()

2016-05-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Only enable ext4 64bit feature when required (#766910)
    
    E2fsprogs version 1.43 always creates 64bit ext4 file systems by default
    [1][2] regardless of the partition size.  Previously it only enabled the
    64bit feature when required on ext4 volumes 16 TiB and larger.  Also
    note that RHEL / CentOS 7 always create 64bit ext4 file systems by
    default from e2fsprogs 1.42.9 [3].
    
    (At least some versions of) Grub 2 and syslinux boot loaders don't work
    with 64bit ext4 file systems [4][5][6].  For maximum boot loader
    compatibility make GParted implement what mke2fs previously did, only
    setting the 64bit feature on volumes 16 TiB and larger and clearing it
    otherwise.  Only applied to mkfs.ext4 version 1.42 and later.
    
    [1] Release notes, E2fsprogs 1.43 (May 17, 2016)
        http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43
    
        "Mke2fs will now create file systems with the metadata_csum and
        64bit features enabled by default".
    
    [2] http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=cd27af3ecb83e8fd1e3eaa14994284a1818c7c15
        mke2fs: enable the metadata_csum and 64bit features by default
    
    [3] Comment 20 and 21 in Red Hat bug 1099237
        https://bugzilla.redhat.com/show_bug.cgi?id=1099237#c20
    
        "..., is rhel7 default behavior w.r.t. 64 bit really different from
        upstream ?
    
        Yes it is. This is what we have in RHEL7:
        Patch6: e2fsprogs-1.42.9-enable-64bit-feature-by-default.patch
        it fixed this bz: https://bugzilla.redhat.com/show_bug.cgi?id=982871
        and this is upstream proposal:
        http://www.spinics.net/lists/linux-ext4/msg42294.html"
    
    [4] Grub 2 not working on Slackware with 64bit EXT4
        http://www.linuxquestions.org/questions/slackware-14/grub-mkconfig-error-in-slackware-current-64-bit-4175580544/
    
    [5] Syslinux not working on Slackware with 64bit EXT4
        http://www.linuxquestions.org/questions/slackware-14/slackware64-current-5-20-2016-syslinux-booting-and-ext4-formatting-4175580324/
    
    [6] Syslinux not working on RHEL 7 with 64bit EXT4
        Bug 1099237 - rhel7 ext4 defaults to 64 bit, which extlinux can't reliably read
        https://bugzilla.redhat.com/show_bug.cgi?id=1099237
    
    Bug 766910 - Multiple boot loaders don't work on 64bit EXT4 file systems

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

    Don't limit ext4 volume size when 64bit feature is available (#766910)
    
    E2fsprogs 1.42 adds ext4 64bit feature [1] allowing volume sizes larger
    than 16 TiB.  However only enable large volumes from e2fsprogs 1.42.9
    when a large number of 64bit bugs were fixed [2].  (Also RHEL / CentOS 7
    use e2fsprogs 1.42.9 and always enable 64bit feature by default).
    
    [1] Release notes, E2fsprogs 1.42 (November 29, 2011)
        http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42
    
        "This release of e2fsprogs has support for file systems > 16TB.
        Online resize requires kernel support which will hopefully be in
        Linux version 3.2.  Offline support is not yet available for > 16TB
        file systems, but will be coming".
    
    [2] Release notes, E2fsprogs 1.42.9 (December 28, 2013)
        http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42.9
    
        "Fixed a large number of bugs in resize2fs, e2fsck, debugfs, and
        libext2fs to correctly handle bigalloc and 64-bit file systems.
        There were many corner cases that had not been noticed in previous
        uses of these file systems, since they are not as common.  Some of
        the bugs could cause file system corruption or data loss, so users
        of 64-bit or bigalloc file systems are strongly urged to upgrade to
        e2fsprogs 1.42.9".
    
    Bug 766910 - Multiple boot loaders don't work on 64bit EXT4 file systems

2016-05-28  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Limit maximum ext2/3/4 volume size to just less than 16 TiB (#766910)
    
    Maximum size of an ext2/3/4 volume is 2^32 - 1 blocks [1], ignoring ext4
    with 64bit feature.  That is just under 16 TiB with a 4K block size.
    
        # truncate -s 16T /mnt/1/sparse.img
        # ls -l /mnt/1/sparse.img
        -rw-r--r--. 1 root root 17592186044416 May 28 19:33 /mnt/1/sparse.img
        # losetup /dev/loop0 /mnt/1/sparse.img
        # mkfs.ext3 /dev/loop0
        mke2fs 1.43 (17-May-2016)
        mkfs.ext3: Size of device (0x100000000 blocks) /dev/loop0 too big to be expressed
                in 32 bits using a blocksize of 4096.
        # losetup -d /dev/loop0
        #
        #
        # truncate -s $((16*1024**3-4))K sparse.img
        # ls -l /mnt/1/sparse.img
        -rw-r--r--. 1 root root 17592186040320 May 28 19:51 /mnt/1/sparse.img
        # losetup /dev/loop0 /mnt/1/sparse.img
        # mkfs.ext3 /dev/loop0
        mke2fs 1.43 (17-May-2016)
        Discarding device blocks: done
        Creating filesystem with 4294967295 4k blocks and 536870912 inodes
        Filesystem UUID: 9721d8d9-8711-499b-aae4-8ea4d9e16ca2
        Superblock backups stored on blocks:
                32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
                4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
                102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
                2560000000, 3855122432
    
        Allocating group tables: done
        Writing inode tables: done
        Creating journal (32768 blocks): done
        Writing superblocks and filesystem accounting information: done
    
        # losetup -d /dev/loop0
        # rm /mnt/1/sparse.img
    
    Actually limit the maximum volume size to 1 MiB less than 16 TiB for
    coding reasons explained in the FIXME comment.
    
    [1] Ext4 Disk Layout, Blocks
        https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Blocks
    
    Bug 766910 - Multiple boot loaders don't work on 64bit EXT4 file systems

2016-05-30  Enrico Nicoletto <liverig@gmail.com>

    Updated Brazilian Portuguese translation

2016-05-30  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2016-04-20  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Stop leaking PedGeometry object memory (#767009)
    
    Calling libparted ped_geometry_new() creates a new PedGeometry object
    from malloced memory, however the corresponding ped_geometry_destroy()
    is never called to destroy the object and free the memory.
    
    Perform a resize of a FAT file system when running GParted under
    valgrind identifies several memory blocks leaked via ped_geometry_new()
    from resize_move_filesystem_using_libparted().  One such example:
    
        # valgrind --track-origins=yes --leak-check=full ./gpartedbin
        ...
        ==32069== 32 bytes in 1 blocks are definitely lost in loss record 5,419 of 11,542
        ==32069==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
        ==32069==    by 0x8ECD8C5: ped_malloc (libparted.c:231)
        ==32069==    by 0x8ED23C1: ped_geometry_new (geom.c:79)
        ==32069==    by 0x4764F3: GParted::GParted_Core::resize_move_filesystem_using_libparted(GParted::Partition const&, GParted::Partition const&, GParted::OperationDetail&) (GParted_Core.cc:2666)
        ==32069==    by 0x478007: GParted::GParted_Core::resize_filesystem(GParted::Partition const&, GParted::Partition const&, GParted::OperationDetail&, bool) (GParted_Core.cc:2990)
        ==32069==    by 0x478440: GParted::GParted_Core::maximize_filesystem(GParted::Partition const&, GParted::OperationDetail&) (GParted_Core.cc:3037)
        ==32069==    by 0x4769A0: GParted::GParted_Core::resize(GParted::Partition const&, GParted::Partition const&, GParted::OperationDetail&) (GParted_Core.cc:2746)
        ==32069==    by 0x47582B: GParted::GParted_Core::resize_move(GParted::Partition const&, GParted::Partition&, GParted::OperationDetail&) (GParted_Core.cc:2457)
        ==32069==    by 0x46DDB2: GParted::GParted_Core::apply_operation_to_disk(GParted::Operation*) (GParted_Core.cc:767)
        ...
    
    There is also a leak of a PedGeometry object from
    resize_move_partition().  Fix by calling ped_geometry_destroy() to
    delete all the allocated PedGeometry objects and free the memory.
    
    Bug 767009 - PedGeometry objects are memory leaked

2016-05-25  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Updated Swedish translation

2016-05-21  Piotr Drąg <piotrdrag@gmail.com>

    Updated Polish translation

2016-05-21  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Updated Swedish translation

2016-05-21  Dušan Kazik <prescott66@gmail.com>

    Updated Slovak translation

2016-05-06  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Remove outdated comment fragment from activate_mount_partition()
    
    Outdated by commit:
        6e97a63f49016ea6b0b48f37aedb10fe6ec808bb
        Always use blkid file system detection before libparted (#757781)

2016-05-15  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Replace whole path list after calibrate in apply_operation_to_disk() (#766349)
    
    When replacing the list of paths for the other partition object involved
    in either a Resize/Move or Format operation in apply_operation_to_disk()
    should replace the whole list of partitions not just replace with the
    first path.  Copy the whole path list is the correct action.  It makes
    no material difference because secondary partition paths are only used
    to discover mount points during refresh phase and not at the apply
    phase, where only the primary path is used.
    
    Bug 766349 - Resolve code ugliness with partition path getting set to
                 "copy of /dev/SRC"

2016-05-14  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Stop relying on sort order when adding real paths in calibrate (#766349)
    
    Quoting the relevant comments from GParted_Core::calibrate_partition():
        Re-add the real partition path from libparted.
    
        When creating a copy operation by pasting into unallocated space the
        list of paths for the partition object was set to
        ["Copy of /dev/SRC"] because the partition didn't yet exist before
        the operations were applied.  Additional operations on that new
        partition also got the list of paths set to ["Copy of /dev/SRC"].
        This re-adds the real path to the start of the list making it
        ["/dev/NEW", "Copy of /dev/SRC"].  This provides the real path for
        file system specific tools used during those additional operations
        such mkfs for the format operation or fsck and others for the
        resize/move operation.
    
        FIXME: Having this work just because "/dev/NEW" happens to sort
        before "Copy of /dev/SRC" is ugly!  Probably have a separate display
        path which can be changed at will without affecting the list of real
        paths for the partition.
    
    Having a separate display path is overly complicated and unnecessary.
    Just replace the list of paths with the real one reported by libparted
    if it contained "Copy of /dev/SRC", determined by checking if the file
    exists.  Otherwise continue to add the libparted name as an alternate
    path.  Whole disk devices can never be named "Copy of /dev/SRC" because
    they are not partitioned so never created or deleted by GParted, only
    ever written to, hence don't need the extra exists test logic.
    
    Bug 766349 - Resolve code ugliness with partition path getting set to
                 "copy of /dev/SRC"

2016-05-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Stop overriding real path when pasting into existing partitions (#766349)
    
    When composing a copy operation it always named the destination
    partition as "copy of /dev/SRC".  For the case of pasting into
    unallocated space creating a new partition this was the right thing to
    do as the partition doesn't yet exist so the path is not yet known.
    However for the case of pasting into an existing partition the path is
    known and replacing it with "copy of /dev/SRC" is wrong.  No other
    operation when operating on an existing partition changes it path.
    
    Given a set of existing partitions, sdb1 to sdb4, compose a set of copy
    operations as: copy sdb1 to sdb2, copy sdb2 to sdb3 and copy sdb3 to
    sdb4.  The displayed partitions before being applied become:
        /dev/sdb1
        copy of /dev/sdb1
        copy of copy of /dev/sdb1
        copy of copy of copy of /dev/sdb1
    And the pending operations are named:
        Copy /dev/sdb1 to /dev/sdb2
        Copy copy of /dev/sdb1 to /dev/sdb3
        Copy copy of copy of /dev/sdb1 to /sev/sdb4
    
    This is perverse.  In the case of pasting into an existing partition
    keep the real path name.  This keeps the partitions being displayed as:
        /dev/sdb1
        /dev/sdb2
        /dev/sdb3
        /dev/sdb4
    And the pending operations named as:
        Copy /dev/sdb1 to /dev/sdb2
        Copy /dev/sdb2 to /dev/sdb3
        Copy /dev/sdb3 to /dev/sdb4
    Much more understandable.
    
    Also switch to an upper case "C" in "Copy of /dev/SRC" as the temporary
    path name when pasting into unallocated space.  Finally update the
    comment in calibrate_partition() to describe the remaining cases when
    re-adding the path is still required.
    
    Bug 766349 - Resolve code ugliness with partition path getting set to
                 "copy of /dev/SRC"

2016-05-17  Baurzhan Muftakhidinov <baurthefirst@gmail.com>

    Updated Kazakh translation

2016-04-26  Curtis Gedak <gedakc@gmail.com>

    Append -git to version for continuing development

2016-04-26  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-0.26.0   ==========

2016-04-22  Daniel Șerbănescu <daniel@serbanescu.dk>

    Updated Romanian translation

2016-04-19  Sveinn í Felli <sv1@fellsnet.is>

    Updated Icelandic translation

2016-04-19  Cédric Valmary <cvalmary@yahoo.fr>

    Updated Occitan translation

2016-04-19  Rafael Fontenelle <rafaelff@gnome.org>

    Updated Brazilian Portuguese translation

2016-04-19  Rafael Fontenelle <rafaelff@gnome.org>

    Updated Brazilian Portuguese translation

2016-04-19  Claude Paroz <claude@2xlibre.net>

    Updated French translation

2016-04-18  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add symbolic constants SETTLE_DEVICE_*_MAX_WAIT_SECONDS
    
    Make the code a little more self documenting by adding the symbolic
    constants:
        SETTLE_DEVICE_APPLY_MAX_WAIT_SECONDS
        SETTLE_DEVICE_PROBE_MAX_WAIT_SECONDS
    which highlight that settle_device() is called in two different
    contexts, device probe and apply operations, with two different timeout
    values.

2016-04-14  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Wait for udev to recreate /dev/PTN entries when calibrating (#762941)
    
    File system specific commands sometimes fail reporting that the
    partition specific /dev entry doesn't exist.  Example failing check
    operation details:
    
        Check and repair file system (ext4) on dev/sdb4
          calibrate /dev/sdb4
            path: /dev/sdb4 (partition)
            start: 4196352
            end: 6293503
            size: 2097152 (1.00 GiB)
          check file system on /dev/sdb4 for errors and (if possible) fix them
            e2fsck -f -y -bv -C 0 /dev/sdb4
              e2fsck 1.42.9 (28-Dec-2013)
              e2fsck: No such file or directory while trying to open /dev/sdb4
              Possibly non-existent device?
    
    This has been reproduced on CentOS 7.  Debugging shows that the
    libparted calls used to re-read the partition details in
    GParted_Core::calibrate_partition() leads to udev removing and re-adding
    all the partition /dev entries for the disk.
    
        # udevadm monitor &
        # gpartedbin
        ...
         16.480662 +12.618659 calibrate_partition()          calling get_device("/dev/sdb", lp_device) ...
         16.483644 +0.002982 calibrate_partition()          get_device() returned
         16.483678 +0.000034 calibrate_partition()          calling get_disk(lp_device, lp_disk) ...
         16.618113 +0.134435 calibrate_partition()          get_disk() returned
        KERNEL[19275.707968] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block)
         16.618561 +0.000448 destroy_device_and_disk()      calling ped_disk_destroy(lp_disk) ...
         16.618584 +0.000023 destroy_device_and_disk()      ped_disk_destroy() returned
         16.618591 +0.000007 destroy_device_and_disk()      calling ped_device_destroy(lp_disk) ...
         16.618602 +0.000011 destroy_device_and_disk()      ped_device_destroy() returned
         16.618687 +0.000085 calibrate_partition()          return true
         16.618851 +0.000164 execute_command()              e2fsck -f -y -v -C 0 /dev/sdb4
        KERNEL[19275.708389] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block)
        KERNEL[19275.708500] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block)
        KERNEL[19275.708643] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block)
        KERNEL[19275.768278] change   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb (block)
        KERNEL[19275.771171] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block)
        KERNEL[19275.771360] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block)
        KERNEL[19275.771542] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block)
        KERNEL[19275.775858] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block)
        UDEV  [19275.820153] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block)
        UDEV  [19275.823152] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block)
        UDEV  [19275.828275] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block)
         16.742735 +0.123884 execute_command()              exit status 8
        UDEV  [19275.841425] remove   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block)
        UDEV  [19275.905478] change   /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb (block)
        UDEV  [19276.013580] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block)
        UDEV  [19276.034728] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block)
        UDEV  [19276.174840] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block)
        UDEV  [19276.237105] add      /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block)
    
    So exactly when GParted is running the external e2fsck command, udev is
    in the middle of removing and re-adding all the /dev partition entries
    for the disk.  Hence the above failure reporting that /dev/sdb4 didn't
    exist.  This error depends on the timing between GParted running the
    external file system specific command and udev removing and re-adding
    the entries, so sometimes it works and sometimes it fails.
    
    Further debugging showed that simply opening and closing the whole disk
    device read-write triggers the same removing and re-adding of all the
    partition /dev entries with udev >= 219.  Opening the whole disk device
    read-write is what libparted has always done until this post
    libparted 3.2 patch to make it open read-only when probing:
    
        http://git.savannah.gnu.org/cgit/parted.git/commit/?id=44d5ae0115c4ecfe3158748309e9912c5aede92d
        libparted: Use read only when probing devices on linux (#1245144)
    
    To fix this simply wait for udev devices to settle in
    calibrate_partitions().  The longest I have seen udev take to do this is
    0.80 seconds in a VM.  Wait up to 10 seconds as is done in commit() ->
    commit_to_os(), also called when applying operations.
    
    On configurations which don't have this issue execution of udevadm
    settle, which will return immediately, adds at most 0.1 seconds to the
    time taken for the calibrate step.  This won't be noticed in the time
    taken of the operation details so there is no point in trying to avoid
    executing udevadm settle when not needed.
    
    Bug 762941 - Operations sometimes failing with: No such file or
                 directory

2016-04-17  Γιάννης Κουτσούκος <giankoyt@gmail.com>

    Updated Greek translation

2016-04-13  Stas Solovey <whats_up@tut.by>

    Updated Russian translation

2016-04-11  Cédric Valmary <cvalmary@yahoo.fr>

    Updated Occitan translation

2016-03-22  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Minor tidyup in load_proc_partitions_info_cache()
    
    Minor issues:
    1) In the while loop reading from /proc/partitions into variable line,
       just after the sscanf() call the variable was re-purposed to hold the
       device name making the code unnecessarily hard to follow.
    2) Variable c_str was a fixed sized buffer holding the device name read
       from /proc/partitions.
    3) Variable c_str name provides no meaning as to what data it holds.
    4) Return value from all the Utils::regexp_label() calls is converted
       from Glib::ustring to std::string to be stored in device variable.
    
    Resolve by using Utils::regexp_label() to extract the device name from
    each line in /proc/partitions and store in the variable device, already
    used for this purpose and now changed to type Glib::ustring.

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

    Use realpath() safely (#764369)
    
    realpath(3) manual page says:
    
        BUGS
            The POSIX.1-2001 standard version of this function is broken by
            design, since it is impossible to determine a suitable size for
            the output buffer, resolved_path.  According to POSIX.1-2001 a
            buffer of size PATH_MAX suffices, but PATH_MAX need not be a
            defined constant, and may have to be obtained using pathconf(3).
            And asking pathconf(3) does not really help, since, on the one
            hand POSIX warns that the result of pathconf(3) may be huge and
            unsuitable for mallocing memory, and on the other hand
            pathconf(3) may return -1 to signify that PATH_MAX is not
            bounded.  The resolved_path == NULL feature, not standardized in
            POSIX.1-2001, but standardized in POSIX.1-2008, allows this
            design problem to be avoided.
    
    The resolved_path == NULL feature of realpath() has existed as a Glibc
    extension since realpath() was first added to Glibc 1.90, released in
    June 1996.  Therefore it can be used unconditionally.
    
        https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa0bc87c32d02cd81ec4d0ae00e0d943c683e6e1
    
    Bug 764369 - Use realpath() safely

2016-04-06  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Replace 32-bit member variable "index" with wider local variables (#764658)
    
    The previous commit (Fix crash reading NTFS usage when there is no
    /dev/PTN entry) identified that the FileSystem member variable "index"
    is too small on 64-bit machines.  Also this member variable stores no
    FileSystem class information and was being used as a local variable.
    
    Replace with local variables of the of the correct type, wide enough to
    store the npos not found value.
    
    Bug 764658 - GParted crashes when reading NTFS usage when there is no
                 /dev/PTN entry

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

    Fix crash reading NTFS usage when there is no /dev/PTN entry (#764658)
    
    On a 64-bit distribution, with an NTFS file system in a partition
    without a /dev entry then GParted will crash when attempting to read
    the file system usage.  Not having a /dev entry for the partition is
    rare and only known to occur for the disk devices used within Fake RAID
    (dmraid) arrays, and then only on Ubuntu 12.04 LTS.  Other/newer
    distributions do create /dev entries for partitions found on disk
    devices within Fake RAID arrays.
    
    Create mirror Fake RAID array:
        # dmraid -f isw -C MyArray --type 1 --disk /dev/sdc,/dev/sdd
        # dmraid -ay
    
    Create NTFS partition on the Fake RAID array.  On refresh GParted
    crashes:
        # ./gpartedbin
        (gpartedbin:590): glibmm-ERROR **:
        unhandled exception (type std::exception) in signal handler:
        what: basic_string::assign
    
    Without a /dev/sdc1 device entry the ntfsresize command reports this:
        # ntfsresize --info --force --no-progress-bar /dev/sdc1
        ntfsresize v2015.3.14 (libntfs-3g)
        ERROR(2): Failed to check '/dev/sdc1' mount state: No such file or directory
        Probably /etc/mtab is missing. It's too risky to continue. You might try
        an another Linux distro.
    
    The problem code in ntfs::set_used_sectors():
        145         index = output.find( "Cluster size" );
        146         if ( index == output.npos ||
        147              sscanf( output.substr( index ).c_str(), "Cluster size       : %Ld", &S ) != 1 )
    As "Cluster size" did not exist in the output find() returned the not
    found token of string::npos [1], which in a 64-bit environment is
    represented by 2^64-1 [2].  However it was saved in the variable index
    of type unsigned integer, which is only a 32-bit integer, thus
    truncating it to 2^32-1.  Therefore the comparison failed and sscanf()
    tried to parse the output starting at offset 2^32-1 which resulted in
    the crash.
    
    Introduced by commit:
        324d99a172848e4ff3fb7eb189f490bb4e6c53e5
        Record file system block size where known (#760709)
    
    Fix by following the same pattern of the other comparisons in
    ntfs::set_used_sectors() which checks if index is less than the output
    length.
    
    References:
    [1] std::string::find
        http://www.cplusplus.com/reference/string/string/find/
    [2] std::string::npos
        http://www.cplusplus.com/reference/string/string/npos/
    (Note that Glib::ustring is derived from std::string in the Standard C++
    library and provides a compatible interface).
    
    Bug 764658 - GParted crashes when reading NTFS usage when there is no
                 /dev/PTN entry

2016-04-06  YunQiang Su <yqsu@src.gnome.org>

    Update zh_CN translation

2016-04-06  Shi Jing <jingshi@ubuntukylin.com>

    Update zh_CN translation

2016-04-05  Milo Casagrande <milo@ubuntu.com>

    Updated Italian translation

2016-03-24  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Enable C++11 compilation when using libsigc++ 2.5.1 and later (#758545)
    
    As with glibmm [1] the latest versions of libsigc++ also uses ISO C++
    2011 features.  The NEWS file [2] says:
    
        2.5.1 (unstable):
    
        * Use (and require) C++11
          (Kjell Ahlstedt)
        * Using C++11 lambda functions to create sigc::slots:
          Avoid the need for SIGC_FUNCTORS_DEDUCE_RESULT_TYPE_WITH_DECLTYPE.
          (Kjell Ahlstedt)
    
    Without enabling C++11 compiler features, compilation of GParted with
    libsigc++ 2.5.1 and later fails with errors such as theses:
    
        /usr/include/sigc++-2.0/sigc++/trackable.h:40:3: warning: identifier 'noexcept' is a keyword in C++11 [-Wc++0x-compat]
           trackable_callback(void* data, func_destroy_notify func) noexcept
           ^
    
    [1] d6d7cb2bbf2fc381b890f63bbbf626eacfc8cdf8
        Enable C++11 compilation when using glibmm 2.45.40 and later (#756035)
    
    [2] libsigc++ 2.5.1 NEWS file
        https://git.gnome.org/browse/libsigcplusplus/tree/NEWS?h=2.5.1
    
    Bug 758545 - gparted-0.24.0 fails to build with gnome 3.18 mm packages
                 (on Gentoo)

2016-03-28  Muhammet Kara <muhammetk@gmail.com>

    Updated Turkish translation

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

    Limit FAT32 maximum volume size to 2 TiB
    
    GParted is allowing creation of a FAT32 formatted partition of any size.
    However with a 512 byte sector size the maximum volume size of a FAT32
    file system is reported to be 2 TiB.
    * Wikipedia: File Allocation Table / FAT32
      https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32
      "The boot sector uses a 32-bit field for the sector count, limiting
      the FAT32 volume size to 2 TB for a sector size of 512 bytes and 16 TB
      for a sector size of 4,096 bytes."
    * Microsoft: Default cluster size for NTFS, FAT, and exFAT / Default
      cluster sizes for FAT32
      https://support.microsoft.com/en-us/kb/140365
    
    Trying to create a FAT32 file system in a partition larger than 2 TiB
    results in unallocated space being left after the file system.
    
    Nuances:
    [1] Larger sector sizes allow larger maximum volume sizes up to 16 TiB
        with 4096 byte sectors.
    [2] mkdosfs/mkfs.fat has an -S SECTOR_SIZE option which allows changing
        the "logical" sector size of the file system allowing the maximum
        volume to be proportionally increased.
    [3] mkfs.fat appears to have an signed overflow bug when the size of the
        partition is larger than maximum signed 32-bit integer of logical(?)
        sectors.  (2 TiB for a sector size of 512 bytes).  It reports the
        partition size as minus size and creates a 1 TiB file system.
    
    GParted wants a single maximum file system size and the code is not
    ready for a differing maximum file system size for different sector
    sizes.
    
    In fat16::create() could specify larger "logical" sector sizes to
    mkfs.fat when the partition is larger than 2 TiB to allow maximum volume
    size to be increased further.  However that will take a lot of cross
    platform testing to ensure that all sorts of devices support "logical"
    sector sizes other than 512 bytes on devices with a hardware sector size
    of 512 bytes.  This is too much effort.
    
    Therefore implement a single FAT32 maximum volume size of 2 TiB.
    
    Bug 763896 - GParted not restricting creation of FAT32 volume to maximum
                 size of 2 TiB

2016-03-16  Seong-ho Cho <shcho@gnome.org>

    Updated Korean translation

2016-03-14  Marek Černocký <marek@manet.cz>

    Updated Czech translation

2016-03-13  Aurimas Černius <aurisc4@gmail.com>

    Updated Lithuanian translation

2016-03-09  Tom Tryfonidis <tomtryf@gnome.org>

    Updated Greek translation

2016-03-04  Balázs Úr <urbalazs@gmail.com>

    Updated Hungarian translation

2016-02-24  Rafael Fontenelle <rffontenelle@gmail.com>

    Updated Brazilian Portuguese translation

2016-02-24  Rafael Fontenelle <rffontenelle@gmail.com>

    Updated Brazilian Portuguese translation

2016-02-24  Josef Andersson <josef.andersson@gmail.com>

    Updated Swedish translation

2016-02-13  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Use a single progress bar for the internal block copy operation (#762367)
    
    As part of the internal block copy operation 5 initial ranges of blocks
    are copied using different block sizes to determine the fastest.  Then
    the remainder is copied using the fastest block size.  Each of these
    copies reports progress independently, so during the benchmarking phase
    the progress bar flashes 5 times as it goes from 0 to 100% in a fraction
    of a second, before showing the progress of the remainder.
    
    This looks bad, so report a single progress bar for all the ranges of
    blocks copied in a single copy operation.
    
    Already have variables done and length which track progress within each
    copied range; and total_done which records amount copied in previous
    ranges.  Just add total_length to allow overall progress to be reported.
    
    Bug 762367 - Use a single progress bar for the whole of the internal
                 copy operation

2016-02-13  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Update internal block copy, total_done after last progress report (#762367)
    
    Previously total_done was updated in copy_thread() after copying of the
    blocks, but importantly before the last call to set_progress_info() to
    update the progress bar.  Having total_done varying during the copy of a
    single range of blocks, single call to copy_blocks::copy(), is an
    impediment to being able to report a single progress bar across the
    whole internal copy operation.
    
    Move updating of total_done to copy() immediately after copy_thread()
    completes.
    
    Bug 762367 - Use a single progress bar for the whole of the internal
                 copy operation

2016-02-13  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Display progress of NTFS file system specific copy operation (#762366)
    
    Copying of ntfs is performed using ntfsclone, which writes progress
    indication to standard output like this:
    
        # ntfsclone -f /dev/sdb2 /dev/sdb1 2> /dev/null
        NTFS volume version: 3.1
        Cluster size       : 4096 bytes
        Current volume size: 21474832384 bytes (21475 MB)
        Current device size: 21474836480 bytes (21475 MB)
        Scanning volume ...
        100.00 percent completed
        Accounting clusters ...
        Space in use       : 1832 MB (8.5%)
        Cloning NTFS ...
        100.00 percent completed
        Syncing ...
    
    Add ntfsclone progress tracker for ntfsclone command.  Deliberately
    doesn't stop the progress bar.  See comment in ntfs::clone_progress()
    for the explanation.
    
    Bug 762366 - Add progress bar to NTFS file system specific copy method

2016-02-22  hanniedu <lafeber-dumoleyn2@zonnet.nl>

    Update Dutch translation

2016-02-21  Мирослав Николић <miroslavnikolic@rocketmail.com>

    Updated Serbian translation

2016-02-17  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Change to autoconf PKG_CHECK_EXISTS for set_default_icon_name() method (#762184)
    
    Previously the autoconf check for Gtk::Window::set_default_icon_name()
    method was a compile test because the documentation reported the method
    was available in gtkmm from 2.6 [1], however it wasn't available on
    RHEL / CentOS 5.x with gtkmm 2.10.
    
    Then commit [2] added detection and enabling of C++11 compilation, but
    after the above autoconf check.  So on Fedora 23 the compiler based
    autoconf check for set_default_icon_name() method failed because C++11
    compilation had not yet been enabled:
    
    >   checking for Gtk::Window::set_default_icon_name method... no
        checking for gtk_show_uri function... yes
        checking for Gtk::MessageDialog::get_message_area() method... yes
    >   checking for glibmm >= 2.45.40 which requires C++11 compilation... yes
    >   checking whether g++ supports C++11 features by default... no
    >   checking whether g++ supports C++11 features with -std=gnu++11... yes
    
    The gtkmm source code reveals that set_default_icon_name() method was
    only added in gtkmm 2.11.1 [3] so switch to a PKG_CHECK_EXISTS for this
    version of gtkmm.
    
    [1] gtkmm GTK::Window Class Reference
        https://developer.gnome.org/gtkmm/3.6/classGtk_1_1Window.html#a533d03e9b92d8ccd142ab3a44005cae4
    
    [2] Enable C++11 compilation when using glibmm 2.45.40 and later (#756035)
        d6d7cb2bbf2fc381b890f63bbbf626eacfc8cdf8
    
    [3] gtkmm NEWS file
        https://git.gnome.org/browse/gtkmm/tree/NEWS?h=gtkmm-2.14.0#n565
    
    Bug 762184 - Autoconf check for C++11 comes after compile test for
                 Gtk::Window::set_default_icon_name()

2016-01-09  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Always be explicit when emitting a signal by calling emit()
    
    Mostly the code is explicit and calls the emit() method when emitting a
    signal [1], like this:
        signal_name.emit();
    
    However there are a few cases which use the function call operator on
    the signal object [2], like this:
        signal_name();
    
    The behaviour is identical [3] but it is preferred to be explicit that a
    signal callback is being initiated, and it also makes them much easier
    to search for too.
    
    [1] List explicit emit() signal calls
            fgrep '.emit(' src/*.cc
    
    [2] List function call operator emitted signals
            egrep "`sed -n '/sigc::signal/s/.*sigc::signal.*> *\([a-zA-Z_]*\).*/\1/p' include/*.h | tr '\n' '|' | sed 's/\(.*\).$/[^a-zA-Z_](\1)\\\(/'`" src/*.cc
    
    [3] Quote from the libsigc++ Reference Manual, class sigc::signal
        https://developer.gnome.org/libsigc++/stable/classsigc_1_1signal7.html#ab37db0ecc788824d0baa3c301efc8dcd
    
            result_type sigc::signal<...>::operator()(...)
    
            Triggers the emission of the signal (see emit())

2016-02-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Leave commands with progress bars shown in the applying dialog (#760709)
    
    For non-progress tracked external commands the command being executed is
    displayed in the Apply pending operations dialog, just below the top
    pulsing progress bar.  However for progress tracked external commands
    the description of the parent operation detail is displayed instead.
    
    Example 1: non-progress tracked xfs check repair:
    
                                                                   TreePath
        Check and repair file system (xfs) on /dev/sdc1            0
        + calibrate /dev/sdc1                                      0:0
        + check file system on /dev/sdc1 for errors and (if po...  0:1
          + xfs_repair -v /dev/sdc1                                0:1:0
            + [empty stdout]                                       0:1:0:0
            + [stderr]Phase 1 - find and verify superblock...      0:1:0:1
    
    "xfs_repair -v /dev/sdc1" (TreePath 0:1:0) is shown because it is the
    latest updated operation detail which is timed (set to status
    executing).
    
    Example 2: progress tracked ext4 copy using e2image:
    
                                                                   TreePath
        Copy /dev/sdc2 to /dev/sdc3                                0
        + calibrate /dev/sdc2                                      0:0
        + check file system on /dev/sdc2 for errors and (if po...  0:1
        + set partition type on /dev/sdc3                          0:2
        + copy file system of /dev/sdc2 to /dev/sdc3               0:3
          + e2image -ra -p /dev/sdc2 /dev/sdc3                     0:3:0
            + [stdout]Scanning inodes...                           0:3:0:0
            + [stderr]e2image 1.42.9 (28-Dec-2013)...              0:3:0:1
    
    "copy file system of /dev/sdc2 to /dev/sdc3" (TreePath 0:3) is shown
    because that operation detail is also timed and it is being constantly
