Win_Gparted and Dialog_Progress were creating threads to perform most
functions in the background. Most of the time, the only reason the
threads blocked was to execute an external command. The external command
execution has been changed to spawn the command asynchronously and wait
for completion with a nested main loop. While waiting for completion,
the pipe output is captured via events. In the future, this will allow
for it to be parsed in real time to obtain progress information.
Those tasks in GParted_Core that still block now spawn a background thread
and wait for it to complete with a nested main loop to avoid hanging the
gui.
Part of Bug #685740 - Refactor to use asynchronous command execution
Dialog_Progress was using pthread_create() so that it could later
pthread_cancel() the thread. pthread_cancel() is wildly unsafe and full
of errors. Changed to use Glib's threads like the rest, and only cancel
between operations. Because it can take some time to cancel, disable
the cancel button once it has been clicked once.
Bug 601239 - Please allow 'Cancel after current operation'
Win_Gparted and Dialog_Progress were looping on Gtk::Main::events_pending()
and iteration() with usleeps in between. Use a full mainloop instead and
a proper timeout to trigger pulsebar updates instead of usleeps.
Part of Bug 685740 - Refactor to use asynchronous command execution
No longer need to trim fat16, fat32 and xfs labels as all labels are
limited to their maximum lengths during entry.
Bug #689318 - filesystem type specific support for partition name
maximum length
Active Linux software RAID devices are detected in the
Proc_Partitions_Info method. Hence the SWRaid method is no longer
required.
Removal of the SWRaid method fixes the problem with the error message:
Could not stat device /dev/md/0 - No such file or directory
This fixes the problem because we no longer use "mdadm --examine
--scan" in an attempt to detect Linux software RAID devices. The
mdadm command was returning device names such as /dev/md/0, which are
incorrect for GParted.
NOTE: With this change, GParted no longer requires the mdadm command
to detect Linux software RAID devices.
Closes Bug #678379 - Could not stat device /dev/md/0 - No such file or
directory
They were used like global variables. Now they are moved to the
functions that actually use them to make clearer how the data flow is.
Bug #683149 - Cleanup(?): Remove lp_device and lp_disk from GParted_Core
GParted doesn't notice when a file system label is changed to blank.
GParted first calls the file system specific read_label() method. When
the label is blank read_label() correctly sets partition.label to the
zero length string. Second GParted_Core::set_device_partitions() treats
the zero length string to mean that the label is unset and calls
FS_Info::get_label() to retrieve it from the cache of blkid output.
Blkid also doesn't notice when the file system label has been changed to
blank so reports the previous label. Hence GParted displays the
previous file system label.
Fix by making label a private member variable of the class Partition and
providing access methods set_label(), get_label() and label_known()
which track whether the label has been set or not. This only fixes the
fault for file systems which use file system specific commands to read
the label and when these tools are installed. Otherwise GParted uses,
or has to fall back on using, the buggy blkid command to read the file
system label.
NOTE:
Many of the file system specific read_label() methods use a tool which
outputs more than just the label and use Utils::regexp_label() to match
leading text and the label itself. If the surrounding text changes or
disappears altogether to indicated a blank label, regexp_label() doesn't
match anything and returns the zero length string. This is exactly
what is required and is passed to set_label() to set the label to blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
A user had a 190 MiB partition containing an old ext2 file system. When
unmounted it was reported as filling the partition, but when mounted it
was reported as having 6% unallocated space. The file system's inode
tables were approximately twice the size of those created by default
with the current mkfs.ext2 defaults.
To create an equivalent file system in a 190 MiB partition:
mkfs.ext2 -N 97344 /dev/sda15
It turns out that for ext2, ext3 and ext4 file systems what was
described as intrinsic unallocated space during the development of
Bug #499202 is actually file system overhead. When mounted the ext2/3/4
kernel code reports the size of the file system after subtracting the
overhead. Overhead is made up of superblock backups, group descriptors,
allocation bitmaps and largest of all inode tables. E2fsprogs tools
don't subtract this overhead when reporting the file system size.
References:
* The Second Extended File System, Internal Layout, by Dave Poirier
http://www.nongnu.org/ext2-doc/ext2.html
* Linux ext2_statfs() function
http://lxr.linux.no/#linux+v3.5.3/fs/ext2/super.c#L1311
Call the file system specific method for reading the usage of ext2, ext3
and ext4 file systems while mounted. Make it read the file system size
from the on disk superblock to avoid subtraction of overhead and use the
statvfs() system call to return an up to date free space figure.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Each file system class can now choose how the size and free space of the
file system is determined when it is mounted.
.fs.online_read = FS::NONE (default)
Do nothing. Don't get the file system size and free space.
.fs.online_read = FS::GPARTED
Use internal GParted method which calls statvfs() system call on
the mounted file system.
.fs.online_read = FS::EXTERNAL
Call the file system's member function set_used_sectors(). This
is the same function as called when the file system is not
mounted. It can determine if the file system is mounted or not
by testing partition.busy and acting accordingly.
This means that determining the size and free space of active LVM2
Physical Volumes is no longer a special case. Instead the lvm2_pv class
just elects to have its set_used_sectors() method called for both the
active and deactive cases.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
On Fedora up to and including Fedora 16 and Red Hat and CentOS up to the
current 6.3 release the UUID of an unmounted reiserfs file system is
displayed as "<no" and a GTK markup warning is written to the terminal.
This was because the reiserfs-utils package isn't linked with libuuid
support so reiserfs file systems were created with a Nil UUID (all
zeros). To read the UUID GParted first tries to retrieve the UUID from
the blkid command output via the FS_Info cache. Secondly it tries the
reiserfs file system specific read_uuid() method which uses the first
space separated word following the text "UUID:", hence it gets "<no".
# debugreiserfs /dev/sda15 2> /dev/null | grep UUID
UUID: <no libuuid installed>
In September 2012 Red Hat bug 660285 "reiserfstune compiled without UUID
support" was fixed for Fedora 16 and later releases. On Fedora with
this fix applied GParted will display the Nil UUID (all zeros) for a
previously created reiserfs file system rather than suppressing it.
Only accept valid, none Nil UUIDs in the reiserfs file system specific
read_uuid() method.
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
As LVM2 Physical Volumes can't be resized when they are members of
exported Volume Groups add a warning message to explain this fact.
Display the message as a partition specific warning and as additional
text when growing the file system to fill the partition is skipped for
the check operation and when pasting into an existing larger partition.
Bug #670171 - Add LVM PV read-write support
When an inactive LVM2 Volume Group is exported it makes it unknown to
the local system, ready for moving the member Physical Volumes to
another system, where the VG can be imported and used. In this state a
PV can't be resized.
# lvm pvresize /dev/sda10
Volume group Test-VG1 is exported
Unable to read volume group "Test-VG1".
0 physical volume(s) resized / 1 physical volume(s) not resized
# echo $?
5
Fix this by preventing resizing of such a PV. This has been coded in a
generic way using new function filesystem_resize_disallowed() to
determine whether a file system is allowed to be resized or not. For
a file system which can be resized, but is currently not allowed to be
resized, the behaviour is as follows:
1) Pasting into unallocated space is limited to creating a new
partition which is the same size as the copied partition.
2) Resizing the partition is disallowed, only moving the partition is
allowed.
3) Pasting into an existing partition will only copy the file system.
If the destination partition is larger a warning will report that
growing the file system is not currently allowed.
4) Checking a partition will also report a warning that growing the
file system is not currently allowed.
This is exactly the same behaviour as for a file system which does not
implement resizing, except for a different warning message.
Bug #670171 - Add LVM PV read-write support
Create common cache search and index functions get_attr_by_name() and
get_attr_by_row() as the existing ones, get_pv_attr_by_*() and
get_vg_attr_by_*(), only differ from each other by the string vector
they use.
If an LVM2 Volume Group has two or more missing Physical Volumes, the VG
is displayed as only having one "unknown device" because
get_vg_members() only adds unique names to the list of members.
# lvm pvcreate /dev/sda11 /dev/sda12 /dev/sda13
# lvm vgcreate Test-VG1 /dev/sda11 /dev/sda12 /dev/sda13
# wipefs -a /dev/sda12
# wipefs -a /dev/sda13
View partition information in GParted
The simplest fix would be to include the PV's UUID in the cache of LVM2
information and add PV names based on unique UUIDs being a member of the
relevant VG. Unfortunately "lvm pvs" seems to have a bug when
displaying Logical Volume attributes, and there are two or more missing
PVs, which causes one of the PVs to be displayed multiple times, rather
than displaying each PV once.
Without LV attributes, every PV is listed:
# lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr 2> /dev/null
PV,PV UUID,VG,Attr
/dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-
unknown device,1ESORF-7wlR-0tnO-fy2z-nOL1-MrnJ-2O5yjK,Test-VG1,wz-pn-
With LV attributes, one missing PV is repeated:
# lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr,lv_name,lv_attr 2> /dev/null
PV,PV UUID,VG,Attr,LV,Attr
/dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-,,
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
Also "lvm vgs" and "lvm lvs" don't display anything when including both
VG and LV attributes.
Instead query the LVM2 information in two separate commands, one
querying PV attributes and one querying VG and LV attributes, saving the
results in lvm_pv_cache and lvm_vg_cache respectively.
Bug #670171 - Add LVM PV read-write support
Add const qualifier to get_pv_attr_by_path() and get_pv_attr_by_row() as
they only access member variables read-only.
Make lvm2_pv_attr_to_num() a static member function as it doesn't access
any member variables.
Rename functions and a variable to use a generic term for the menu item
which changes the busy state of partitions now that it also activates
and deactivates LVM2 Physical Volumes as well as mounting and unmounting
file systems and enables and disables swap partitions.
When attempting to delete a non-empty LVM2 Physical Volume (one which is
still a member of a Volume Group) display a warning dialog which
includes the VG name and a list of the PV members to allow the user to
make an informed choice whether to go ahead and perform the deletion or
cancel to the operation. This dialog is displayed when a partition
containing a PV is being deleted or being overwritten by being
reformatted or pasted into.
Bug #670171 - Add LVM PV read-write support
This commit only adds a remove() method to every file system and an
optional call to it in the relevant operations. All remove() methods
are no operations and not enabled.
The remove() method provides explicit controlled removal of a file
system before the partition is deleted or overwritten by being formatted
or pasted into. When implemented, it appears as an extra step in the
relevant operation. The file system specific remove() method is
explicitly allowed to fail and stop the operations currently being
applied.
This is different to the existing erase_filesystem_signatures() which
wipes any previous file system signatures immediately before a new file
system is written to ensure there is no possibility of the partition
containing two or more different file system signatures. It never fails
or reports anything to the user.
NOTE:
Most file systems should NOT implement a remove() method as it will
prevent recovery from accidental partition deletion.
Bug #670171 - Add LVM PV read-write support
In the Partition menu enable activation / deactivation of the LVM2
Volume Group of which the Physical Volume is a member.
Bug #670171 - Add LVM PV read-write support
Steps to reproduce:
1) Open any of these dialogs: Create New Partition, Resize/Move or
Paste;
2) Update any of the following numeric entry fields to a different value
using the keyboard: Free space preceding, New size or Free space
following;
3) Press [Esc] key;
Gparted crashes.
What is happening is that the [Esc] key is leading to the dialog being
closed and calling the ~Dialog_Base_Partition() destructor. However
after this the GTK widget is calling the on_spinbutton_value_change()
registered callbacks for the change to the other two values, on the now
just deleted object.
Fix by disconnecting the change notification callbacks in the
destructor.
Closes bug #682658 - GParted crash by pressing Esc in dialogs with
number entry
The member functions btrfs_size_to_num(), btrfs_size_max_delta() and
btrfs_size_to_gdouble() don't access any member variables. Therefore
they don't need the const qualifier allowing them to be called when the
btrfs object is const for read-only access to member variables, but
instead need to be static member functions with no access to member
variables.
Now that every call to calc_usage_triple() just passes usage figures
returned by get_sectors_*(), remove those parameters, call
get_sectors_*() internally and rename to get_usage_triple().
Stop using fraction_unallocated and fraction_used member variables of
the DrawingAreaVisualDisk class as intermediate storage of partition
usage fractions. Instead get the figures straight from the partition
class and use the new calc_usage_triple() to directly set pixels widths
for the partition usage graphic.
For specific partition usage values the right hand border of the
partition graphic in the Information dialog would be displayed as grey
rather than the color assigned to the partition.
Steps to reproduce fault:
Create 1024 MiB partition
# lvm pvcreate /dev/sda12
# lvm vgcreate GParted-VG1 /dev/sda12
View partition information
Fragment from Dialog_Partition_Info::init_drawingarea():
139 else if ( partition .sector_usage_known() )
140 {
141 used = Utils::round( ( 400 - BORDER *2 ) / ( dlength / partition .get_sectors_used() ) ) ;
142 unused = Utils::round( ( 400 - BORDER *2 ) / ( dlength / partition .get_sectors_unused() ) ) ;
143 unallocated = 400 - BORDER *2 - used - unused ;
144 }
For this issue the above values are both exactly x.5 and both round
upwards, resulting in unallocated being -1.
used = round((400 - 8*2)/(2097152.0/8192)) = round(1.5)
unused = round((400 - 8*2)/(2097152.0/2088960)) = round(382.5)
unallocated = 400 - 8*2 - 2 - 383 = -1
The simple fix would be to use floor() instead of round() in the
calculation of either used or unused. The same fix would also need to
be applied in Display_Info() for the calculation of the percentage
figures. Unfortunately this simple fix can lead to odd figures when the
used or unused is close to zero and floor() or ceil() is effectively
applied rather than round(). For example:
Size: 227.23 GiB
Used: 28.00 KiB ( 1% )
Unused: 180.00 GiB ( 79% )
Unallocated: 47.23 GiB ( 20% )
Used figure of 28 KiB in 227 GiB partition should be rounded to 0% but
wasn't.
Write Partition::calc_usage_triple() which calculates the "best" figures
by rounding the smaller two figures and subtracts them from the desired
total for the largest figure. Apply to the calculation of the partition
usage percentage figures in the Information dialog and the partition
usage graphic in the same dialog and the main window.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Most file systems report intrinsic unallocated space using the statvfs()
system call when mounted, but not using their own tools. They are:
ext2/3/4, fat16/32, hfs, nilfs2, reiserfs and xfs. Showing either a
little or no unallocated space, depending on whether a file system is
mounted or not, could be confusing to the user.
When all file systems are created filling their partitions the unused
figure reported by statvfs() and their own tools are the same or very
close. Also the used plus unallocated figure from statvfs() agrees with
the used figure from their own tools.
For all file systems don't display intrinsic unallocated space (that
below the threshold of 2 to 5%), instead include it as used space. As
soon as the amount of unallocated space becomes significant display it
everywhere and also trigger the warning.
For display purposes always use the new Partition methods:
get_sectors_used(), get_sectors_unused(), and get_sectors_unallocated().
When calculating new usage figures during Paste and Resize/Move
operations directly access sectors_used, sectors_unused and
sectors_unallocated members.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
A number of file systems report intrinsic unallocated space even when
they are created filling the partition. As reported using their own
specific tools, they are: jfs, lvm2 pv and ntfs. Therefore when
resizing a partition estimate its minimum size to be used sectors plus
any unallocated sectors up to the significant amount.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
The btrfs programs only provide approximations of file system sizes
because they display figures using binary prefix multipliers to two
decimal places of precision. E.g. 2.00GB. For partition sizes where
the contained file system size rounds upwards, GParted will fail to read
the file system usage and report a warning because the file system will
appear to be larger than the partition.
For example, create a 2047 MiB partition containing a btrfs file system
and display its size.
# btrfs filesystem show
Label: none uuid: 92535375-5e76-4a70-896a-8d796a577993
Total devices 1 FS bytes used 28.00KB
devid 1 size 2.00GB used 240.62MB path /dev/sda12
The file system size appears to be 2048 MiB, but that is larger than the
partition, hence the issue GParted has. (Actually uses the btrfs devid
size which is the size of the btrfs file system within the partition in
question).
This issue is new with the fix for Bug #499202 because it queries the
file system sizes for the first time. The same issue could
theoretically occur previously, but with the used figure (FS bytes
used). This would have been virtually impossible to trigger because
btrfs file system would have to have been greater than 99% full, but
btrfs has been notorious for early reporting of file system full.
The fix is that if a btrfs file system size appears larger than the
partition size, but the minimum possible size which could have been
rounded to the reported figure is within the partition size use the
smaller partition size instead. Apply the method to the used figure
too, in case the file system is 100% full. Also if the btrfs file
system size appears smaller than the partition size, but the maximum
possible size which could have been rounded to the reported figure is
within the partition size use the larger partition size instead to avoid
reporting, presumably false, unallocated space. Not applied to file
system used figure.
Bug 499202 - gparted does not see the difference if partition size
differs from filesystem size
When pasting a copied partition into free space or move/resizing a
partition set its space utilisation so that any unallocated space within
the partition is displayed correctly before the operation is applied.
NOTE:
If the file system does not support file system resizing the Paste and
Move/Resize dialogs don't allow resizing the partition so the preview
will always be correct, unlike the case in the previous patch:
Set unallocated space when performing simple operations (#499202)
Also remove the deprecated and no longer used Partition::Set_Unused()
and Partition::set_used() methods.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Display the unallocated space within a partition in the main window's
graphical disk representation.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Add reporting of the LVM2 Physical Volume size allowing the unallocated
space in the partition to be calculated.
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Update file system specific implementations to set the size and free
space, thus allowing the unallocated space in the partition to be
calculated, for the following unmounted file systems:
btrfs, ext2, ext3, ext4, fat16, fat32, jfs, nilfs2, ntfs, reiserfs,
reiser4, xfs
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
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
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)
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
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.
Phillip Susi