Display the unallocated space in the graphical partition representation
and numeric figures in the Partition Information dialog.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Currently GParted assumes that a file system fills its containing
partition. This is not always true and can occur when resizing is
performed outside of GParted or a resize operation fails. GParted
doesn't display any information about unallocated space to the user
and in most cases it is simply included in used space.
Add partition unallocated space accounting. Make GParted record the
unallocated space for mounted file system and display a warning in the
Partition Information dialog when too much unallocated space is found.
Partition::set_sector_usage( fs_size, fs_unused ), is the new preferred
method of recording file system usage because it allows the unallocated
space in a partition to be calculated. Partition::Set_Unused() and
Partition::set_used() are now deprecated.
NOTES:
1) Set the minimum unallocated space to be 5% before considering it
significant to avoid false reporting. Worst case found was a
mounted xfs file system in a 100MiB partition, which reports as
~4.7% unallocated according to file system size from statvfs().
However, it reports as having no unallocated space using xfs
specific tools.
2) Unallocated space is only a graphical representation for the user.
GParted must still use relevant tools to resize file systems before
shrinking the data and can't assume all unallocated space exists
after the file system at the end of the partition.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
AFAICS, there is no reason to manually copy all partition fields,
or to manually initialize the copy of the new partition object.
So now the partition object is simply copied using assignment.
AFAICS, there is no reason to manually copy all partition fields,
or to manually initialize the copy of the new partition object.
So now the partition object is simply copied using assignment.
Normally the GUI should restrict partitions from overlapping other
partitions. However we have received a report where an overlap has
occurred.
Unfortunately we did not have enough details to recreate the problem.
Based on the report my thoughts are that somehow the problem arose
due to partitions aligned to boundaries other than MiB in combination
with the size of a partition being rounded up in the GUI resizer.
In an effort to prevent this problem in the future I have added a
check for primary or extended partitions overlapping other primary or
extended partitions.
Closes Bug #661744 - libparted "Can't have overlapping partitions."
after successful move+resize?!
Ensure at least 2 sectors for Extended Boot Record (EBR) between end
of logical partition and start of next logical partition.
Ensure at least 34 sectors reserved for backup GUID Partition Table
(GPT) after the end of the last partition.
GParted_Core::set_device_partitions() creates and initialises the
partition objects based on the partitions on the disk using
partition.Reset() and partition.Set(). These methods never set the
alignment attribute.
Copy and pasting into an existing partition calls GParted_Core::
snap_to_alignment() to adjust the start and end of the newly created
in memory partition object. When pasting into unallocated space the
user has selected the required alignment and this is exactly what is
needed. However when pasting into an existing partition the in memory
partition object should always match the actual partition boundaries on
disk. Unfortunately the partition boundaries are adjusted based on
reading the uninitialised alignment attribute.
Initialise the alignment attribute of newly created partition objects to
ALIGN_STRICT. Also, when pasting into an existing partition set the
alignment of that partition object to ALIGN_STRICT so that no boundary
adjustment is performed.
valgrind:
==6845== Conditional jump or move depends on uninitialised value(s)
==6845== at 0x80C779A: GParted::GParted_Core::snap_to_alignment(...) (GParted_Core.cc:566)
==6845== by 0x810C115: GParted::Win_GParted::Add_Operation(...) (Win_GParted.cc:692)
==6845== by 0x8110499: GParted::Win_GParted::activate_paste() (Win_GParted.cc:1649)
...
==6845== Conditional jump or move depends on uninitialised value(s)
==6845== at 0x80C77A8: GParted::GParted_Core::snap_to_alignment(...) (GParted_Core.cc:568)
==6845== by 0x810C115: GParted::Win_GParted::Add_Operation(...) (Win_GParted.cc:692)
==6845== by 0x8110499: GParted::Win_GParted::activate_paste() (Win_GParted.cc:1649)
GParted_Core.cc:
562 bool GParted_Core::snap_to_alignment( const Device & device, Partition & partition, Glib::ustring & error )
563 {
564 bool rc = true ;
565
>> 566 if ( partition .alignment == ALIGN_CYLINDER )
567 rc = snap_to_cylinder( device, partition, error ) ;
>> 568 else if ( partition .alignment == ALIGN_MEBIBYTE )
569 rc = snap_to_mebibyte( device, partition, error ) ;
570
Closes Bug #672654 - Pasting into an existing partition may shrink
GParted's representation of it
When resizing an extended boot record we must ensure that at least 2
sectors is reserved in front of the nearest logical partition for the
Extended Boot Record.
Please note that unless specifically told otherwise, the Linux kernel
considers Extended Boot Records to be two sectors long, in order to
"leave room for LILO".
Closes Bug #664050 - Unable to resize extended partition
Previously used "fsck.reiser4" to perform a file system check with a by
product of outputting the uuid. However this performs a lot of disk I/O
and takes a while to complete. Instead use the much faster and less
resource intensive "debugfs.reiser4" tool to retrieve the uuid.
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)
Mike Fleetwood