As failure of flushing the cache can lead to misidentification of file
systems make it a checked step in the displayed operation details.
Bug #688882 - Improve clearing of file system signatures
When wipefs command fails this means that in the display of the
operation results tree:
1) The command is displayed with a time and a stop sign, rather than no
time and a warning sign;
2) There is no report of any warnings or failures at the top level
summary.
(The immedately following "clear primary signatures" step will clear all
the file system signatures which wipefs failed to do. Should this fail
too it will report errors which will fail the whole operation).
Bug #688882 - Improve clearing of file system signatures
RHEL/CentOS 5.x uses util-linux 2.13 which predates the wipefs command.
Also the wipefs command may fail. Therefore implement a fallback which
caters for both these cases by overwriting all possible file system
super blocks with zeros at the start of the partition.
The "MUST be cleared" requirement stated in the first patch is now
satisfied. Therefore the status of the "clear old file system
signatures" step, as returned by erase_filesystem_signatures(), now
reflects the success of the wipefs command or the internal write zeros.
Failure of both will stop all operations, matching what happens with all
other steps.
Bug #688882 - Improve clearing of file system signatures
Before util-linux 2.21.0, released Feb 2012, wipefs only cleared one of
the three vfat (fat16/fat32) signatures it can be detected by each time
wipefs was run. Also if a nilfs2 file system was created before all
three signatures were cleared the partition was still recognised as a
vfat file system, albeit a corrupted one, rather than as a nilfs2 file
system.
Old wipefs clearing vfat signatures:
# wipefs --version
wipefs from util-linux 2.20.1
# wipefs -a /dev/sda7
8 bytes were erased at offset 0x52 (vfat)
they were: 46 41 54 33 32 20 20 20
# wipefs -a /dev/sda7
1 bytes were erased at offset 0x0 (vfat)
they were: eb
# wipefs -a /dev/sda7
2 bytes were erased at offset 0x1fe (vfat)
they were: 55 aa
New wipefs clearing vfat signatures:
# wipefs --version
wipefs from util-linux 2.21.2
# wipefs -a /dev/sda12
8 bytes were erased at offset 0x00000052 (vfat): 46 41 54 33 32 20 20 20
1 bytes were erased at offset 0x00000000 (vfat): eb
2 bytes were erased at offset 0x000001fe (vfat): 55 aa
Workaround by calling "wipefs -a" three times if the output indicated
only one vfat signature was cleared.
Bug #688882 - Improve clearing of file system signatures
When just formatting an existing partition to "cleared", GParted just
uses wipefs to clear the file system signatures. Afterwards parted/
libparted still detect the file system and GParted shows errors from the
file system specific tools reporting the file system doesn't exist.
# wipefs /dev/sda7
offset type
----------------------------------------------------------------
0x0 xfs [filesystem]
UUID: 28399a74-83a5-4ed7-aaf8-c76ac449fb57
# wipefs -a /dev/sda7
4 bytes were erased at offset 0x0 (xfs)
they were: 58 46 53 42
# parted /dev/sda print
Model: ATA SAMSUNG HM500JI (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 538MB 537MB primary ext4 boot
2 538MB 5907MB 5369MB primary linux-swap(v1)
3 5907MB 32.8GB 26.8GB primary ext4
4 32.8GB 500GB 467GB extended
5 32.8GB 355GB 322GB logical ext3
6 355GB 356GB 1074MB logical
7 356GB 357GB 1074MB logical xfs
# xfs_db -c 'sb 0' -c 'print blocksize' -c 'print dblocks' -c 'print fdblocks' -r /dev/sda7
xfs_db: /dev/sda7 is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
Wipefs was run on the partition specific block device (/dev/sda7) where
as libparted reads the disk using the whole disk device (/dev/sda).
However as the Linux buffer cache does not provide cache coherency, the
xfs file system can still be found in the cache of /dev/sda.
Fix this by calling ped_device_sync() after wipefs as it guarantees
cache coherency.
(As documented in erase_filesystem_signatures() there are cases when
calling ped_device_sync() isn't necessary, but testing shows that the
whole processes takes at most 0.15 seconds. As this is in the middle of
applying an operation, uses won't notice this extra time so just always
call ped_device_sync()).
Bug #688882 - Improve clearing of file system signatures
Add "cleared" to the bottom of list of file system formats available in
the Create new Partition dialog and in the Format to --> (file system
list) menu. This clears existing file system signatures in the newly
created partitions and existing partitions respectively.
Bug #688882 - Improve clearing of file system signatures
Move some code into new create_format_menu_add_item() sub-function which
adds one file system entry to the Partition --> Format to -->
(file system list) menu.
Bug #688882 - Improve clearing of file system signatures
Previously the function erase_filesystem_signatures() was used to clear
file system signatures when a new partition was created and when an
existing partition was formatted with a file system. However this was
only available with libparted <= 2.4 and then only for the file systems
which libparted supports.
Having multiple different file system signatures on a partition leads to
misidentification of file system. For example creating a nilfs2 over
the top of a fat32 file system is detected as a fat32, not nilfs2. This
shows that old file system signatures must be cleared before a new file
system is created.
Fix by always using "wipefs -a /dev/PARTITION" command to clear all old
file system signatures rather than libparted API calls. Failure from
wipefs is only considered a warning so doesn't fail the file system
creation. (This doesn't yet fully meet the "MUST be cleared"
requirement above. Will be fully met later in this patchset). Output
from the wipefs command is displayed as a new sub-step which looks like
this:
v Format /dev/sda7 as xfs 00:00:05
> calibrate /dev/sda14 00:00:01
v clear old file system signatures in /dev/sda7 00:00:01 [NEW]
> wipefs -a /dev/sda7 [NEW]
> set partition type on /dev/sda7 00:00:02
v create new xfs file system 00:00:01
> mkfs.xfs -f -L "" /dev/sda7
Also signatures are only cleared immediately before a new file system is
written and not when an unformatted partition is created. This allows
recovery from accidental partition deletion by re-creating the deleted
partition as unformatted.
Bug #688882 - Improve clearing of file system signatures
GParted fails to compile on RHEL/CentOS 5.9 because it doesn't provide
the Gtk::Window::set_default_icon_name() method. The "gtkmm GTK::Window
Class Reference" document says that set_default_icon_name() is available
in gtkmm >= 2.6, however it is not available in RHEL/CentOS 5.9 with
gtkmm 2.10.
Add an autoconf compile and link check for the set_default_icon_name()
method and make GParted only use the method when available.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
GParted fails to compile on RHEL/CentOS 5.9 because it doesn't provide
the Glib::Regex class. Glib::Regex class requires glibmm >= 2.14,
however RHEL/CentOS 5.9 only provides glibmm 2.12.
Add an autoconf check for the Glib::Regex class and fallback code using
the POSIX regex function. Fall back code is the same as that used prior
to commit:
b6f1c56fb1
Enhance regexp_label method to handle unicode characters
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
Only supports detection and creation of f2fs file systems. Requires
f2fs-tools and a blkid with f2fs support, util-linux > 2.22.2.
f2fs-tools v1.1.0 only supports file system creation.
Currently requires util-linux directly from the git repository as f2fs
support was only committed on 5 Feb 2013 and it has not yet been
released.
Closes Bug #695396 - Please apply f2fs patch
After a refresh, instead of having no partition selected, default to the
largest unallocated partition. This allows immediate creation of a new
partition in the unallocated space.
Bug 667365 - Free space should be selected by default
Many filesystems do not implement some of their methods, but had to provide
dummy implementations. Remove all of the dummy implementations and instead
just provide one in the base FileSystem class.
The details view refused to use additional space, even after the window was
expanded, instead continuing to use the scrollbars. Now resizing the
window will be allowed regardless of the state of the details expander, and
the details view will expand to use the extra space. Also request enough
initial width to not need a horizontal scrollbar.
Closes:
Bug 602635 - list of tasks in apply dialog does not expand to the available
vertical space
Bug 662722 - Increase default width of "applying..." dialog to include the
"Details" status icons
There were separate modules for ext3 and ext4 even though there
were virtually no differences with ext2. Remove the duplicate
modules and patch ext2 to serve as a common reference for all
three sub types.
After a move is canceled or fails, an attempt is made to revert the disk to
its previous state. This was moving back all blocks that had already been
copied. Many of the first blocks copied during a move do not overwrite
any valid data, and so do not need put back after an error, so don't bother
doing so.
After a failed or canceled move, the move was reverted, and the filesystem
was fscked while the partition was still in the expanded state encompassing
the original and destination partitions, resulting in errors and
corruption. Move fsck to after the partition table has been restored to
its original state.
After a refresh, instead of having no partition selected, default to the
largest unallocated partition. This allows immediate creation of a new
partition in the unallocated space.
Closes Bug 667365 - Free space should be selected by default
Interested operations can now connect a signal to their OperationDetail
to be notified of a cancelation request. The internal copy/move code
will now cleanly stop on cancelation, allowing the partition to be
rolled back to its previous state. This makes canceling a move
perfectly safe.
After clicking cancel, the button changes to "Force Cancel" and is
disabled for 5 seconds. Operations that are safe to cancel will do so
and those that are not will continue to run. Clicking force cancel
asks operations to cancel, even if doing so is unsafe. For the
internal copy/move algorithm, canceling is always safe because an
error results in a rollback operation. Canceling the rollback is
unsafe. For external commands, filesystem modules may indicate
that the command is safe to cancel or not. Canceled commands will
be terminated with SIGINT.
As a result of the new safe cancel vs force cancel distinction, the
scary warning about cancl causing corruption has been moved to
after clicking the force cancel button.
Part of Bug #601239 - Please allow 'Cancel after current operation'
Have the copy code create a background thread to do the actual copying so
that it won't block the main loop.
Part of Bug 685740 - Refactor to use asynchronous command execution
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
fat16 and fat32 were creating a temp mtoolsrc file to configure the
command to reference a drive letter and ignore certain errors. They have
been changed to pass this information via the command line and environment
instead.
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
Use of these functions is depreciated and making gtk calls in a background
thread still sometimes causes deadlocks or crashes. Change ped exception
handler to instead use an idle function to force the main thread to display
the dialog box.
Part of Bug 685740 - Refactor to use asynchronous command execution
When moving a MiB aligned primary partition from right to left, the
resulting partition was unexpectedly 1 MiB smaller in size.
From further testing, this occurred only if the move boundaries
overlapped the original partition boundaries.
In cases where the move did not overlap the original partition
boundaries, then the size remained the same.
Closes Bug #695078 - Move of MiB aligned partition right to left
yields unexpected shrink of 1 MiB
Add -I option to 'mkdosfs' command to work around faulty detection of
"complete disks" vs. "partitions".
Bug #693955 - mkdosfs detects "complete disk" vs. "partition" incorrectly
Thanks to Kano for reporting this!
(This will also be needed if GParted ever allows formatting a device without
partitioning it.)
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
For a reiser4 file system with exactly the maximum size 16 character
label, debugfs.reiser4 may include junk at the end of the label it
prints. (It reads the label into a 16 character array and prints it as
a string, but there isn't a nul terminating character).
# mkfs.reiser4 --yes --label abcdefghij123456 /dev/sda13
# debugfs.reiser4 /dev/sda13 2> /dev/null | grep label:
label: abcdefghij123456!
Trim the read label to at most 16 characters.
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
Add regular expression to detect the device entry only (e.g., md127)
and not the partitions (e.g., md127p1).
Linux software RAID devices are listed in /proc/partitions as follows:
# cat /proc/partitions
major minor #blocks name
9 127 523968 md127
259 0 131072 md127p1
259 1 262144 md127p2
Part of Bug #678379 - Could not stat device /dev/md/0 - No such file
or directory
HP Smart Array Devices are listed in /proc/partitions as follows:
major minor #blocks name
104 0 143338560 cciss/c0d0
104 1 104391 cciss/c0d0p1
104 2 24097 cciss/c0d0p2
104 3 143203410 cciss/c0d0p3
The previous regular expression was too broad, and would match many
other forms, including Linux software RAID devices such as md127.
Linux software RAID devices are listed in /proc/partitions as follows:
major minor #blocks name
9 127 523968 md127
259 0 131072 md127p1
259 1 262144 md127p2
This problem with the regexp was discovered while investigating a
problem with Linux software RAID device detection.
The regular expression has been tightened up to match the following
hardware RAID controllers:
Compaq/HP Smartarray RAID controller
E.g., device = /dev/cciss/c0d0, partition = /dev/cciss/c0d0p1
(linux-x.y.z/Documentation/blockdev/cciss.txt)
Compaq SMART2 Intelligent Disk Array controller
E.g., device = /dev/ida/c0d0, partition = /dev/ida/c0d0p1
(linux-x.y.z/Documentation/blockdev/cpqarray.txt)
Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers
E.g., device = /dev/rd/c0d0, partition = /dev/rd/c0d0p1
(linux-x.y.z/Documentation/blockdev/README.DAC960)
Related to Bug #678379 - Could not stat device /dev/md/0 - No such
file or directory
In certain situations with a mixture of partition alignments, the MiB
alignment option would try to set the end of a logical partition
beyond the end of the extended partition. This, of course, is an
invalid partition geometry and the libparted library correctly reports
failure when this is attempted.
This enhancement to MiB alignment adds a check to see if the end of
the logical partition would be beyond the extended partition, and
adjusts the end of the logical partition if required.
Closes Bug #686668 - Growing logical partition overlaps end of
extended partition
Prior to this enhancement, GParted ignored the status of the partition
grow operation, and attempted to grow the file system.
Now we check the status of the partition grow operation prior to
growing the file system.
Part of Bug #686668 - Growing logical partition overlaps end of
extended partition
A reiser4 file system with a blank label is displayed as "<none>" by
debugfs.reiser4 and therefore GParted too.
# mkfs.reiser4 -y -L "" -f /dev/sda14
# debugfs.reiser4 /dev/sda14 2> /dev/null | grep label:
label: <none>
Additionally when displaying the Partition Information the following
warning is written to the terminal:
(gpartedbin:19609): Gtk-WARNING **: Failed to set text from markup
due to error parsing markup: Error on line 1 char 23: Element
'markup' was closed, but the currently open element is 'none'
Fix by just assuming "<none>" always means blank. If someone really
does set the label to "<none>" it won't be displayed. This is equlivant
to how btrfs and nilfs2 are already handled.
Closes bug 688760 - GParted displays blank resier4 label as <none>
1) lp_disk is not used and assigned NULL so doesn't need closing.
2) lp_device is already ped_device_open()ed and ped_device_close()d
within the above while loop. lp_device will be set to NULL when the
while loop ends so this doesn't need closing either. Hence
close_device_and_disk() is always passed with two NULL pointers and is a
no operation so can be removed.
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
Use swaplabel to read the Linux swap label so that 1) a blank label can
be read, and 2) to replace deprecated and removed vol_id.
Vol_id was deprecated in May 2009, superseded by blkid and soon
thereafter removed. Swaplabel is available in util-linux 2.18 from Jun
2010.
If the swaplabel command is not available GParted falls back on reading
the label through the FS_Info cache which uses the blkid command. If
the blkid command is also not available FS_Info cache will *NOT* return
any label and GParted will display blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
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
Traced debugreiserfs on a 10GiB reiserfs file system which was 100% full
full with nearly 900,000 files. It read exactly three 4KiB blocks from
different offsets and the program never took more than 0.1 seconds.
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)
Vol_id command was deprecated in May 2009 and superseded by the blkid
command. Replace the generic vol_id command with the file system
specific debugfs.reiser4 command to read the file system label.
Debugfs.reiser4 will exist as it's already required to read the file
system usage and UUID.
Use the new RFC 4122 none Nil UUID regular expression to validate the
UUID read in all the Linux native file system specific read_uuid()
methods. No longer need to explicitly exclude "<none>" or all zeros Nil
UUID as the regular expression does this.
Not necessary but use the simpler file system tune command rather than
the file system debug command where possible. Also saves creating an
echo process.
For a mounted reiserfs file system with a Nil UUID (all zeros) GParted
will display a partition specific warning. This comes from the reiserfs
specific read_uuid() method. Error demonstration:
# blkid /dev/sda15
/dev/sda15: LABEL="test-reiserfs-2" TYPE="reiserfs"
# mount | grep sda15
/dev/sda15 on /mnt/2 type reiserfs (rw,relatime)
# reiserfstune /dev/sda15
reiserfstune: Reiserfstune is not allowed to be run on mounted filesystem.
Switch to using debugreiserfs to read the UUID as it can be used on a
mounted file system.
# debugreiserfs /dev/sda15 2> /dev/null | grep UUI
UUID: 00000000-0000-0000-0000-000000000000
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
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
Rescanning for supported actions in the File System Support dialog was
not detecting the removal and restoration of the lvm command. GParted
was only updating supported actions after refreshing all devices.
Checking for the lvm command was tied to the refresh of the LVM2_PV_Info
cache, hence the behaviour. Fix by always checking for the lvm command
when requested.
Also remove extra new line from end of an error message in
load_lvm2_pv_info_cache().
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
Active LVM2 PVs have the partition class busy member set in
GParted_Core::set_device_partitions() just as mounted file systems do.
This is a basic requirement for GParted so that it only manipulates
partitions and contained file systems when they are not in use.
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.
For LVM2 Physical Volumes the Volume Group name was looked up multiple
times, sometimes from the secondary location of the mount point and at
other times from the primary location in the LVM2_PV_Info class. Just
lookup the VG name once from the primary location.
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.
The new delete non-empty LVM2 Physical Volume warning dialog uses
Gtk::MessageDialog::get_message_area() in the display of Volume Group
members. This function was new in gtkmm 2.22, released September 2010,
which is not available in a number of current distributions including:
Unbuntu 10.04 LTS, RHEL 6.3, SLES 11-SP2, Debian 6.0.
Implement fallback method to display the VG name and member PVs in the
warning dialog for when get_message_area() is not available.
Bug #670171 - Add LVM PV read-write support
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
Implement remove() method so that the LVM2 metadata is updated to
reflect the removal of the LVM2 Physical Volume as well as removing the
signature from the PV before the partition is deleted or overwritten.
lvm pvremove /dev/DEVICE
Also specifically force the removal of the PV when it is a member of a
Volume Group so that it will succeed.
RATIONAL:
If the PV was not removed before the partition was deleted or
overwritten, LVM2 would be left in a broken state with metadata
describing missing PVs for any partially deleted VGs. This leaves the
user needing to perform recovery of a lost PV, which required in depth
understanding of LVM2 and is beyond the scope of what GParted can
currently provide.
The alternative is to use the pvremove command to instruct LVM2 to
remove the PV and update LVM2 metadata to reflect the removal of the PV.
For PVs which are a member of a VG this includes forcing the removal.
This has the impact of making recovery from accidental deletion of a
partition containing a PV irrecoverable. GParted is not able to recover
this situation anyway because Device -> Attempt Data Rescue, using the
gpart command, is not able to detect the signature of an LVM2 PV.
Choose to remove the PV, forcibly if required, rather than potentially
leave LVM2 with missing PVs.
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
Copy operation for LVM2 Physical Volumes is deliberately not implemented
because it doesn't fit with how LVM2 works and is not safe in the
general case without an understanding of its internals. See comment in
lvm2_pv::copy() for more details.
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
Add creation of Physical Volumes specifying LVM2 metatdata format:
lvm pvcreate -M 2 /dev/DEVICE
Also set the partition type to identify its contents as LVM. Note that
libparted treats every partition type as a file system except LVM which
it treats as a flag, hence GParted displaying "lvm" in the Manage Flags
dialog. Never the less libparted set the partition types correctly.
For MBR partitioning the type is 8e "Linux LVM" and for GPT partitioning
the type is E6D6D379-F507-44C2-A23C-238F2A3DF928. Setting the partition
type as LVM is not strictly required as LVM2 scans the contents of all
partitions looking for PVs, but it is best practice.
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 mount of lost file systems that were larger than a 32 bit integer
could hold (~2 GiB), or started after the first ~2 GiB of disk, would
fail.
Closes Bug #680740 - Gparted fails when mounting the read-only view of
lost filesystems
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.
When resizing an extended partition, a problem can occur with MiB
alignment wherein the requested end sector could be less than the end
sector of the last logical partition. This would be an invalid
geometry because all the logical partitions must be wholly contained
within the extended partition.
Check for this situation and if found then set requested end for
the extended partition to the end of the last logical partition.
Closes Bug #678831 - Partition End Overlap when Resizing Extended
Partition
Restore intended logic accidentally changed by my recent commit:
Simplify calc_usage_triple() interface and rename
6c96ab34b3
Set each display integer to zero if the associated usage value is
negative, rather than setting 100% unused for unknown usage. Graphical
display of partition usage for unknown and unsupported file system types
is not affected and continues to be all white because of the logic in
the callers.
Local variables used, unused and unallocated were hiding class member
variables of the same name. Remove first two local variables as they
were only accessed once and rename third.
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
Many file systems report differing percentages of unallocated space over
a range of sizes, as well differing figures using their own specific
tools or using statvfs() system call when mounted.
File systems reporting intrinsic unallocated space using their specific
tools are: jfs, lvm2 pv and ntfs. LVM2 PV has the largest amount of
unallocated space with its default Physical Extent size of 4 MiB. For a
100 MiB partition it has 4.0% unallocated space.
File systems reporting intrinsic unallocated space using the statvfs()
system call when mounted are: ext2/3/4, fat16/32, hfs, jfs, nilfs2,
ntfs, reiserfs, and xfs. Xfs has the worst identified unallocated space
of ~4.7% in a 100 MiB partition. Ext2/3 exhibit unusual behaviour by
reporting unallocated space of ~4.6% in a 100 MiB partition falling to a
constant percentage of ~1.8% for sizes of 1 GiB and above.
Update the calculation for used to estimate the maximum size of
intrinsic unallocated space. Limit is now 5% for partitions smaller
than 100 MiB, 2% for partitions larger than 1 GiB and linear scaling of
the percentage between. Will still get false unallocated space warnings
for mounted xfs file systems and lvm2 pvs smaller than 100 MiB.
Also add a short note and worked example calculation of unallocated
space to the HACKING file.
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
When pasting a copied partition into an existing partition set its space
utilisation so that any unallocated space is displayed correctly before
the operation is applied. If the destination partition is larger the
file system will be grown to fill the partition.
NOTE:
GParted will attempt to grow the the file system in this situation
regardless of whether the file system supports it or not. These file
systems: exfat, hfs, hfs+, reiser4 and ufs can't be grown and will fail
with "growing is not available for this file system". The preview will
also be wrong in this case for the same reason. Everything will be
depicted correctly after the refresh.
When formatting an existing partition default its space utilisation to
unknown for display before the operation is applied.
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
Update the implementation using libparted to set the file system size
and free space, thus allowing the unallocated space in the partition to
be calculated, for the following unmounted file systems:
hfs, hfs+
(Requires libparted <= 2.4 or libparted >= 3.1, as the needed
functionality did not exist in libparted 3.0).
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
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)
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
Determine the FS type before checking whether a FS is busy,
and check LVM only for LVM PVs.
Remove the LVM busy check for extended partitions, as they
don't contain LVM PVs - or any other FS for that matter.
(and even if they did, the rest of the code silently assumes
they don't...)
Previously used "dmsetup info" to directly list device-mapper mapping
names in the kernel to identify active Logical Volumes. However GParted
failed to recognise active LVs if the VGNAME contains any hyphens (-).
This is because LVM encodes hyphens as double hyphens in the mapping
name.
To avoid having to duplicate the LVM hyphen encoding in GParted, switch
to using "lvm lvs" to list LVs.
# dmsetup info --columns --noheadings --separator , -o name
GParted_VG1-lvol_00
GParted--VG2-lvol--00
# lvm lvs --noheadings --separator , -o lv_name,vg_name,lv_attr
lvol_00,GParted_VG1,-wi-a-
lvol-00,GParted-VG2,-wi-a-
lvol-01,GParted-VG3,-wi---
.^.
(-) not active, (a) or any other character considered active. Reference
lvs(8).
Bug #160787 - lvm support
A Volume Group is active when any of its Logical Volume mappings are
loaded (and enabled) in the Kernel's device-mapper driver. Therefore
all the Physical Volumes in the VG (must be considered) active too.
This is exactly equivalent to a mounted file system, as the kernel is
actively using the partition. Mark active LVM2 PVs as busy in GParted.
Don't use statvfs() for determining sector usage of busy LVM2 PVs as it
will fail with "statvfs(VGNAME): No such file or directory". Instead
always use the LVM2 PV specific method.
Display the status of the LVM2 PV in the Information dialog using one of
the following relevant messages:
Not active (Not part of any volume group)
VGNAME not active
VGNAME active
(The code uses the VGNAME stored in the partition's first mount point,
as displayed in the "Mount Point" column, rather than going back to the
primary source of the information in the LVM2_PV_Info class).
Temporarily prevent GParted from offering to unmount LVM2 PVs until
activating and deactivating Volume Groups is implemented later.
Bug #160787 - lvm support
As the Mount Point column is being borrowed to display the PV's VGNAME,
also suppress generation of the "Mount on" submenu for LVM2 PVs.
Bug #160787 - lvm support
Previously when GParted was started LVM2_PV_Info cache was loaded twice,
executing LVM2 PV querying commands twice. Firstly when
lvm2_pv::get_filesystem_support() was checking if LVM2 PV support was
available, and secondly when forced by a refresh in
GParted_Core::set_devices().
Implement lazy initialization. Only load the cache when forced by the
above mentioned refresh or having to return a value when the cache is
not yet loaded. Do not initialize the cache when just checking if LVM2
PV support is available.
Bug #160787 - lvm support
Cache results from querying all LVM2 PVs in one go to minimise the
number of times lvm commands are executed. Take inspiration from
caching performed by FS_Info and Proc_Partitions_Info.
Bug #160787 - lvm support
Newly created LVM2 PVs, before being added to a Volume Group, report
free space equal to the partition size. Allow free space to equal
partition size.
# parted /dev/sda10 unit B print
Error: /dev/sda10: unrecognised disk label
Model: Unknown (unknown)
Disk /dev/sda10: 2147483648B
Sector size (logical/physical): 512B/512B
Partition Table: unknown
# lvm pvcreate /dev/sda10
Writing physical volume data to disk "/dev/sda10"
Physical volume "/dev/sda10" successfully created
# lvm pvs --units b -o pv_free /dev/sda10
PFree
2147483648B
Add minimal support for just reporting the space usage of LVM2 PVs.
Accept libparted / blkid detection of LVM2 PVs first, falling back on
GParted's specific detection code otherwise. Maintain LVM not supported
warning message.
Bug #160787 - lvm support
This is the first step of adding support for just LVM2 Phyiscal Volumes,
a subset of full LVM2 support.
Make it clear that it is only LVM2 PVs being treated like a file system.
Bug #160787 - lvm support
Moving the start sector of an extended partition should not adversely
affect booting an operating system because an extended partition is
only a container for logical partitions.
Add the ability to set a new random UUID on file systems that provide
the appropriate tools to perform this action.
Update the help manual to include this new functionality. Also add
reference links to "setting a partition label" and "changing a
partition UUID" in the "copying and pasting a partition" section.
This patch does not include setting the UUID on an NTFS file system.
Bug #667278 - Add support for setting UUID
Bug #608308 - fix documentation - Copying and Pasting a Partition
Inserted cast to int so that third parameter matches expected
parameter precision type.
Original warning:
FileSystem.cc: In member function ‘Glib::ustring
GParted::FileSystem::mk_temp_dir(const Glib::ustring&,
GParted::OperationDetail&)’:
FileSystem.cc:81:69: warning: field precision should have type ‘int’,
but argument 3 has type ‘long unsigned int’
Increase sleep time to decrease pulse bar update frequency.
Debian Bug 499193 - gparted: 100% cpu usage
Debian Bug 519764 - gparted: Lots of animation makes use over SSH
X-tunnel slow
There is a lot of commonality and code repetition for resizing of file
systems which can only be resized while mounted. Resizing of btrfs, jfs
and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir.
Copying an xfs file system also uses a similar pattern, but for the
source and destination xfs file systems simultaneously.
Add three helper functions to the FileSystem class which implement
common tasks, allowing mounted file system resizing to be implemented
more simply.
Also add a function to the Utils class which checks whether the kernel
supports a file system. It handles the case of non-loaded modules,
which currently leads to reporting the growing of jfs and xfs as
unsupported.
We used to just log libparted exceptions without handling them. This patch
changes the exception handler to display a modal dialog box and return the
chosen action to libparted.
The call to "blkid -c /dev/null" on Precise Pangolin Alpha 1 takes
exceedingly long. This occurs when the BIOS is incorrectly set to
indicate a floppy drive is present when none is physically installed.
Use cached blkid results instead.
Ubuntu launchpad 910379 - Gparted does not start and continues to
scan devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/910379
Setting the status and controlling the timing of operation details
initialised with OperationDetail(desc, status, font) uses a conditional
branch depending on the uninitialised variable this->status.
valgrind:
==28957== Conditional jump or move depends on uninitialised value(s)
==28957== at 0x80E4287:
GParted::OperationDetail::set_status(GParted::OperationDetailStatus)
(OperationDetail.cc:77)
OperationalDetail.cc:
75 void OperationDetail::set_status( OperationDetailStatus status )
76 {
>> 77 if ( this ->status != STATUS_ERROR )
78 {
79 switch ( status )
80 {
Requires libparted 2.4 or higher, or blkid from utils-linux 2.20 or
higher for nilfs2 file system detection.
Requires nilfs-utils for nilfs2 file system support.
Closes Bug #642842 - nilfs is not detected
When GParted performed operations or combinations of operations,
such as:
a) copy to same or smaller size destination partition
b) move to same or smaller size due to alignment change
c) resize to smaller size
a redundant maximize file system operation would occur.
Normally these redundant maximize operations to grow the file
system to take up all the space in the partition were not harmful.
However in situations where libparted failed to inform the kernel
of partition changes, then the extra maximize operation would
grow the file system to be the original partition size. In cases
where the original partition was larger than the new partition
size, this caused problems because the file system would be
larger than the partition on reboot.
This enhancement avoids redundant file system maximize actions on
copy, move, and resize, and should help reduce problems described
in the following links:
WARNING! Problem Resizing File Systems with GParted
http://gparted-forum.surf4.info/viewtopic.php?id=13777
Bug #601574 - ERROR: Current NTFS volume size is bigger than the
device size!
Bug #604298 - Problems resizing file systems with
gparted-live-0.5.0-3
Closes Bug #663980 - Avoid redundant file system maximize actions
on copy, move, and resize
Btrfsctl and btrfs-show were depreciated in October 2011 and have been
superseeded by the newer btrfs multi-tool control command. Use btrfs as
first choice, falling back to btrfsctl and btrfs-show when not found.
There are still 2 issues with reading btrfs labels when falling back
on using btrfs-show command, rather than primary method of using the
blkid command:
1) Label is set no "none" when btrfs-show is reporting there is no
label, although it is impossible to distinguish from the case of the
label actually being set to "none".
2) The label has 2 trailing spaces appended as the regular expression
matches "Label: (btrfslabel )uuid:" rather than
"Label: (btrfslabel) uuid:" in the btrfs-show output.
Assume a label "none" means there is no label and fix the regular
expression.
Note that this enhancement changes GParted to first try the native
tools to determine the volume label for all file systems. If the
volume label is not found then the fall back method is to use blkid.
There is a small degradation in device refresh times as a result of
this change.
Closes Bug #662537 - Ext4 unicode labels not shown correctly
Fix bug introduced in GParted 0.9.0 in commit
4a8fef9822 to address ISO C++ ambiguity
compiler warning.
Due to the nature of the surrounding code, this bug was not evident
in the log file output.
Thanks to Magnus Fromreide for finding this bug.
When a new operation is added to operations list, check if a merge
is possible depending on the operation type:
OPERATION_RESIZE_MOVE: 2 consecutive "resize" operations on the
same partition
OPERATION_LABEL_PARTITION: 2 "label change" operations (need not be
consecutive) on the same partition
OPERATION_CHECK: 2 "check" operations (need not be
consecutive) on the same partition
OPERATION_FORMAT: 2 consecutive "format" operations on the
same partition
Closes Bug #438573 - Cancel out overlapping actions
Also fix a bug when copying partition using the Partition::Set(...)
method. This method did not initialize "sectors_used" and
"sectors_unused" members.
Due to a change in error handling behaviour in ntfsresize version
2.011.4.12AR.4 (libntfs-3g) GParted would fail to properly resize ntfs
file systems if the file system was marked for consistency check.
The current maintainer of ntfsprogs provided the following advice:
"Well, though I am reverting back to the old behavior, you should
add -ff instead of relying on an unspecified behavior when
ntfsresize gets an error when trying to read the reply. I suppose
you do not connect the stdin of ntfsresize, hence the error. With
-ff no question is asked (I stress : even with the old
ntfsresize)."
Hence I have added a second "--force" option to the ntfsresize command
for resizing NTFS file systems.
Closes Bug #655215 - NTFS partition resize fails
Enhance code to pass compiler warning. Prior to this change the
compiler would complain with the following message:
error: ISO C++ says that these are ambiguous, even though the worst
conversion for the first is better than the worst conversion for the
second: /usr/include/c++/4.5/bits/postypes.h:192:7: note: candidate 1:
std::fpos<_StateT> std::fpos<_StateT>::operator-(std::streamoff) const
[with _StateT = __mbstate_t, std::fpos<_StateT> =
std::fpos<__mbstate_t>, std::streamoff = long int] Utils.cc:443:27:
note: candidate 2: operator-(std::streamoff, long long int) <built-in>
Add code to handle situation where realpath might return a NULL value.
Prior to this change the compiler would complain with the following
message:
error: ignoring return value of ‘char* realpath(const char*, char*)’,
declared with attribute warn_unused_result
Removed expression that is always true. Prior to this change the
compiler would complain with the following message:
error: comparison of unsigned expression >= 0 is always true
Add code to handle situation where mkdtemp(char*) function returns
with a NULL value. Prior to this code the compiler would complain
with the following message:
error: ignoring return value of ‘char* mkdtemp(char*)’, declared with
attribute warn_unused_result
Some classes contained private attributes which were used only by a single
member function. Such items were moved to the corresponding function implementations
to stress their limited usage scope.
A few unused variables were also deleted.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
The release of (lib)parted 3.0 includes a change to the Application
Programing Interface - API. Most importantly, libparted 3.0 removes
many file system specific function calls, and hence the capabilities
provided by these functions. In order for GParted to compile and link
with libparted 3.0, this libparted functionality is lost.
Specifically, the functionality that is lost when GParted is compiled
and linked with libparted 3.0 is as follows:
- Loss of ability to grow and shrink FAT16 and FAT32 file systems
- Loss of ability to shrink HFS and HFS+ file systems
- Loss of ability to determine used and unused sectors in HFS and
HFS+ file systems
- Loss of ability to erase file system signatures on partition
create and format
It is hoped that other free software projects will include some or all
of the above lost functionality, which can then be added back to
GParted.
This commit includes a change in how FAT16 and FAT32 file systems are
moved. Specifically the move is now performed internally by GParted
when linked with libparted 3.0. The move functionality is provided by
libparted for prior libparted versions (e.g. less than 3.0).
This is the final enhancement in a series of commits that enable
GParted to compile with libparted version 3.0.
Closes Bug #651559 - Doesn't compile against parted 3.0
On disks with an unrecognized disk label, the end sector value
was saved as one sector larger than actual. This caused the
Partition Information dialog to report the end sector value and
the total number of sectors on the disk as one larger than the
actual value.
Closes Bug #649444 - Partition information reports wrong sector
count
I hit this performance bug when I cloneda 40G NTFS partition. The actual
copy was done in under 11 minutes. After that I was shocked to find that
gparted would spend over 12 minutes in cleanup_cursor, pegging a CPU
core. (On a quad core desktop...)
Simply replacing the ustring with std::string would reduce the time to
about 1.5 minutes. Still bad. Also, I didn't want to lose UTF8
awareness.
So I rewrote the algorithm in 'streaming mode'. This has the (potential)
drawback that locale conversions are done, but performs well and
- IMHO - is a lot more readable.
On a minor note: this implementation correctly handles backspaces at the
start of a line.
Change spawn_command_line_sync to spawn_sync to reduce the level of
quoting required when passing commands to the function. Since
spawn_command_line_sync uses the parent's environment, the replacement
call also uses the parent's environment.
This change permits unmounting of file systems mounted with an
apostrophe in the mount point name.
Ubuntu launchpad bug 151796 - Can't unmount partition with apostrophe
in label
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/151796
Usage of the kpartx package to create partition names has been
completely removed. Hence kpartx is no longer even an optionally used
package by gparted.
This change is related to the following bug report:
Ubuntu launchpad bug 719129 - [Natty] Gparted duplicates dmraid
partition devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/719129
The new configure option --enable-libparted-dmraid enables the native
use of /dev/mapper dmraid support in the libparted library.
If this option is not specified, or is disabled, then gparted code
will be used to support dmraid. The gparted code uses the old dmraid
partition naming scheme of always appending the partition number to
the device name. The letter 'p' is not inserted between the device
name and the partition number. The gparted code is particularly
useful when used with older versions of libparted that do not support
/dev/mapper dmraid.
Ubuntu launchpad bug 719129 - [Natty] Gparted duplicates dmraid
partition devices
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/719129
Added a display refresh to the event queue to address this
problem.
Previously, the display area of the visual disk seemed to
disappear when enough operations had been added to the queue so
that a scrollbar was required (about 4 operations).
If the three lines in HBoxOperations::load_operations method for
"//make scrollwindow focus on the last operation in the list"
were commented out then this also prevented the problem from
occurring.
Interestingly, if I changed the "set_cursor" method to
a "scroll_to_row" method, then this problem does not occur for an
additional 2 operations (about 6 operations total).
Ubuntu launchpad bug 583746 - Partition graph disappears after a
swap partition has been deleted
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/583746
Previously when creating a new partition on a device with 512
byte sectors with 7 MiB chosen and cylinder alignment, the
snap_to_cylinder logic would round up to 2 cylinders (~15.69
MiB), instead of the correct 1 cylinder (~7.84 MiB).
Re-work logic for copying a cylinder aligned partition to a new
MiB aligned partition. Previously this was partially fixed in
bug #626946 - Destination partition smaller than source partition
Closes Bug #639393 - Redux: Destination partition smaller than
source partition
Use mntent C library to read mount point files such as
/etc/fstab, /etc/mtab, and /proc/mounts.
Closes bug #629592 - Unable to find Mount Point if it contains a
Space Character
The reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
This reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
Enhance code so that all calls to the ped_partition_get_path
function in the libparted library go through one
GParted_Core::get_partition_path method.
This one method makes the appropriate adjustments to the dmraid
partition path name as required.
Closes bug #634553 - ntfsresize fails on RAID array
This problem would occur when using align to MiB for the
destination partitions.
Closes bug #628863 - gparted crashes applying move to right of
more than one logical partition
This new URL is actually an html redirect to the actual page
location. This permits us the flexibility to move the actual
page wherever is needed on the web site without the need to
change the URL location in the code.
Correct problem introduced in version 0.6.3 whereby move or copy
operations using MiB alignment resulted in the destination
partition being 1 MiB larger.
Closes bug #632478
GParted already has basic support only to recognize Btrfs volumes; if
configured, use our newer methods to handle them.
Also, put in place interface controls for all supported generic actions.
This adds initial handlers for Btrfs; only .create, .check and
.read_label are done for now, via external btrfs-tools.
Other methods are still only stubs.
Change string initialization to use direct assignment instead of
a class method in the GParted_Core class initialization.
Thanks go to Jan Claeys for pointing out this potential problem
and providing the following link:
https://bugzilla.gnome.org/show_bug.cgi?id=627724#c7
This link contains a comment by Matthias Clasen that says:
"In a class init function, don't do anything that causes
other threads to initialize classed types."
Prior to this enhancement creating a new partition aligned to MiB
after a partition aligned to cylinder would result in the creation of
a partition that was 1 MiB smaller in size than requested. In the
case of a 1 MiB new partition, a warning message would be displayed
indicating that "A partition cannot have a length of 0 sectors".
This problem is avoided by applying similar logic as was used to
address the following bug:
Bug #626946 - Destination partition smaller than source partition
Prior to this enhancement when copying and pasting a partition
after a cylinder aligned partition, the destination partition
would become smaller than the source partition if align to MiB
was selected.
Closes bug #626946 - Destination partition smaller than source
partition.
Mike Fleetwood