Commit graph

3287 commits

Author SHA1 Message Date
Aurimas Černius
0effdb03a5 Updated Lithuanian translation 2018-03-19 23:35:52 +02:00
Curtis Gedak
295c649ace Append -git to version for continuing development 2018-03-19 10:29:11 -06:00
Curtis Gedak
62cd4a5d92 ========== gparted-0.31.0 ========== 2018-03-19 10:08:53 -06:00
Curtis Gedak
3f3209c6ba Update copyright year 2018-03-19 10:05:34 -06:00
Rūdolfs Mazurs
905f158d68 Update Latvian translation 2018-03-19 11:09:43 +00:00
Milo Casagrande
83cd11c6cc Update Italian translation 2018-03-18 16:55:46 +00:00
Trần Ngọc Quân
96e7ecbe74 Updated Vietnamese translation
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
2018-03-13 07:22:26 +07:00
Claude Paroz
6066d61686 Updated French translation 2018-03-12 17:47:50 +01:00
Anders Jonsson
76e9ec1c20 Update Swedish translation 2018-03-11 22:21:24 +00:00
Alan Mortensen
e393eb3e45 Updated Danish translation 2018-03-10 17:06:10 +01:00
Mario Blättermann
34e0c95407 Update German translation 2018-03-10 11:12:29 +00:00
Balázs Úr
3820783d85 Update Hungarian translation 2018-03-04 21:23:13 +00:00
Baurzhan Muftakhidinov
521f8eaba1 Update Kazakh translation 2018-03-03 15:56:18 +00:00
Daniel Șerbănescu
2678717057 Update Romanian translation 2018-03-03 13:07:57 +00:00
GNOME Translation Robot
0cd0c8731c Update Dutch translation 2018-03-02 20:05:24 +00:00
Piotr Drąg
1a4a6b1fbb Fix Spanish translation header 2018-02-24 00:27:46 +01:00
Daniel Mustieles
a79016dc53 Updated Spanish translation 2018-02-22 14:07:25 +01:00
Мирослав Николић
ff4f5e787e Updated Serbian translation 2018-02-17 23:57:25 +01:00
Kukuh Syafaat
23ffd4b46a Update Indonesian translation 2018-02-09 09:19:58 +00:00
Mike Fleetwood
fdc0f3b391 Remove deprecated USE_GNOME2_MACROS from autogen.sh
Use of USE_GNOME2_MACROS is deprecated in GNOME 3 and produced this
warning:

    $ ./autogen.sh
    /usr/bin/gnome-autogen.sh
    ...
    ***Warning*** USE_GNOME2_MACROS is deprecated, you may remove it from autogen.sh
    ...

It's use appears to have been removed first from GNOME 2.8 with this
commit from 2004:

    https://git.gnome.org/browse/gnome-common/commit/?id=ea9e85851445efa0135c3f8d08c3d1ea53760d91
    delete some files that were unused after the reorganisation

The oldest supported distribution is RHEL / CentOS 6 which is using
gnome-common-2.28.0 from 2009.  Therefore unconditionally remove the
USE_GNOME2_MACROS setting.

Also confirmed that it makes no difference by running ./autogen.sh with
and without USE_GNOME2_MACROS being set.  The produced GParted build
trees were the same.  Therefore the release and executable can't be
affected.
2018-02-08 21:58:51 +00:00
Curtis Gedak
0eb9f1fcfb Reduce dependency on scrollkeeper (#743318)
Scrollkeeper and the associated OMF catalog files are used by the
GNOME 2 version of yelp to display the GParted help manual.  To see how
this works try the following command:

  yelp ghelp:gparted

GNOME version 3 and higher yelp do not require scrollkeeper or the OMF
catalog files to properly display the GParted help manual.  And in fact
GNOME 3 deprecated the GNOME 2 method of building and installing GNOME
help documents altogether; including use of GNOME_DOC_INIT autoconf
macro, the gnome-doc-utils package and use of scrollkeeper.

  [GNOME 3] GNOME Goal: Port To New Documentation Infrastructure
  https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure

Further, the next release of Debian, Debian 10 (Buster), will be
removing the scrollkeeper / rarian package.

  rarian: Don't release with Buster
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885657

GParted is still a GNOME 2 app using GNOME 2 documentation build system
using autoconf GNOME_DOC_INIT macro.

  [GNOME 2] Migrating your documentation to gnome-doc-utils
  https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo

This is needed to build GParted documentation on still supported GNOME 2
distributions RHEL / CentOS 6.  So avoid requiring deprecated
scrollkeeper on GNOME 3 by automatically disabling scrollkeeper database
updates when the scrollkeeper-update command is not available.

  Executable          | Configure option used  | Use scrollkeeper
  scrollkeeper-update | on command line        | when building help
  exists?             |                        | for GParted?
  --------------------+------------------------+-------------------
  Yes                 | <none>                 | Yes
  Yes                 | --enable-scrollkeeper  | Yes
  Yes                 | --disable-scrollkeeper | No
                      |                        |
  No                  | <any>                  | No

Note that because GParted is still using the GNOME 2 documentation build
system it still builds and installs OMF files.  It is just that they are
not required with GNOME 3 yelp and this commit automatically disables
updating the scrollkeeper database when the scrollkeeper-update command
is not available.

Bug 743318 - configure script missing check for scrollkeeper dependency
2018-02-08 21:58:51 +00:00
Mike Fleetwood
578ebf133e Add comment about needing to compute encryption overhead in activate_format()
To explain why just using the size of the LUKS header won't always be
correct.
2018-01-28 10:09:35 -07:00
Mike Fleetwood
a3b47ca14a Move struct FS and FS_Limits into FileSystem.h
Struct FS and struct FS_Limits are strongly related to the FileSystem
class, both being return values from members and associated with storing
file system attributes.  Move their definitions from Utils.h into
FileSystem.h.
2018-01-28 10:09:35 -07:00
Mike Fleetwood
175d27c55d Rename enum FILESYSTEM to FSType
There are too many different types of things named "filesystem" in the
GParted code with the potential to cause confusion.  Namely:

    std::vector<FS> FILESYSTEMS
                              Vector of file system capabilities.

    class FileSystem          Base class interfacing to file system
                              specific executables for querying and
                              modification.

    enum FILESYSTEM           Symbolic constants representing each file
                              system type.

Many recent written or re-written functions already used a variable
named fstype.  Rename enum FILESYSTEM to enum FSType to clearly
distinguish it from the other things with very similar names.  Only
changing the name of the enumeration, not the name of variables of that
type too because that is a lot more lines of code and those can be
changed when the relevant code is re-written.
2018-01-28 10:09:35 -07:00
Mike Fleetwood
32c483c314 Fix cannot format error dialog which always reported the file system as encrypted
Try to format an existing partition with a file system which doesn't
fit.  The error dialog reporting the partition as too small or too large
always claimed the file system was encrypted, whether it was or not.
For example trying to format a 128 MiB partition as btrfs produces this
error dialog:

    (-) Cannot format this file system to [Encrypted] btrfs
        A [Encrypted] btrfs file system requires
        a partition of at least 256.00 MiB.
                                                   [  OK  ]

This commit:
    88136c96d7
    Extend functions generating encrypted file system string (#774818)
just completely missed handling the case for non-encrypted file systems
in Utils::get_filesystem_string().  Add the missed code.
2018-01-28 10:09:35 -07:00
Mike Fleetwood
46bf5a383e Extract common code into GParted_Core::get_filesystem_limits() (#787204)
There are multiple repetitions of the same code getting a FileSystem
object, checking for NULL and then calling the file system specific
get_filesystem_limits().  Extract that into a common function.

GParted_Core::get_filesystem_limits() can't use the file system from the
passed Partition object because that is the current file system which
will be different from the intended file system for new and format
operations.  So would look up the wrong derived FileSystem specific
object and call the wrong get_filesystem_limits().  Hence still needing
fstype as a separate parameter to pass the intended file system.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
ae2a8723b5 Set dynamic UDF file system size limits (#787204)
UDF file system minimum and maximum size limits are defined in terms of
numbers of file system blocks.  So when resizing an existing file system
compute the byte size limits from the existing UDF file system's block
size.  Alternatively when creating a new UDF file system use the
device's sector size as the multiplier instead.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
668957c0a4 Pass Partition object to get_filesystem_limits() (#787204)
As described in the previous commit, this is so that file system
specific implementations can dynamically determine size limits based on
Partition object attributes: such as the device sector size and the file
system block size.  (Assuming set_used_sectors() sets
partition.fs_block_size for the type of file system in question).

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
f8b38b7b31 Reorder code in Win_GParted::activate_paste() (#787204)
Background information about UDF is that when creating a file system
it's block size must match the underlying device's sector size.  For
optical media like CDs and DVDs that is 2K.  For hard drives that is
usually 512 bytes or 4K.  However if a UDF file system has been copied
from a device with a different sector size the UDF block size won't
match the sector size.  Linux will happily mount such UDF file system.

Therefore the derived udf::get_filesystem_limits() will need access to
the file system block size when determining the size limits of an
existing UDF file system being resized and use the device sector size
when a new UDF file system is being created.  All this can be queried
from an appropriate Partition object passed to get_filesystem_limits().
All the calls to get_filesystem_limits() have an appropriate Partition
object available already, except in Win_GParted::activate_reformat()
when composing a format operation.  Or more correctly
activate_reformat() constructs temp_ptn, a suitable Partition object,
including with fs_block_size member defaulting to -1 indicating not a
resize, but not until after the file system size limits had been checked
and get_filesystem_limits() called.

Therefore reorder the code in activate_paste() so that the file system
size limits are checked after the wanted Partition object has been
created.  No functional change with this commit.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
e234df6b2e Remove struct FS members .MIN & .MAX (#787204)
All the code has been switched to call get_filesystem_limits() and use
struct FS_Limits.  Remove struct FS members .MIN & .MAX.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
d5cd6ca349 Use struct FS_Limits in Win_GParted::activate_format() (#787204)
Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
8729556778 Use struct FS_Limits in GParted_Core::create() (#787204)
Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
4fa262d7e3 Switch to using struct FS_Limits inside Dialog_Partition_New (#787204)
Change Dialog_Partition_New to use a fs_limits rather than struct FS
and .MIN and .MAX.  No passing of struct FS_Limits required.  Just use
the FILESYSTEMS vector of struct FS to provide the file system type and
look up it's size limits each time the selection changes.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
53b7a75894 Query and pass struct FS_Limits into Dialog_Partition_Resize_Resize_Move (#787204)
Refactor Win_GParted::activate_resize() to query the file system size
limits using the new get_filesystem_limits() method and pass those
limits into the dialog class as struct FS_Limits.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
fe7b734792 Switch to using struct FS_Limits inside Dialog_Partition_Resize_Move (#787204)
Changes the internal code in Dialog_Partition_Resize_Move to use
fs_limits instead of fs.MIN and fs.MAX.  The limits are still passed
into the constructor via struct FS and it's members .MIN and .MAX but
immediately used to assign to fs_limits.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
285c24a82a Query and pass struct FS_Limits into Dialog_Partition_Copy (#787204)
Refactor Win_GParted::activate_paste() to query the file system size
limits using the new get_filesystem_limits() method and pass those
limits into the the dialog class as struct FS_Limits.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
fc436595fd Switch to using struct FS_Limits inside Dialog_Partition_Copy (#787204)
Adds working copy fs_limits member into common Dialog_Base_Partition
class.  Changes the internal code in Dialog_Partition_Copy class to use
fs_limits instead of fs.MIN and fs.MAX.  The limits are still passed
into the constructor via object of struct FS and it's members .MIN and
.MAX but immediately used to assign to the fs_limits member.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
aea0070799 Assign to duplicate FS_Limits (#787204)
Duplicate the assignment of file system size limits into
struct FS_Limits, matching the fixed values currently assigned to
struct FS members .MIN and .MAX.

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Mike Fleetwood
04535c48b3 Create separate file system limits structure and getter method (#787204)
PATCH SET OVERVIEW:

Currently the supported actions of each file system and their size
limits are stored in struct FS objects.  These are created by calling
file system specific derived implementations of
FileSystem::get_filesystem_support().  This happens when GParted is
started or when a when a rescan for supported actions is performed.  The
file system size limits are expressed as a fixed number of bytes.

The maximum UDF file system size is specified in terms of file system
block size units.  Also the file system block size must match the sector
size of the underlying device.  Typically 2K for optical media and 512
bytes or 4K for hard drives.

Therefore GParted can't properly express the true UDF file system size
limits because they depend on the block size of an existing UDF file
system or the sector size of the device for new UDF file systems.  In
fact other file systems such as EXT2/3/4 and XFS actually express their
maximum file system size in terms of numbers of file system blocks but
these tend to always be 4K and don't have to match the sector size of
the underlying device, so fixed byte values tend to suffice.

To update GParted for this, first separate file system size limits from
struct FS into struct FS_Limits and provide new
FileSystem::get_filesystem_limits() method to allow the limits to be
queried independently of the calls to get_filesystem_support().
Second, pass Partition objects and allow derived get_filesystem_limits()
implementations.

THIS PATCH:

Just creates a separate structure storing fixed value file system
minimum and maximum size limits along with getter method
get_filesystem_limits().

Bug 787204 - Minimum and maximum size of the UDF partition/disk
2018-01-28 10:09:35 -07:00
Marek Cernocky
c67e069b3a Updated Czech translation 2018-01-28 14:34:26 +01:00
Piotr Drąg
8c9261fecb Update Polish translation 2018-01-08 14:39:34 +01:00
Rafael Fontenelle
43a6e275d4 Update Brazilian Portuguese translation 2018-01-06 20:36:15 +00:00
gogo
118649bdb6 Update Croatian translation 2018-01-04 18:31:00 +00:00
Pali Rohár
2f532be9f9 Use external tools udfinfo and udflabel for UDF file system (#792052)
Those external tools were introduced in version 2.0 of udftools package
and can show or change UDF label, UDF uuid and can provide information
needed for counting total/free sectors.

Bug 792052 - Add support for changing UDF label/uuid and show disk usage
2018-01-04 17:02:53 +00:00
Mike Fleetwood
b04dbbc357 Rename function and reword text for rollback of failed file system move
To better reflect specifically that it is a failed (internally
implemented) file system move which is being rolled back.
2018-01-02 10:34:52 -07:00
Mike Fleetwood
f54dd10707 Fix rollback when growing a partition by more than twice fails (#791875)
Attempt to grow a partition to more than twice it's size.  If committing
that change to the partition fails in such a way that the new larger
partition boundaries are not written to the disk drive then rolling back
will fail with libparted error:
    Can't have overlapping partitions.

Example operation details:

    Grow /dev/sdb8 from 1.00 GiB to 2.20 GiB
    * calibrate /dev/sdb8                                      (SUCCESS)
    * check file system on /dev/sdb8 for errors and (if poss...(SUCCESS)
    * grow partition from 1.00 GiB to 2.20 GiB                 (ERROR)
    * attempt to rollback failed change to the partition       (ERROR)
        original start: 7350272
        original end:   9447423
        original size:  2097152 (1.00 GiB)
      * libparted messages                                     (ERROR)
          Can't have overlapping partitions.

What happened is that resize_move_partition() passed the new Partition
object to resize_move_partition_implement() as the source partition for
the rollback, and than called ped_disk_partition_by_sector() with a
sector in the middle to identify the partition to be changed.  However
the new partition was never written to the drive so in the middle was
outside the old smaller partition.  Therefore libparted identified empty
space after the partition, rather than the partition itself, as the
intended target so when ped_disk_set_partition_geom() was called it
reported error "Can't have overlapping partitions" because it thought
another partition was being created with the same boundaries as the old
partition, rather than the boundaries of the old partition being
updated.

The same error also occurs when rolling back a failed partition change
as part of a move operation when the middle of the new partition falls
outside of the boundaries of the old partition.

Fix by making a temporary Partition object from the intersection of the
old and new partition boundaries just to be used to identify the
partition being changed to libparted.  As this is only rolling back a
single step adjusting the partition boundaries as part of a resize
and/or move operation, the old and new partition boundaries must
intersect (and in fact that intersection contains the file system data).

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood
0b5bf83b22 Enable failed partition change rollback for selected steps (#791875)
The general rule is that:
1) For a partition change step BEFORE a file system change step,
   rollback on failure;
2) For a partition change step AFTER a file system change step, don't
   rollback on failure.

Examining every case where resize_move_partition() is called and whether
rollback on failure is wanted or not:

* In resize_move()
    Resize / move extended partition.  No associated file system change.
  NO ROLLBACK
    Just to keep possibly applied operation.

* #1 in move()
    Making all encompassing partition before moving file system.
  ROLLBACK
    To restore partition boundaries back to those of the file system.

* #2 in move()
    Recreating original partition boundaries after file system move
    failed or was cancelled and has been rolled back.
  NO ROLLBACK
    To keep updated partition boundaries to match restored file system
    data.

* #3 in move()
    Replacing all encompassing partition with final partition after
    successful file system move.
  NO ROLLBACK
    Keep new partition boundaries to match moved file system.

* #1 in resize_encryption()
    Making the partition larger before growing closed LUKS encrypted
    data.
  ROLLBACK
    Restore partition boundaries back to those of the closed LUKS
    encrypted data.

* #2 in resize_encryption()
    Shrinking the partition after open LUKS mapping has been shrunk, but
    before swap is re-created (smaller).
  NO ROLLBACK
    Difficult case because the partition shrink is in the middle of a
    LUKS shrink and a swap shrink (re-create).  If swap was actually
    shrunk like other types of file system, rather than re-created, then
    the operation sequence would be (1) shrink swap, (2) shrink LUKS
    encryption, (3) shrink partition.  In this hypothetical case and the
    actual case no rollback is preferred to try to keep the new
    partition boundaries match the shrunk open LUKS encryption mapping.

* #3 in resize_encryption()
    Grow the partition before growing open LUKS mapping and re-creating
    swap larger.
  ROLLBACK
    Restore partition boundaries back to those of the smaller open LUKS
    encryption mapping.

* #4 in resize_encryption()
    Shrink the partition after shrinking the file system and open LUKS
    encryption mapping.
  NO ROLLBACK
    Keep new smaller partition boundaries to match shrunk encrypted file
    system.

* #5 in resize_encryption()
    Grow the partition before growing the open LUKS encryption mapping
    and file system.
  ROLLBACK
    Restore partition boundaries back to those of the not yet grown
    encrypted file system.

* #1 in resize_plain()
    Resize partition before re-creating swap a different size.
  ROLLBACK
    Restore partition boundaries back to those of the not yet resized
    (re-created) swap space.

* #2 in resize_plain()
    Shrink partition after shrinking the file system.
  NO ROLLBACK
    Keep new smaller partition boundaries to match shrunk file system.

* #3 in resize_plain()
    Grow partition before growing the file system.
  ROLLBACK
    Restore partition boundaries back to those of the not yet grown
    file system.

Removes the default value from the rollback_on_fail parameter so
rollback or not has to be explicitly specified for every call of
resize_move_partition().

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood
0f16703bbb Implement rollback of failed partition resize/move steps (#791875)
Even after implementing a fix for bug 790418 "Unable to inform the
kernel of the change message may lead to corrupted partition table"
GParted/libparted can still encounter errors informing the kernel of the
new partition layout.  This has been seen with GParted on CentOS 7 with
libparted 3.1.

In such a case the partition has been successfully written to the disk
but just informing the kernel failed.  This is a problem because when a
partition is being moved in advance of a file system move step, failure
to inform the kernel leaves the partition boundaries not matching the on
disk limits of the file system.  For a move to the left this leaves the
partition reported as unknown, apparently losing the user's data.

For example start with a 512 MiB partition containing an XFS file
system.  This is recognised by blkid and parted, hence also by GParted.

    # blkid /dev/sdb1
    /dev/sdb1: UUID=... TYPE="xfs" PARTUUID="37965980-01"
    # parted /dev/sdb unit s print
    Model: ATA VBOX HARDDISK (scsi)
    Disk /dev/sdb: 16777216s
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    Disk Flags:

    Number  Start     End       Size      Type     File system  Flags
     1      1048576s  2097151s  1048576s  primary  xfs

Now move the partition 100 MiB to the left and have it fail to inform
the kernel after the first partition change step.  Operation details:

    Move /dev/sdb1 to the left                                 (ERROR)
    * calibrate /dev/sdb1                                      (SUCCESS)
    * check file system on /dev/sdb1 for errors and (if poss...(SUCCESS)
    * grow partition from 512.00 MiB to 612.00 MiB             (ERROR)
        old start: 1048576
        old end: 2097151
        old size: 1048576 (512.00 MiB)
        requested start: 843776
        requested end: 2097151
        requested size: 1253376 (612.00 MiB)
      * libparted messages                                     (ERROR)
          Error informing the kernel about modifications to partition
          /dev/sdb1 -- Device or resource busy.  This means Linux won't
          know about any changes you made to /dev/sdb1 until you reboot
          -- so you shouldn't mount it or use it in any way before
          rebooting.  Failed to add partition 1 (resource temporarily
          unavailable)

Now because the start of the partition is 100 MiB before the start of
the file system, the file system is no longer recognised, and apparently
the user's data has been lost.

    # blkid /dev/sdb1
    /dev/sdb1: PARTUUID="37965980-01"
    # parted /dev/sdb unit s print
    ...
    Number  Start    End       Size      Type     File system  Flags
     1      843776s  2097151s  1253376s  primary

It doesn't matter why updating the partition failed, even if it was
because of an error writing to the disk.  Rollback of the change to the
partition should be attempted.  The worst case scenario is that rollback
of the change fails, which is the equivalent to how the code worked
before this patch set.

However in other cases where the partition boundaries are being updated
after a file system move or shrink step then the partition should be
updated to match the new location of the file system itself.  And no
rollback is wanted.  If the failure was only informing the kernel then
in fact the partition has actually been updated on disk after all.

So each partition resize/move step needs examining on a case by case
basis to decide if rolling back the change to the partition is wanted or
not.

This patch only adds partition change rollback into
resize_move_partition().  Rollback remains disabled until all cases are
examined in the following patch.

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood
93ccc79e3a Extract common code into update_dmraid_entry() (#791875)
Extract common code which updates a DMRaid device mapper entry into a
sub-function.  This will also be needed when adding rollback of a
partition change on failure.

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00
Mike Fleetwood
890d5a93a7 Extract code into resize_move_partition_implement() (#791875)
Extract the code which actually implements the partition change into a
sub-function ready for adding rollback of the change on failure.

Bug 791875 - Rollback specific failed partition change steps
2018-01-02 10:34:52 -07:00