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.
Minimum update explaining the meaning of the cleared and unformatted
file system types.
Also markup file system names as GUI menu items.
Bug #688882 - Improve clearing of file system signatures
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
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
Mike Fleetwood