The struct FS constructor initialised every member *except* filesystem
and busy. Then in *most* cases after declaring struct FS, assignments
followed like this:
FS fs;
fs.filesystem = FS_BTRFS;
fs.busy = FS::GPARTED;
But member busy wasn't always initialised.
Add initialisation of members filesystem and busy to the struct FS
constructor. Specify optional parameter to the constructor to set the
filesystem member, or when left off filesystem is initialised to
FS_UNKNOWN.
Lots of files which use the Partition class relied on the declaration
being included via other header files. This is bad practice.
Add #include "Partition.h" into every file which uses the Partition
class which doesn't already include it. Header file #include guards are
specifically to allow this.
Command exit status is a 1 byte value between 0 and 255. [1][2] However
at the Unix API level the value is encoded as documented in the
waitpid(2) manual page. This is true for the Glib API too. [3] This is
why, for example, the comment in ext2::check_repair() reported receiving
undocumented exit status 256. It was actually receiving exit status 1
encoded as per the waitpid(2) method.
Add shell style exit status decoding [2] to execution of all external
commands. Return value from Utils::execute_command() and
FileSystem::execute_command() functions are now:
0 - 125 - Exit status from the command
126 - Error executing the command
127 - Command not found
128+N - Command terminated by signal N
255 - Unexpected waitpid(2) condition
Also adjust checking of the returned statuses as necessary.
[1] Advanced Bash-Scripting Guide: Appendix D. Exit Codes With Special
Meanings
http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/exitcodes.html
[2] Quote from the bash(1) manual page:
EXIT STATUS
... Exit statuses fall between 0 and 255, though as
explained below, the shell may use values above 125
specially. ...
... When a command terminates on a fatal signal N, bash uses
the value of 128+N as the exit status.
If a command is not found, the child process created to
execute it returns a status of 127. If a command is found
but is not executable, the return status is 126.
[3] Quote from the Glib Reference Manual, Spawning Processes section,
for function g_spawn_check_exit_status():
https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-check-exit-status
The g_spawn_sync() and g_child_watch_add() family of APIs return
an exit status for subprocesses encoded in a platform-specific
way. On Unix, this is guaranteed to be in the same format
waitpid() returns, ...
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
There has been an undocumented rule that external commands displayed in
the operation details, as part of file system manipulations, only get a
time and check mark displayed when multiple commands are needed, and not
otherwise. (GParted checks whether all commands are successful or not
regardless of whether a check mark is displayed in the operation details
or not).
EXCEPTION 1: btrfs resize
Since the following commit [1] from 2013-02-22, GParted stopped
displaying the timing for the btrfs resize command in the operation
details. It being part of a multi-command sequence to perform the step.
This is because FileSystem::execute_command() since the commit can only
check the exit status for zero / non-zero while timing and checking the
command status but btrfs resize needs to consider some non-zero statuses
as successful.
[1] 52a2a9b00a
Reduce threading (#685740)
EXCEPTION 2: ext2/3/4 move and copy using e2image
When use of e2image was added [2] the single command steps were timed
and check.
[2] 86111fe12a
Use e2image to move/copy ext[234] file systems (#721516)
EXCEPTION 3: fat16/32 write label and UUID
Uses Utils::execute_command() rather than FileSystem::execute_command()
so can be separately changed. See the following commit for resolution
of the final commands not yet timed and check mark displayed.
CHANGE:
Lets make a simpler rule of always displaying the time and a check mark
for all external commands displayed in the operation details. However
this makes several of the other single command actions need special exit
status handling because zero success, non-zero failure is not correct
for every case. Specifically affects resizing of reiserfs and check
repair of ext2/3/4, fat16/32, jfs and reiserfs.
After this change all external commands run as file system actions must
follow one of these two patterns of using the EXEC_CHECK_STATUS flag or
separately calling FileSystem::set_status() to register success or
failure of the command:
exit_status = execute_command(cmd, od, EXEC_CHECK_STATUS...);
or:
exit_status = execute_command(cmd, od, ...);
bool success = (exit_status == 0 || exit_status == OTHER_SUCCESS_VALUE...);
set_status(od, success );
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
Change the two optional boolean parameters into a single optional flags
parameter which uses symbolically defined names. Makes reading the
execute_command() calls much easier to understand. (Implemented as bit
field using the same technique as used for Glib::SpawnFlags [1]).
This changes the calls thus:
execute_command(cmd, od) -> (cmd, od)
execute_command(cmd, od, false) -> (cmd, od, EXEC_NONE) // [2]
execute_command(cmd, od, true ) -> (cmd, od, EXEC_CHECK_STATUS)
execute_command(cmd, od, false, true) -> (cmd, od, EXEC_CANCEL_SAFE)
execute_command(cmd, od, true , true) ->
(cmd, od, EXEC_CHECK_STATUS|EXEC_CANCEL_SAFE)
[1] SpawnFlags bitwise operators in
/usr/include/glibmm-2.4/glibmm/spawn.h.
[2] False and EXEC_NONE are the default values for the optional third
parameter before and after this change respectively and both mean
the same. This is being used in btrfs::resize() and being kept for
now despite it being the default.
Bug 754684 - Updates to FileSystem:: and Utils::execute_command()
functions
Btrfs-progs 4.1, released June 2015, includes support for changing the
UUID of a btrfs file system using the btrfstune command. Check for
availability by looking for the -u option in the btrfstune help output.
Use btrfstune like this:
# umount /dev/sdb1
# btrfstune -f -u /dev/sdb1
Current fsid: e7ad5dba-d721-4f99-990b-1ba2901c8ad2
New fsid: 231563d9-e173-410d-b1da-d34c4319a423
Set superblock flag CHANGING_FSID
Change fsid in extents
Change fsid on devices
Clear superblock flag CHANGING_FSID
Fsid change finished
# echo $?
0
Bug 751337 - btrfstune in btrfs-progs 4.1 supports changing the file
system UUID
This patch changes the reading of the btrfs multi-device membership to
resolve issue 1/2 by ignoring the exit status from the 'btrfs filesystem
show' command and relying on parsing the required information to
determine success or failure.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
Patch 3/4 - btrfs::read_label()
This patch changes the btrfs file system usage reading code to resolve
issue 1/2 by ignoring the exit status from the 'btrfs filesystem show'
command and relying on parsing the required information to determine
success or failure.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
Issue 2/2 - GParted doesn't show label for mounted btrfs file systems
'btrfs filesystem show /dev/PTN' command is used to query details of a
btrfs file system including reading the file system label. When the
file system is mounted the label is no longer enclosed in single quotes,
but only when using btrfs-progs v3.12. This causes GParted to think the
label is blank when the file system is mounted and therefore no longer
display it.
File system label not enclosed in single quotes when mounted:
# fgrep sdb1 /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,relatime,space_cache 0 0
# btrfs filesystem show /dev/sdb1
Label: test1-btrfs uuid: 1f78fa38-2f85-41d3-9be6-ae0356ae9469
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.12
File system label enclosed in single quotes when unmounted:
# umount /dev/sdb1
# btrfs filesystem show /dev/sdb1
Label: 'test1-btrfs' uuid: 1f78fa38-2f85-41d3-9be6-ae0356ae9469
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.12
Removing the single quotes enclosing the label makes the output
identical to that from the older 'btrfs-show' command.
Fix by using a common parser to extract the label from both the
'btrfs filesystem show' and 'btrfs-show' commands which can read the
label with and without enclosing single quotes.
Patch 2/4 - btrfs::read_label()
This patch changes the btrfs file system label parsing code to resolve
issue 1/2 by ignoring the exit status from the 'btrfs filesystem show'
command and relying on parsing the required information to determine
success or failure. Issue 2/2 is also resolved as described above.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
Issue 1/2 - GParted shows warnings for mounted btrfs file systems
'btrfs filesystem show /dev/PTN' command is used to query details of a
btrfs file system. When the file system is mounted the command reports
failed exit status 1, but only when using btrfs-progs v3.14 and v3.14.1.
This causes GParted to: (1) report warnings from the failed commands for
a mounted btrfs file system, (2) fail to determine file system usage
figures and (3) fail to display the mount point and busy indicator for
non-mounting devices in multi-device btrfs file systems. The label is
also read using the secondary blkid method via the FS_Info cache.
Failed exit status 1 when the btrfs file system is mounted:
# fgrep sdb1 /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,space_cache 0 0
# btrfs filesystem show /dev/sdb1
Label: 'test1-btrfs' uuid: 033e6b07-ee6a-4620-a585-8580a2b83275
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.14.1
# echo $?
1
Successful exit status 0 when the btrfs file system is unmounted:
# umount /dev/sdb1
# btrfs filesystem show /dev/sdb1
Label: 'test1-btrfs' uuid: 033e6b07-ee6a-4620-a585-8580a2b83275
Total devices 1 FS bytes used 192.00KiB
devid 1 size 2.00GiB used 240.75MiB path /dev/sdb1
Btrfs v3.14.1
# echo $?
0
Fix by ignoring the exit status of the 'btrfs filesystem show' command
and rely on parsing the required information to determine success or
failure. The output from the older 'btrfs-show' command is almost
identical so the same code will parse it in all cases.
Patch 1/4 - btrfs::read_uuid()
This patch changes the secondary method used to read the btrfs UUID to
resolve issue 1/2 as described above.
Bug #733601 - Btrfs: Warnings and missing label with btrfs-progs 3.12
and 3.14
In a number of cases there may be no btrfs device cache entry. Some of
the reasons why this can occur:
1) Mounting device removed from btrfs on linux <= 3.4 so old mount
point in /proc/mounts;
2) btrfs and btrfs-show commands don't exist;
3) btrfs or btrfs-show command returned non-zero exit status;
4) get_cache_entry() failed to parse output from btrfs filesystem show
or btrfs-show.
Without a valid btrfs device cache entry, busy detection for all member
devices fails. Search the GParted internal mounted partitions map as
the fallback busy detection method. This can only determine if the
mounting device is mounted or not, not any of the other members of a
multi-device btrfs file system.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
GParted doesn't specify the devid when resizing a btrfs file system, so
the kernel defaults to resizing devid 1. On a multi-device btrfs this
may not be the same partition which GParted is resizing. This will
result in file system truncation and corruption. Shrinking the wrong
partition example:
1) Create a btrfs file system spanning 2 partitions:
# mkfs.btrfs /dev/sdb1 /dev/sdb2
# btrfs filesystem show /dev/sdb1
Label: none uuid: 41654265-9840-45c4-aca1-55989da358d6
Total devices 2 FS bytes used 112.00KiB
devid 1 size 2.00GiB used 437.50MiB path /dev/sdb1
devid 2 size 2.00GiB used 417.50MiB path /dev/sdb2
2) Resize /dev/sdb2 down to 1 GiB using GParted. This command was
run:
btrfs filesystem resize 1048576K /tmp/gparted-ddyGRh
which resized devid 1 (/dev/sdb1) to 1 GiB:
# btrfs filesystem show /dev/sdb1
Label: none uuid: 41654265-9840-45c4-aca1-55989da358d6
Total devices 2 FS bytes used 256.00KiB
devid 1 size 1.00GiB used 437.50MiB path /dev/sdb1
devid 2 size 2.00GiB used 417.50MiB path /dev/sdb2
but GParted instead resized /dev/sdb2 to 1 GiB:
# sfdisk -s /dev/sdb1
2097152
# sfdisk -s /dev/sdb2
1048576
Even on a single device btrfs devid 1 may no longer exist if the file
system has had the initial device removed from it. Example:
1) Create a single btrfs file system, add a second device and
remove the first:
# mkfs.btrfs /dev/sdb1
# mount /dev/sdb1 /mnt/1
# btrfs device add /dev/sdb2 /mnt/1
# btrfs device remove /dev/sdb1 /mnt/1
# umount /mnt/1
# btrfs filesystem show /dev/sdb2
Label: none uuid: 2cbf3ac3-1344-472a-a0c7-1476d23bdc9f
Total devices 1 FS bytes used 256.00KiB
devid 2 size 2.00GiB used 480.00MiB path /dev/sdb2
2) Again resize /dev/sdb2 down to 1 GiB using GParted. This
command was run:
btrfs filesystem resize 1048576K /tmp/gparted-ddyGRh
but it failed with:
ERROR: unable to resize 'tmp/gparted-lEyGaY' - No such device
A more informative error message was written to syslog:
# tail -1 /var/log/messages
Mar 12 14:15:01 localhost kernel: btrfs: resizer unable to find device 1
This is with Linux kernel 3.13.5 on Fedora 20, circa March 2014.
Fix by specifying the devid when resizing (part of) a btrfs file system.
Example command specifying devid 2:
btrfs filesystem resize 2:1048576K /tmp/1
This will always work because it is the kernel which interprets the
devid colon size parameter and has always done so since btrfs was first
added to the kernel in version 2.6.32 [1].
Reference:
[1] linux v2.6.32 fs/btrfs/ioctl.c btrfs_ioctl_resize()
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/ioctl.c?id=v2.6.32#n578
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Currently GParted fails to report the usage of a multi-device btrfs file
system if it is mounted or if the used space is larger than the size of
an individual member device. When GParted does display usage figures it
also incorrectly reports the file system wide used figure against every
member device.
Mounted case:
statvfs() provides an FS size which is larger than any individual
device so is rejected. See:
GParted_Core::mounted_set_used_sectors()
Utils::get_mounted_filesystem_usage()
partition .set_sector_usage()
Unmounted case, FS used > device size:
FS used figure is larger than any individual device so free space is
calculated as a negative number and rejected. See:
btrfs::set_used_sectors()
Btrfs has a volume manager layer within the file system which allows it
to provide multiple levels of data redundancy, RAID levels, and use
multiple devices both of which can be changed while the file system is
mounted. To achieve this btrfs has to allocate space at two different
level: (1) chunks of 256 MiB or more at the volume manager level; and
(2) extents at the file data level.
References:
* Btrfs: Working with multiple devices
https://lwn.net/Articles/577961/
* Btrfs wiki: Glossary
https://btrfs.wiki.kernel.org/index.php/Glossary
This makes the question of how much disk space is being used in an
individual device a complicated question to answer. Further, the
current btrfs tools don't provide the required information.
Btrfs filesystem show only provides space usage information at the chunk
level per device. At the file extent level only a single figure for the
whole file system is provided. It also reports size of the data and
metadata being stored, not the larger figure of the amount of space
taken after redundancy is applied. So it is impossible to answer the
question of how much disk space is being used in an individual device.
Example output:
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
Fix by guesstimating the per device used figure as the fraction of the
file system wide extent usage based on chunk usage per device.
Calculation:
ptn fs used = total fs used * devid used / sum devid used
Positives:
1) Per device used figure will correctly be between zero and allocated
chunk size.
Known inaccuracies:
[for single and multi-device btrfs file systems]
1) Btrfs filesystem show reports file system wide file extent usage
without considering redundancy applied to that data. (By default
btrfs stores two copies of metadata and one copy of data).
2) At minimum size when all data has been consolidated there will be a
few partly filled chunks of 256 MiB or more for data and metadata of
each storage profile (RAID level).
[for multi-device btrfs file systems only]
3) Data may be far from evenly distributed between the chunks on
multiple devices.
4) Extents can be and are relocated to other devices within the file
system when shrinking a device.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Linux can only show a single device name in /proc/mounts and /etc/mtab
for each mounted btrfs, even if it is a multi-device file system. So
GParted only shows a mount point for one of the devices in the btrfs, no
matter how many devices are part of the file system.
# mkfs.btrfs /dev/sdb1 /dev/sdb2
# btrfs filesystem show /dev/sdb1
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
# mount /dev/sdb1 /mnt/1
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
GParted only shows the mount point for /dev/sdb1 as /mnt/1, but nothing
for /dev/sdb2.
Make GParted report the same mount point for all devices included in a
multi-device btrfs file system.
Add btrfs specific get_mount_device() method to report the mounting
device, if any, for the btrfs file system in the occupying the device in
question. Uses the existing cache of btrfs file system device
membership. Also extract common code from GParted_Core::
set_mountpoints() into set_mountpoints_helper().
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
Busy detection of file systems works by checking if the device is
mounted (appears in the mount_info map). For a multi-device btrfs file
system this will only report one of the devices as busy, not all of
them.
# btrfs filesystem show /dev/sdb1
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 2 FS bytes used 156.00KB
devid 2 size 2.00GB used 512.00MB path /dev/sdb2
devid 1 size 2.00GB used 240.75MB path /dev/sdb1
# mount /dev/sdb1 /mnt/1
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
GParted will only report /dev/sdb1 as busy, but not /dev/sdb2.
Add btrfs specific is_busy() method which reports the device as busy if
any of the devices in the btrfs file system are mounted. This uses a
cache which maps device membership in all btrfs file systems. The cache
is cleared on GParted refresh and incrementally populated as each btrfs
partition is checked for busy status.
WARNING:
Removal of the mounting device from a btrfs file system makes it
impossible to determine whether the file system is mounted or not for
linux <= 3.4. This is because /proc/mounts continues to show the old
device which is no longer a member of the file system.
# btrfs device delete /dev/sdb1 /mnt/1
# sync
# grep btrfs /proc/mounts
/dev/sdb1 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0
# btrfs filesystem show /dev/sdb1
# btrfs filesystem show /dev/sdb2
Label: none uuid: 36eb51a2-2927-4c92-820f-b2f0b5cdae50
Total devices 1 FS bytes used 28.00KB
devid 2 size 2.00GB used 1.02GB path /dev/sdb2
Fixed in linux 3.5 by commit:
Btrfs: implement ->show_devname
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9c5085c147989d48dfe74194b48affc23f376650
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
GParted's primary inbuilt busy detection method is "is the partition
mounted?". A custom method is used for LVM2 PV because its not a
mounted file system.
Make busy detection selectable per file system type.
.fs.busy = FS::NONE (default)
No busy detection.
.fs.busy = FS::GPARTED
Use internal GParted method which checks if the partition is
mounted.
.fs.busy = FS:EXTERNAL
Call the file system type's member function is_busy().
LVM2 PV busy detection changes from a special case to just electing to
call the lvm2_pv::is_busy() method. Linux Software RAID remains a
special case because it's only recognised, but not otherwise supported.
Bug #723842 - GParted resizes the wrong filesystem (does not pass the
devid to btrfs filesystem resize)
This is part of parent bug:
Bug #721455 - Obsolete info in license text on multiple modules
and GNOME Goal:
https://wiki.gnome.org/Initiatives/GnomeGoals/Proposals
* verify all source files to make sure they have a license and a
copyright, and that both are up-to-date
Bug #721565 - License text contains obsolete FSF postal address
Many file systems are capable of growing while mounted, and a few can
even shrink. This support must be explicitly enabled at configure time
with the --enable-online-resize flag and depends on a patched libparted.
Also requires kernel >= 3.6 for partition resizing, even if the
partition is in use (BLKPG_RESIZE_PARTITION).
Thanks to Mike Fleetwood for double check mark idea instead of a second
column to show the online grow/shrink.
Bug #694622 - Add support for online resize
All the code was there in btrfs::read_uuid() to read the UUID from the
btrfs-show command. It just needed enabling.
This is only relevant when: (1) the blkid command is unavailable as
GParted primarily reads the UUID through the FS_Info cache using the
blkid command, and (2) the btrfs command is unavailable and the btrfs
module uses the older btrfs-show command instead.
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
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.
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.
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
GParted doesn't notice when a file system label is changed to blank.
GParted first calls the file system specific read_label() method. When
the label is blank read_label() correctly sets partition.label to the
zero length string. Second GParted_Core::set_device_partitions() treats
the zero length string to mean that the label is unset and calls
FS_Info::get_label() to retrieve it from the cache of blkid output.
Blkid also doesn't notice when the file system label has been changed to
blank so reports the previous label. Hence GParted displays the
previous file system label.
Fix by making label a private member variable of the class Partition and
providing access methods set_label(), get_label() and label_known()
which track whether the label has been set or not. This only fixes the
fault for file systems which use file system specific commands to read
the label and when these tools are installed. Otherwise GParted uses,
or has to fall back on using, the buggy blkid command to read the file
system label.
NOTE:
Many of the file system specific read_label() methods use a tool which
outputs more than just the label and use Utils::regexp_label() to match
leading text and the label itself. If the surrounding text changes or
disappears altogether to indicated a blank label, regexp_label() doesn't
match anything and returns the zero length string. This is exactly
what is required and is passed to set_label() to set the label to blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
Each file system class can now choose how the size and free space of the
file system is determined when it is mounted.
.fs.online_read = FS::NONE (default)
Do nothing. Don't get the file system size and free space.
.fs.online_read = FS::GPARTED
Use internal GParted method which calls statvfs() system call on
the mounted file system.
.fs.online_read = FS::EXTERNAL
Call the file system's member function set_used_sectors(). This
is the same function as called when the file system is not
mounted. It can determine if the file system is mounted or not
by testing partition.busy and acting accordingly.
This means that determining the size and free space of active LVM2
Physical Volumes is no longer a special case. Instead the lvm2_pv class
just elects to have its set_used_sectors() method called for both the
active and deactive cases.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Use the new RFC 4122 none Nil UUID regular expression to validate the
UUID read in all the Linux native file system specific read_uuid()
methods. No longer need to explicitly exclude "<none>" or all zeros Nil
UUID as the regular expression does this.
This commit only adds a remove() method to every file system and an
optional call to it in the relevant operations. All remove() methods
are no operations and not enabled.
The remove() method provides explicit controlled removal of a file
system before the partition is deleted or overwritten by being formatted
or pasted into. When implemented, it appears as an extra step in the
relevant operation. The file system specific remove() method is
explicitly allowed to fail and stop the operations currently being
applied.
This is different to the existing erase_filesystem_signatures() which
wipes any previous file system signatures immediately before a new file
system is written to ensure there is no possibility of the partition
containing two or more different file system signatures. It never fails
or reports anything to the user.
NOTE:
Most file systems should NOT implement a remove() method as it will
prevent recovery from accidental partition deletion.
Bug #670171 - Add LVM PV read-write support
The member functions btrfs_size_to_num(), btrfs_size_max_delta() and
btrfs_size_to_gdouble() don't access any member variables. Therefore
they don't need the const qualifier allowing them to be called when the
btrfs object is const for read-only access to member variables, but
instead need to be static member functions with no access to member
variables.
The btrfs programs only provide approximations of file system sizes
because they display figures using binary prefix multipliers to two
decimal places of precision. E.g. 2.00GB. For partition sizes where
the contained file system size rounds upwards, GParted will fail to read
the file system usage and report a warning because the file system will
appear to be larger than the partition.
For example, create a 2047 MiB partition containing a btrfs file system
and display its size.
# btrfs filesystem show
Label: none uuid: 92535375-5e76-4a70-896a-8d796a577993
Total devices 1 FS bytes used 28.00KB
devid 1 size 2.00GB used 240.62MB path /dev/sda12
The file system size appears to be 2048 MiB, but that is larger than the
partition, hence the issue GParted has. (Actually uses the btrfs devid
size which is the size of the btrfs file system within the partition in
question).
This issue is new with the fix for Bug #499202 because it queries the
file system sizes for the first time. The same issue could
theoretically occur previously, but with the used figure (FS bytes
used). This would have been virtually impossible to trigger because
btrfs file system would have to have been greater than 99% full, but
btrfs has been notorious for early reporting of file system full.
The fix is that if a btrfs file system size appears larger than the
partition size, but the minimum possible size which could have been
rounded to the reported figure is within the partition size use the
smaller partition size instead. Apply the method to the used figure
too, in case the file system is 100% full. Also if the btrfs file
system size appears smaller than the partition size, but the maximum
possible size which could have been rounded to the reported figure is
within the partition size use the larger partition size instead to avoid
reporting, presumably false, unallocated space. Not applied to file
system used figure.
Bug 499202 - gparted does not see the difference if partition size
differs from filesystem size
Update file system specific implementations to set the size and free
space, thus allowing the unallocated space in the partition to be
calculated, for the following unmounted file systems:
btrfs, ext2, ext3, ext4, fat16, fat32, jfs, nilfs2, ntfs, reiserfs,
reiser4, xfs
Bug #499202 - gparted does not see the difference if partition size
differs from filesystem size
Btrfs file system can be successfully resized to the same size without
failing on Linux 3.2 or higher.
Linux 3.2-rc4 includes commit:
35bae54a255fbf3eab747b842d300d59f6e1abb4
Btrfs: Don't error on resizing FS to same size
Closes bug #669389
Add the ability to set a new random UUID on file systems that provide
the appropriate tools to perform this action.
Update the help manual to include this new functionality. Also add
reference links to "setting a partition label" and "changing a
partition UUID" in the "copying and pasting a partition" section.
This patch does not include setting the UUID on an NTFS file system.
Bug #667278 - Add support for setting UUID
Bug #608308 - fix documentation - Copying and Pasting a Partition
Btrfsctl and btrfs-show were depreciated in October 2011 and have been
superseeded by the newer btrfs multi-tool control command. Use btrfs as
first choice, falling back to btrfsctl and btrfs-show when not found.
There are still 2 issues with reading btrfs labels when falling back
on using btrfs-show command, rather than primary method of using the
blkid command:
1) Label is set no "none" when btrfs-show is reporting there is no
label, although it is impossible to distinguish from the case of the
label actually being set to "none".
2) The label has 2 trailing spaces appended as the regular expression
matches "Label: (btrfslabel )uuid:" rather than
"Label: (btrfslabel) uuid:" in the btrfs-show output.
Assume a label "none" means there is no label and fix the regular
expression.
This adds initial handlers for Btrfs; only .create, .check and
.read_label are done for now, via external btrfs-tools.
Other methods are still only stubs.
Mike Fleetwood