The parted-3.1 release brings back FAT16/FAT32 and HFS/HFS+ file
system resize capabilities in a new libparted fs resize library.
The following operations are again available when GParted is linked
with parted-3.1:
FAT16 - grow and shrink
FAT32 - grow and shrink
HFS - shrink
HFS+ - shrink
Note that there is a difference in how move actions are handled for
FAT16/FAT32 file systems based on parted version.
When GParted is linked with parted >= 3.0:
FAT16 - move performed internally by GParted
FAT32 - move performed internally by GParted
When GParted is linked with parted < 3.0:
FAT16 - move performed by libparted
FAT32 - move performed by libparted
Thanks goes to Jim Meyering for restoring these file system resizing
capabilities in Parted 3.1 with a new libparted fs resize library.
Closes Bug #668281 - minimal file-system resize API? (FAT and HFS*
only)
The setting of the write label capability for linux-swap was lost
when it was overwritten in the following commit:
Add support for setting UUID (#667278)
9e96159bb2
Even if invalid, the first filesystem in list is always included.
This is an off-by-one error, which was triggered when the first member
of FILESYSTEMS was no longer a regular filesystem, as a result of
commit ce9feeda0e9a04da04cec0a1b01512ed68c2495c:
'Make FileSystem objects in GParted_Core accessible and usable by others'
This assumption was invalidated by commit
ce9feeda0e9a04da04cec0a1b01512ed68c2495c:
'Make FileSystem objects in GParted_Core accessible and usable by others'
This patch removes the dependency on this implicit assumption.
Since linux-swap does not contain data and does not have a resize
command, linux-swap is recreated instead of moved, copied, or resized.
GParted 0.11.0 contained the following enhancement:
Bug #663980 - Avoid redundant file system maximize actions
An unfortunate side effect of this change was that the required
maximize action to recreate linux-swap would not occur when the new
size for the partition was less than or equal to the original size.
The changes associated with this commit address this regression.
Closes Bug #670017 - Corrupting swap partitions
Also update to use LVM terminology, such that a Physical Volume is
referred to as a member of a Volume Group. Status of an LVM2 PV is now
displayed using one of the following messages:
Not active (Not a member of any volume group)
VGNAME not active
VGNAME not active and exported
VGNAME active
Bug #160787 - lvm support
GParted would crash if there were any embeded spaces in the output from
the command used to query LVM2 PVs. There aren't normally any embeded
spaces, but they can occur in certain degrated situations. For example
if one of the PVs in a VG spanning two PVs is lost the PV is displayed
as "unknown device" rather than its actual device name:
# lvm pvs --nosuffix --units b --separator , -o pv_name,pv_free,vg_name,lv_name,lv_attr
Couldn't find device with uuid DMEi8r-9Vvy-w0Ok-CSSn-oLmY-YrY3-1PBznz.
PV,PFree,VG,LV,Attr
/dev/sda11,2143289344,GParted-VG1,,
unknown device,1619001344,GParted-VG1,lvol0,-wi---
unknown device,1619001344,GParted-VG1,,
This was loaded into the cache as:
["/dev/sda11,2143289344,GParted-VG1,,",
"unknown",
"device,1619001344,GParted-VG1,lvol0,-wi---",
"unknown",
"device,1619001344,GParted-VG1,,"]
The crash would happen when trying to access the VG name or LV flags on
a line without enough comma separated fields.
Improve parsing of the output from "lvm pvs" so that lines are not split
on embeded spaces. Don't crash on lines without without enough comma
separated fields.
Bug #160787 - lvm support
Previously any errors which occurred when running LVM commands used to
load the LVM2_PV_Info cache were simply ignored and the cache wasn't
loaded. This lead to missing information about LVM2 PVs, but the user
had no indication as to why.
Now when any errors occur the command ran and all output is captured.
This is displayed to the user, along with a suitable warning message, in
the Partition Information dialog.
Bug #160787 - lvm support
Btrfs file system can be successfully resized to the same size without
failing on Linux 3.2 or higher.
Linux 3.2-rc4 includes commit:
35bae54a255fbf3eab747b842d300d59f6e1abb4
Btrfs: Don't error on resizing FS to same size
Closes bug #669389
Create function Utils::kernel_version_at_least() to check that the
current Linux kernel is a particular version or higher.
Update nilfs2 to use this function to determine whether the kernel is
new enough to support file system resizing.
Restructure and word-smith translatable text associated with the
enhancement to add ability for setting UUID in an effort to better
align with the Gnome Documentation Style Guide.
See Bug #667278 - Add support for setting UUID
Algimantas Margevičius