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
Make the generated configure script additionally report these two checks
with their outcome:
checking for gtk_show_uri function... yes
checking for Gtk::MessageDialog::get_message_area() method... yes
1) Require autoconf >= 2.50
(Released May 2001).
2) Rename file to configure.ac
(Recommended with autoconf >= 2.50).
3) Update macro from AC_TRY_RUN to AC_RUN_IFELSE
(As wanted by the autoupdate program).
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.
Mike Fleetwood