A "Force Cancel" button and proper cancel support was added to
GParted 0.15.0 with the following commit:
Add proper cancel support (#601239)
89de9a5026
Part of Bug #707070 - Update Help Manual with GPT flags, Force Cancel
button, etc.
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
The menu option to mount a partition containing a file system should
be the active tense because choosing the menu option will perform the
action.
Changing:
"_Mounted on" --> "_Mount on"
If the gnome-doc-utils package isn't installed and you try to compile
GParted from git it will fail with this:
$ ./autogen.sh
/usr/bin/gnome-autogen.sh
Cannot find file: gnome-doc-utils.make
You need to install gnome-doc-utils
After installing the gnome-doc-utils package the same error will be
reported again unless you also update the locate database.
Instead query the full path to the gnome-doc-utils.make file from the
gnome-doc-utils' pkg-config metadata.
Closes Bug #702040 - very strange gnome-doc-utils check in gparted
Only one partition editing tool should be in use at any one point
in time. If more than one is in use concurrently, then data loss
might occur through operations on common partitions or partition
tables. As such, prevent multiple copies of GParted from running
at the same time.
With the beta release of Fedora 19, invoking gparted appears to
automatically mount partitions. The systemd daemon appears to be
performing the automounting. Hence use systemctl runtime mask to
prevent this automounting from occurring.
Bug #701676 - gparted doesn't inhibit systemd mounting, leading to
potential data loss
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
Include guards need to be unique within GParted code and all included
library header files.
http://en.wikipedia.org/wiki/Include_guard#Difficulties
Use this model for all include guards:
#ifndef GPARTED_FILE_NAME_H
#define GPARTED_FILE_NAME_H
...
#endif /* GPARTED_FILE_NAME_H */
Closes Bug #539297 - Make include guards unique
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
Note the license text of this file differs slightly from the C++
source code license text to indicate this file is a part of GParted.
See: https://www.gnu.org/licenses/gpl-howto.html
For programs that are more than one file, it is better to replace
“this program” with the name of the program, and begin the
statement with a line saying “This file is part of NAME”.
For developers to build GParted in a git repository, logging the top
commit and build results to testbuild.log. Intended for use with
git-test-sequence to verify every change of a patch set compiles, but
can be used standalone too.
Example usage:
git-test-sequence origin/master.. testbuild.sh
Further documentation can be found on the GParted web site at page:
Git Source Code Management
http://www.gparted.org/git.php
Closes Bug #699881 - testbuild.sh - Builds GParted logging results
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
As part of bug 700228, the fat16 and fat32 code was combined. As a
result, the fat32.cc file no longer exists and hence is not available
for translation.
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]
Curtis Gedak