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
Applications are moving away from storing icons in /usr/share/pixmaps,
instead preferring /usr/share/icons/hicolor/$SIZE/apps, so only install
the fallback icon when GParted requires it.
Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
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.
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
Phillip Susi