Enable the text progress bar and percentage complete from the e2fsck
command. Looks like:
# e2fsck -f -y -v -C 0 /dev/sda8
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
test8: |========================================= / 73.6%
Note that e2fsck deliberately brackets the progress bar with control-A
and control-B characters when it detects that it is not being run from a
terminal so that logsave(8) can exclude the progress bar from being
written to a log file. As GParted doesn't run e2fsck via a pty it
receives these control characters. Ignore them.
References:
Change e2fsck to bracket its progress bar output with ctrl-A and ctrl-B
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=bc34d6be65cb93a65451ad209cfea2f98b03fd22
Don't print ^A and ^B chars when e2fsck is talking directly to a tty
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=54a31a3b2e432c124aa03442f2983c4f4d4a974c
Closes Bug #697662 - Do not hide the progress of the tools used
Remove the -P, no progress bar option, from the ntfsresize command.
This allows the command to display the %age complete on its output which
is displayed in the operation details dialog, updated in real time.
Possible since:
Bug #685740 - Refactor to use asynchronous command execution
Bug #697662 - Do not hide the progress of the tools used
Currently the btrfs command outputs figures to 2 decimal places followed
by an SI multiplier, e.g. 1.00GB.
This patch to btrfs-progs has been included in the integration
repository and will likely be included in the official btrfs-progs
repository at some point. It changes btrfs-progs to use IEC
multipliers, e.g. 1.00GiB. In fact multipliers already aren't used for
figures less than 1024.
[PATCH] btrfs-progs: use IEC units for size
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26888https://patchwork.kernel.org/patch/2825841/
Make GParted capable of also accepting IEC prefix multipliers, just "B"
for bytes and no multiplier, as well as an optional space between the
number and multiplier. Therefore accept values like these:
1.00GB 1.00 GB
1.00GiB 1.00 GiB
1073741824B 1073741824 B
1073741824
Closes Bug #706914 - Prepare for btrfs tools using IEC prefix
multipliers
With recent btrfs-progs, GParted failed to format a btrfs file system
over the top of an existing one. Make btrfs failed with this error:
# mkfs.btrfs /dev/sdb1
...
/dev/sdb1 appears to contain an existing filesystem (btrfs).
Use the -f option to force overwrite.
With this commit to btrfs-progs on 2013-02-19, mkfs.btrfs checks for
existing file system signatures, including all mirror copies of btrfs
super blocks, before writing to the partition.
http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/commit/?id=2a2d8e1962e8b6cda7b0a7584f6d2fb95d442cb6
btrfs-progs: require mkfs -f force option to overwrite filesystem or partition table
Make GParted clear all the mirror copies of the btrfs file system super
blocks as erase_filesystem_signatures() is intended to prevent detection
of old signatures. This also avoids having to determine if the -f
option to mkfs.btrfs is available before trying to use it.
Closes Bug #705426 - Formatting Existing BTRFS Partition as BTRFS Fails
Because mkfs.btrfs Is Not Run with "-f"
Unfortunately a regression was introduced with GParted 0.14.1 wherein
linux-swap grow and shrink operations were broken. This regression was
a direct result of the following commit:
Prevent file system grow when partition grow fails (#686668)
fd96328920
The regression did not result in an error in the GUI, but rather the
linux-swap file system was not "resized" to the correct partition size.
The logic error introduced with the above commit listed has now been
fixed.
BACKGROUND INFORMATION ON LINUX-SWAP RESIZING
Currently no command line tools are available for resizing linux-swap.
However, since linux-swap does not contain data in the usual sense, we
simulate resizing linux-swap by re-creating (maximizing to fill
partition) the linux-swap file system with the same UUID and volume
label. To work correctly, the linux-swap file system must be re-created
after the final partition resize action has occurred.
Closes Bug #706604 - Failure to properly grow or shrink linux-swap when
resizing
Under GNOME Shell a running instance of GParted was getting named
"Gpartedbin". Ultimately GNOME Shell [1] uses the WM_CLASS X Window
property [2], which GDK defaults from the executable name.
$ xprop WM_NAME WM_CLASS
(Click on running GParted window)
WM_NAME(STRING) = "/dev/sda - GParted"
WM_CLASS(STRING) = "gpartedbin", "Gpartedbin"
Set the Class name, second string of the WM_CLASS X Window property, to
"GParted". (This prevents the use of the '--class' GTK+/GDK common
command line option [3] to override the class name, but I expect nobody
ever uses the option. GNOME Terminal has the same limitation. It also
has the same change setting the Class name [4]).
References:
[1] Application Based GNOME 3
https://wiki.gnome.org/GnomeShell/ApplicationBased
[2] WM_CLASS Property, Inter-Client Communication Conventions Manual
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
[3] Running GTK+ Applications, Common command line options
https://developer.gnome.org/gtk3/stable/gtk-running.html
[4] Bug #685742 - Window class of terminals doesn't match the desktop
file name
https://bugzilla.gnome.org/show_bug.cgi?id=685742https://git.gnome.org/browse/gnome-terminal/commit/?id=3370c0e51159f5be476b909e94ac05e5362dd28a
Closes Bug #705323 - Shows up as 'Gpartedbin' in GNOME Shell
Dosfstools >= 3.0.18, released June 2013, renamed the programs thus:
dosfslabel becomes fatlabel,
dosfsck becomes fsck.fat,
and mkdosfs becomes mkfs.fat.
Dosfstools creates symbolic links for the old names for backward
compatibility, but unfortunately the Debian dosfstools-3.0.22-1
(experimental) package doesn't include those symbolic links. This
causes create, check and read unmounted FAT16/32 file systems to not be
supported.
Make GParted look for the new names first and the old names second.
Closes Bug #704629 - Program name changes in dosfstools 3.0.18+ break
FAT16/32 support
It was difficult to retrieve whether a filesystem's label can be set on reformat.
The read_label flag can't be used as it decides whether to use the logic in the filesystem class
rather than the fallback in GParted::set_device_partitions, to determine the label of a partition.
The create_with_label flag is NONE for file systems that we cannot format with a
label (or that we cannot format at all).
The value is usually EXTERNAL for file systems that we can format with a label.
The read-only functionality is unused and the readonly parameter is
always false in copy_filesystem() and copy_blocks() methods. This has
been the case since the copy simulation was dropped by commit:
b9b4b2e55d
Remove simulation pass ( read test ) on move
The minimum NTFS volume size supported by the ntfs-3g mkntfs command
is 1 MiB. Since 1 extra sector is required for the backup NTFS boot
sector, an NTFS partition must be at least 1 MiB plus 1 sector.
To demonstrate, create a 1 MiB unformatted partition using MiB
alignment (/dev/sdd1), and then try to format the partition as NTFS.
# mkntfs -Q -v -L "ntfs-test" /dev/sdd1
Device is too small (1023kiB). Minimum NTFS volume size is 1MiB.
For GParted this means a minimum NTFS partition size of 2 MiB since
the smallest unit in the GUI is MiB.
Bug #697848 - Failure to Create 1 MiB NTFS Partition
Place the size and noaction options before the device name when resizing
an NTFS file system to match the order documented in the manual page.
Example fixed command:
# ntfsresize -P --force --force -s 104857600 --no-action /dev/sda11
Ext[234] file systems were being shrunk 1 KiB too small. Ntfs and
reiserfs file systems were being shrunk 1 byte too small. The resultant
file systems were ending up 1 block smaller than they could have been.
This looks like an accidental leftover from when GParted use to:
1) Shrink the file system 1 cylinder too small
2) Shrink the partition
3) Grow the file system to fill the partition
Relevant commit:
d663c3c277
removed cylindersize buffering during resize from the filesystems
Closes Bug #701075 - Setting the backup boot sector when resizing NTFS
It was possible to make GParted crash by adding a label, check or new
UUID operation and then applying the operation before the view of
pending operations had finished fully opening. The operation would be
successfully applied but GParted would crash afterwards.
The fault was that Add_Operation() still enabled the Undo and Apply
buttons and processed the GTK event loop before merging the list of
pending operations. Faulty code flow went like this:
activate_*()
Add_Operation()
Add operation to the operations[] vector
Enable Undo and Apply buttons
Refresh_Visual()
Process GTK event loop
Process Apply button callback applying operations,
refreshing display and clearing operations[] vector
Merge operations in the operations[] vector
<< Core dump here >>
Merge_Operations()
Refresh_Visual()
This faulty code flow came about when merging of operations was added
and it didn't appreciate that the operations[] vector could have been
processed and cleared by Add_Operations() before the merge step.
Relevant commit:
b10349ae37
Merge overlapping operations (#438573)
Fragment of code in the label operation case:
2454 void Win_GParted::activate_label_partition()
2455 {
...
2472 Add_Operation( operation ) ;
2473
2474 // Verify if the two operations can be merged
2475 for ( unsigned int t = 0 ; t < operations .size() - 1 ; t++ )
2476 {
2477 if ( operations[ t ] ->type == OPERATION_LABEL_PARTITION )
2478 {
2479 if ( Merge_Operations( t, operations .size() - 1 ) )
2480 break;
2481 }
2482 }
Commentary in the crashing label operation case:
2472 The pending operation was already applied when Add_Operation()
returned resulting in the operations[] vector being cleared
setting its size to 0.
2475 The return type of operations.size() is an unsigned integral, so
the upper limit of the for loop is t < 0UL - 1. Assuming a
32-bit machine that's t < 4294967295.
2477 operations[] vector is access from out of bounds offset 0
upwards until unallocated memory is accessed resulting in a core
dump.
Fix this by not enabling the Undo and Apply buttons and processing the
GTK event loop until after merging of operations has been performed.
Fixed code flow goes like this:
activate_*()
Add_Operation()
Add operation to the operations[] vector
Merge operations in the operations[] vector
Merge_Operations()
show_operationslist()
Enable Undo and Apply buttons
Refresh_Visual()
Process GTK event loop
Process Apply button callback applying operations,
refreshing display and clearing operations[] vector
Not allowing the operations list to be process until after the merge
step is the be correct ordering. This also prevents the new operation
from flashing up in the operations list and then immediately
disappearing if merged. In the case of adding the first operation,
delaying enabling the Undo and Apply buttons is enough as the buttons
were previously disabled preventing the operation being applied before
the merge. In the case of adding further operations, processing of the
GTK event loop must also be delayed until after the merge to prevent the
operations being applied before the merge. Although that window of
opportunity would only be microseconds.
Bug #699452 - Crash when applying operations before pending operations
fully displayed
Mlabel sometimes writes uninitialised memory at the end of the label.
This causes mlabel, and therefore GParted, to display extra junk at the
end of the label. Depending on the bytes written GParted may also show
the following error on stdout:
(gpartedbin:18116): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g_convert_error
code : 1
what : Invalid byte sequence in conversion input
This is caused by a bug in mlabel, believed fixed in mtools 4.0.14.
Effects at least Fedora 14, RHEL/CentOS 6.x and Debian 6. (Use label
"1234567890" on Debian 6 to reproduce). Reproduction steps:
# mkdosfs -F16 /dev/sda7
mkdosfs 3.0.9 (31 Jan 2010)
# export MTOOLS_SKIP_CHECK=1
# mlabel ::123456 -i /dev/sda7
# mlabel -s :: -i /dev/sda7
Volume label is 123456~1t
It is not possible to detect which characters are junk so they can't be
trimmed. Instead just space pad labels so that at least newly written
labels aren't effected. (Fat labels are space padded on the disk by
definition anyway).
Bug #700228 - FAT16/32 labels are sometimes shown corrupted
There was virtually no difference between the separate modules for fat16
and fat32. Remove module fat32 and patch fat16 to serve both file
system subtypes. This is equivalent to what was previously done for
ext[234] by commit:
38dc55d49c
Combine duplicate code for ext[234]
Rename function to update_command_output() to better reflect that this
callback updates the UI with the latest output read from the command
being executed.
This makes more sense knowing a future change will add a separate
callback which parses the output read from the command and updates the
progress bar. This function should be named update_command_progress().
Rename the libsigc++ signals to signal_update and signal_eof to match
the naming used for signals in GParted.
fgrep 'sigc::signal' include/*.h
Also explicitly use the emit() method rather than using the object
operator(). This again is to match the convention in GParted and make
it more obvious what is happening.
fgrep '.emit(' include/*.h
The previous commit missed one glibmm GSource wrapper in the form of the
io watch for the PipeCapture class. Convert this one to use glib
directly as well.
Bug #697727 - Segfault in livecd Gparted v 0.15.0-3 when copying
partition
On RHEL / CentOS 5.9 GParted couldn't set an icon as the
set_default_icon_name() method is not available. See commit [1] for
details.
Re-add the old set_icon_from_file() method as a fallback and re-install
a GParted pixmap as was used before commit [2].
Commit [1]:
a042107883
Only use Gtk::Window::set_default_icon_name method when available
Commit [2]:
f5a80bc904
Enabled GParted to use themed app icon (Tango theme)
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
On RHEL / CentOS 5.9 GParted failed to run any external commands and
instead reported the following warnings to the terminal:
# src/gpartedbin
======================
libparted : 1.8.1
======================
Failed to change to directory '' (No such file or directory)
Failed to change to directory '' (No such file or directory)
Failed to change to directory '' (No such file or directory)
...
Utils::execute_command() and FileSystem::execute_command() passed a zero
length string for the working directory to
Glib::spawn_async_with_pipes() to mean don't change directory. Instead
glibmm just tried to change to the directory with a zero length name.
This was fixed with glibmm >= 2.21.2 released July 2009, however RHEL /
CentOS 5.9 only has glibmm 2.12.10.
Relevant glibmm fix:
Treat empty Glib::spawn*() working dir as unset
https://git.gnome.org/browse/glibmm/commit/?id=8a7805cbbe6d268e975669349beb4e82d971537d
Fix by simply specifying ".", the current working directory, as the
directory to change into before executing all commands.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
Glib::ustring::compose() method requires glibmm >= 2.16, but RHEL /
CentOS 5.9 only provides glibmm 2.12. Replace with String::ucompose()
as is used everywhere else in the code.
Add missing include for kill() and SIGINT declarations.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
Roughly HFSX is a case sensitive version of the HFS+ file system.
Parted reports such a file system as "hfsx" rather than "hfs+".
# mkfs.hfsplus -v "case insensitive hfs+" /dev/sda7
Initialized /dev/sda7 as a 1024 MB HFS Plus volume
# mkfs.hfsplus -s -v "case sensitive hfs+" /dev/sda8
Initialized /dev/sda8 as a 1024 MB HFS Plus volume
# parted /dev/sda print
...
Number Start End Size Type File system Flags
...
7 356GB 357GB 1074MB logical hfs+
8 357GB 358GB 1074MB logical hfsx
# blkid /dev/sda[78]
/dev/sda7: LABEL="case insensitive hfs+" TYPE="hfsplus"
/dev/sda8: LABEL="case sensitive hfs+" TYPE="hfsplus"
Make GParted recognise HFSX file system variants too.
Closes Bug #698876 - GParted fails to recognize HFS+ partition (possible
due to disabled journaling)
In some circumstances gparted would appear to scan forever if it
encountered a blank hard disk. This would happen if the timing of
events was right and gparted encountered a disk without a partition
table. The missing partition table would cause a call to the
exception handler, which could get stuck in a thread waiting position.
The problem was traced back to the ped_exception_handler
and a cond.signal() call missing the requisite mutex.lock() and
mutex.unlock() around the signal call.
Closes Bug #697518 - gparted scans forever blank disk in virtualbox
The glibmm GSource wrappers have a bug where they do not do
reference counting properly, and have a race condition where
the background thread can try to touch the source after the
main thread has already processed and destroyed it. This
results in writes to freed memory and sometimes this causes
crashes or other erratic behavior. Avoid using the glibmm
wrappers and use glib directly. See bug #561885 for details
of the glibmm bug.
Bug #697727 - Segfault in livecd Gparted v 0.15.0-3 when copying partition
For an absolutely full NTFS GParted doesn't show the file system usage
but instead shows a warning against the partition.
GParted was looking only for "resize at %d" to determine file system
used figure in the output from the ntfsresize command. Also handle
finding "ERROR: Volume is full" too to derive used figure.
NTFS with 1 block free case:
# ntfsresize --info --force --no-progress-bar /dev/sda9
...
Current volume size: 1073738240 bytes (1074 MB)
...
Collecting resizing constraints ...
You might resize at 1073737728 bytes (freeing 4096 bytes).
...
# echo $?
0
Absolutely full NTFS case:
# ntfsresize --info --force --no-progress-bar /dev/sda9
...
Current volume size: 1073738240 bytes (1074 MB)
...
Collecting resizing constraints ...
ERROR: Volume is full. To shrink it, delete unused files.
# echo $?
1
Closes Bug #697946 - Absolutely full NTFS reported as partition error
Lookup the maximum reiser4 file system label length instead, so that it
is defined in only one place. Small improvement missed from earlier
commit:
18941e24d3
Avoid reading trailing junk for a reiser4 label (#689318)
These functions in GParted_Core:
open_device()
open_device_and_disk()
close_disk()
close_device_and_disk()
call the following functions in the libparted API:
ped_device_get()
ped_disk_new()
ped_disk_destroy()
ped_device_destroy()
which don't open or close anything. Instead they allocate and
deallocate PedDevice and PedDisk memory structures which describe block
devices and partition tables respectively.
Rename functions:
open_device_and_disk() -> get_device_and_disk()
close_device_and_disk() -> destroy_device_and_disk()
and merge open_device() and open_device() as each only wrapped one
libparted function and was only called from a single place.
The wipefs command has the following significant limitations which were
worked around in previous commits:
1) Wasn't available in the earliest distributions supported by GParted;
2) Had to be called 3 times to erase vfat (fat16/32) signatures in all
but the most recent versions.
This meant we had all the code to clear file system signatures without
using the wipefs command as well as extra complexity of using wipefs
too. So just remove use of the wipefs command.
Bug #688882 - Improve clearing of file system signatures
Wipefs only clears the nilfs2 file system signature from the primary
super block at the start of the partition. This is enough for blkid to
no longer detect the file system. However parted (>= 2.4 with nilfs2
support) and therefore GParted still detect the file system using the
secondary super block at the end of the partition.
# mkfs.nilfs2 /dev/sda12
# wipefs -a /dev/sda12
2 bytes were erased at offset 0x00000406 (nilfs2): 34 34
# blkid /dev/sda12
# parted /dev/sda12 print
Model: Unknown (unknown)
Disk /dev/sda12: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 1074MB 1074MB nilfs2
Overwrite the nilfs2 secondary super block at the end of the partition
with 4K block of zeros. Always do this just in case the partition
contains a nilfs secondary super block but is detected as a different
file system. Such an example was documented in an earlier commit
message.
Bug #688882 - Improve clearing of file system signatures
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.
Mike Fleetwood