Commit graph

2878 commits

Author SHA1 Message Date
Anders Jonsson
b7a0cc4724 Updated Swedish translation 2016-05-25 08:59:43 +00:00
Piotr Drąg
a5f1d2afec Updated Polish translation 2016-05-21 15:08:42 +02:00
Anders Jonsson
22dcc58fab Updated Swedish translation 2016-05-21 11:11:40 +00:00
Dušan Kazik
2477dffc06 Updated Slovak translation 2016-05-21 07:31:12 +00:00
Mike Fleetwood
29be7547cd Remove outdated comment fragment from activate_mount_partition()
Outdated by commit:
    6e97a63f49
    Always use blkid file system detection before libparted (#757781)
2016-05-20 09:25:48 -06:00
Mike Fleetwood
ab923121de 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-20 09:25:35 -06:00
Mike Fleetwood
b77fef0dd5 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-20 09:20:02 -06:00
Mike Fleetwood
302cc8041e 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-20 09:20:02 -06:00
Baurzhan Muftakhidinov
7bf8760346 Updated Kazakh translation 2016-05-17 10:37:49 +00:00
Curtis Gedak
4761f2e7cb Append -git to version for continuing development 2016-04-26 09:20:15 -06:00
Curtis Gedak
d66c544a45 ========== gparted-0.26.0 ========== 2016-04-26 09:02:57 -06:00
Daniel Șerbănescu
bf00339d71 Updated Romanian translation 2016-04-22 07:54:08 +00:00
Sveinn í Felli
c8bc8a81f1 Updated Icelandic translation 2016-04-19 19:58:41 +00:00
Cédric Valmary
a77698c64b Updated Occitan translation 2016-04-19 17:42:52 +00:00
Rafael Fontenelle
5258426f72 Updated Brazilian Portuguese translation 2016-04-19 17:18:34 +00:00
Rafael Fontenelle
3a8ba26937 Updated Brazilian Portuguese translation 2016-04-19 17:18:09 +00:00
Claude Paroz
3f28e5df2b Updated French translation 2016-04-19 18:52:54 +02:00
Mike Fleetwood
94979a3805 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-18 12:56:51 -06:00
Mike Fleetwood
fd9013d5f6 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-18 12:56:51 -06:00
Γιάννης Κουτσούκος
a93a678a7b Updated Greek translation 2016-04-17 18:39:33 +00:00
Stas Solovey
127e02cd04 Updated Russian translation 2016-04-13 18:19:30 +00:00
Cédric Valmary
50e47e41df Updated Occitan translation 2016-04-11 19:35:47 +00:00
Mike Fleetwood
e0a208576d 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-04-07 10:05:40 -06:00
Mike Fleetwood
d04826cc27 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-07 10:05:40 -06:00
Mike Fleetwood
a681f9f637 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-07 09:56:00 -06:00
Mike Fleetwood
366152e449 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:
    324d99a172
    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-07 09:56:00 -06:00
YunQiang Su
85ab4a82df Update zh_CN translation 2016-04-06 15:00:00 +08:00
Shi Jing
ce20293dda Update zh_CN translation 2016-04-06 14:56:20 +08:00
Milo Casagrande
c2e1cf38e2 Updated Italian translation 2016-04-05 07:18:42 +00:00
Mike Fleetwood
707bae6fed 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] d6d7cb2bbf
    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 11:03:33 -06:00
Muhammet Kara
7cf90f9e42 Updated Turkish translation 2016-03-28 11:19:43 +00:00
Mike Fleetwood
2bb78cf8dc 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-19 10:38:36 -06:00
Seong-ho Cho
c0b14f77f6 Updated Korean translation 2016-03-16 05:37:25 +00:00
Marek Černocký
53633b4f7e Updated Czech translation 2016-03-14 03:37:27 +01:00
Aurimas Černius
e36a6f0799 Updated Lithuanian translation 2016-03-13 21:44:34 +02:00
Tom Tryfonidis
7fe7983972 Updated Greek translation 2016-03-09 21:48:17 +00:00
Balázs Úr
48ca3d9420 Updated Hungarian translation 2016-03-04 22:21:44 +00:00
Rafael Fontenelle
461e5be8a8 Updated Brazilian Portuguese translation 2016-02-24 13:04:29 +00:00
Rafael Fontenelle
99cb9e6718 Updated Brazilian Portuguese translation 2016-02-24 11:41:21 +00:00
Josef Andersson
787871c4af Updated Swedish translation 2016-02-24 09:34:44 +00:00
Mike Fleetwood
1358a5f4fe 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-23 10:41:20 -07:00
Mike Fleetwood
2f2280e3d5 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-23 10:41:19 -07:00
Mike Fleetwood
6d28a62077 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-23 10:02:03 -07:00
hanniedu
b04ce3e312 Update Dutch translation 2016-02-22 16:39:57 +01:00
Мирослав Николић
fe97e564b0 Updated Serbian translation 2016-02-21 07:59:02 +01:00
Mike Fleetwood
ff9aeb8092 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)
    d6d7cb2bbf

[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-02-18 14:13:36 -07:00
Mike Fleetwood
822028b504 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-12 09:09:57 -07:00
Mike Fleetwood
2a55c65876 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
updated by the progress bar updates via it.

Change execute_command() to update the progress bar via the operation
detail it creates to hold the command being executed, instead of the
parent operation detail, to resolve the above.  Also replaces calling
operationdetail.get_last_child() throughout the method.

Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific
             copy methods
2016-02-12 09:09:57 -07:00
Mike Fleetwood
075154b4e8 Simplify XFS copy specific code progress bar usage (#760709)
Remove starting and stopping the progress bar in xfs::copy().  The
progress bar will be automatically started in xfs::copy_progress()
callback when run_progressbar() is called; and automatically stopped in
FileSystem::execute_command() when it calls stop_progress() at the end.

Note that this will now not initialise the progress bar from zero
immediately that the XFS copy is started, but instead 0.5 seconds into
the copy when xfs::copy_progress() timed callback is called for the
first time.

Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific
             copy methods
2016-02-12 09:09:57 -07:00
Mike Fleetwood
438b35aed9 Connect timed progress tracking callbacks inside execute_command() (#760709)
The timed progress tracking callback for execution of xfs copy follows
this pattern:

    sigc::connection c;
    ...
    c = Glib::signal_timeout().connect( ... sigc::mem_fun( *this, &xfs::copy_progress ) ..., 500 /*ms*/ );
    ... execute_command( ... );
    c.disconnect();

As with output progress tracking callbacks for ext2/3/4 and ntfs file
system specific commands, pass the callback slot and a flag into
execute_command() and connect the timed callback inside.  This
simplified the pattern to:

    ... execute_command( ...|EXEC_PROGRESS_TIMED,
                         static_cast<TimedSlot>( sigc::mem_fun( *this, &xfs::copy_progress ) ) );

NOTE:
The type of sigc::mem_fun() doesn't allow the compiler to choose between
the two overloaded variants of execute_command() with the fourth
parameter of either (full types without typedefs of StreamSlot and
TimedSlot respectively):
    sigc::slot<void, OperationDetail *> stream_progress_slot
    sigc::slot<bool, OperationDetail *> timed_progress_slot
Therefore have to cast the result of all callback slots to the relevant
type.  Hence:
    static_cast<StreamSlot>( sigc::mem_fun( *this, &{CLASS}::{NAME}_progress ) )
    static_cast<TimedSlot>( sigc::mem_fun( *this, &xfs::copy_progress ) )

References:
*   [sigc] Functor not resolving between overloaded methods with
    different slot types
    https://mail.gnome.org/archives/libsigc-list/2016-February/msg00000.html
*   Bug 306705 - Can't overload methods based on different slot<>
    parameters.
    https://bugzilla.gnome.org/show_bug.cgi?id=306705

Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific
             copy methods
2016-02-12 09:09:57 -07:00