exFAT file system usage is no longer readable when exfatprogs 1.2.3,
released 2024-05-23 [1], and later is installed. This is because the
output from dump.exfat changed as a result of commit [2].
On Fedora 39 with exfatprogs 1.2.3 installed and exfatprogs 1.2.2
compiled locally from git; old dump.exfat output:
# ~fedora/programming/c/exfatprogs/dump/dump.exfat /dev/sdb1 | egrep 'exfatprogs version|Volume Length\(sectors\):|Sector|Free Clusters:'
exfatprogs version : 1.2.2
Volume Length(sectors): 524288
>> Sector Size Bits: 9
>> Sector per Cluster bits: 3
Free Clusters: 65024
New dump.exfat output:
# dump.exfat /dev/sdb1 | egrep 'exfatprogs version|Volume Length\(sectors\):|Sector|Free Clusters:'
exfatprogs version : 1.2.3
Volume Length(sectors): 524288
>> Bytes per Sector: 512
>> Sectors per Cluster: 8
Free Clusters: 65024
Change the code to read exFAT usage only from dump.exfat 1.2.3 style
output. Don't parse older style output for now as that makes the code
simpler.
[1] exfatprogs-1.2.3 version released
https://github.com/exfatprogs/exfatprogs/releases/tag/1.2.3
[2] dump: Sector and Cluster units
41863cb0f5Closes#261 - Unable to read the contents of exfat file system with
exfatprogs >= 1.2.3
As CentOS has been discontinued remove references to it from the README.
Also update package manager command from yum to dnf now RHEL 8 is the
earliest supported release.
Now that the official Ubuntu latest docker image has updated to Ubuntu
24.04 LTS [1] the build CI job fails like this:
$ make -j $nproc
...
/usr/bin/msgfmt --desktop --template gparted.desktop.in -d ./po -o gparted.desktop
/usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy
/usr/bin/msgfmt: cannot locate ITS rules for org.gnome.gparted.policy.in
make[2]: *** [Makefile:1060: org.gnome.gparted.policy] Error 1
The needed fix is already documented in the README file [2]. Install
the required package into the Ubuntu CI docker images to fix this.
[1] Ubuntu Docker official image
https://hub.docker.com/_/ubuntu/
"Supported tags and respective Dockerfile links
...
24.04, ..., latest, ...
"
[2] 16c2533af0
Document future Debian/Ubuntu build time dependency in README (!121)
Closes!124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
Network Block Devices are not displayed in GParted as partitionable
devices. They do appear in /proc/partitions, are reported by
fdisk -l [1] and by ped_device_probe_all() from libparted. Therefore
include them.
Create NBD device for testing:
# truncate -s 1G /tmp/disk-1G.img
# nbd-server -C /dev/null 9000 /tmp/disk-1G.img
# nbd-client localhost 9000 /dev/nbd0
After creating a couple of partitions for testing, the contents of
/proc/partitions looks like this:
# egrep 'name|nbd' /proc/partitions
major minor #blocks name
43 0 1048576 nbd0
43 1 262144 nbd0p1
43 2 785408 nbd0p2
Listing all disks using fdisk:
# fdisk -l
...
Disk /dev/nbd0: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x081b1cd1
Device Boot Start End Sectors Size Id Type
/dev/nbd0p1 2048 526335 524288 256M 83 Linux
/dev/nbd0p2 526336 2097151 1570816 767M 83 Linux
Temporarily apply this patch to GParted so that it ignores the devices it
currently selects from /proc/partitions to use what get_device_probe_all()
reports. GParted shows NBDs.
$ git diff --unified=1
diff --git a/src/GParted_Core.cc b/src/GParted_Core.cc
index 1629f94f..abea7a0b 100644
--- a/src/GParted_Core.cc
+++ b/src/GParted_Core.cc
@@ -172,3 +172,3 @@ void GParted_Core::set_devices_thread( std::vector<Device> * pdevices )
//try to find all available devices if devices exist in /proc/partitions
- std::vector<Glib::ustring> temp_devices = Proc_Partitions_Info::get_device_paths();
+ std::vector<Glib::ustring> temp_devices;
if ( ! temp_devices .empty() )
Tidy-up NBD device:
# nbd-client -d /dev/ndb0
# killall nbd-server
# rm /tmp/disk-1G.img
[1] man fdisk
"-l, --list
List the partition tables for the specified devices and then
exit. If no devices are given, the devices mentioned in
/proc/partitions (if this file exists) are used.
"
Closes#247 - GParted does not list NBD (Network Block Device) devices
in the GUI
When preparing the GParted Live 1.6.0 distribution, which is based on
Debian unstable ("sid"), compiling GParted failed like this:
$ make
...
/usr/bin/msgfmt --desktop --template gparted.desktop.in -d ./po -o gparted.desktop
chmod +x gparted
/usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy
/usr/bin/msgfmt: cannot locate ITS rules for org.gnome.gparted.policy.in
make[3]: *** [Makefile:1060: org.gnome.gparted.policy] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/root/gparted/gparted-1.6.0-beta1'
make[2]: *** [Makefile:618: all-recursive] Error 1
make[2]: Leaving directory '/root/gparted/gparted-1.6.0-beta1'
make[1]: *** [Makefile:452: all] Error 2
make[1]: Leaving directory '/root/gparted/gparted-1.6.0-beta1'
dh_auto_build: error: make -j16 returned exit code 2
make: *** [debian/rules:9: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
debuild: fatal error at line 1184:
dpkg-buildpackage -us -uc -ui failed
This was also previously reported in the GParted Forum [1]. Future
Debian 13 ("trixie") and Ubuntu 24.04 LTS ("nobel") releases have moved
the needed gettext translation rules for .policy XML files:
/usr/share/gettext/its/policy.its
/usr/share/gettext/its/policy.loc
to new package libpolkit-gobject-1-dev not installed by default.
Document this new build time dependency.
Also see commits [2][3] where the equivalent change was needed in the
Alpine Linux and CentOS continuous integration images.
[1] GParted forum / [SOLVED] Unable to build "msgfmt: cannot locate ITS
rules for org..."
http://gparted-forum.surf4.info/viewtopic.php?id=18136
[2] 57ae8f888b
Fix .policy file translation failure in Alpine Linux CI image (!107)
[3] 8450d8c605
Fix .policy file translation failure in CentOS CI image (!107)
Closed!121 - Document future Debian/Ubuntu build time dependency in
README
... now Attempt Data Rescue has been removed and GParted no longer has
code to show "file:/tmp/gparted-roview-XXXXXX" URIs. Missed in earlier
commit:
8ce9074ac6
Remove Attempt Data Rescue and use of gpart (!118)
As the AppStream 1.0 [1] specification no longer describes them as
appdata files, but instead as metainfo files, rename the Makefile.am
variables for consistency with the name of the standard.
[1] AppStream 1.0
https://www.freedesktop.org/software/appstream/docs/index.htmlCloses#241 - Move appstream metadata out of legacy path
AppData files always were a subset of the AppStream specification
[1][2]. AppStream 0.12 specification [3] onwards says the metainfo
files will be found when placed in /usr/share/metainfo/ *AND* that
/usr/share/appdata/ is a legacy location *AND* a future release of
AppStream will likely drop support for it [4].
Debian 10, RHEL 7 and Ubuntu 18.04 LTS distributions all have the
/usr/share/metainfo/ directory containing application .appdata.xml and
.metainfo.xml files. Ubuntu 16.04 LTS does not have the directory
despite the AppStream specification [3] claiming it does. As old
supported distributions do have the directory, unconditionally update
this.
For reference are these commits in projects GNOME System Monitor [4] and
Evince [5] from 2017 making the same change.
[1] AppData Specification [circa 2016]
https://web.archive.org/web/20160903181519/https://people.freedesktop.org/~hughsient/appdata/
"Rather than create a new schema from scratch, we'll be using a
subset of the AppStream metadata proposal.
Applications wishing to have long descriptions, screenshots and
other useful things are required to ship one or more files in
/usr/share/appdata/%{id}.appdata.xml.
"
[2] AppStream 0.4, 2.2 AppData XML files [circa 2013]
https://web.archive.org/web/20131204004054/http://www.freedesktop.org/software/appstream/docs/sect-AppStream-Metadata-AppData.html
[3] AppStream 0.12, 2.1.2 Filesystem locations [circa 2020]
https://web.archive.org/web/20200615042130/https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
"2.1.2 Filesystem locations
Upstream projects can ship one or more metainfo files in
/usr/share/metainfo/%{id}.metainfo.xml, where id is a unique
identifier of this specific component.
(>) Note
Component metadata of type desktop-application as described in
Section 2.2, "Desktop Applications" can be installed with an
.appdata.xml extension as well for historical reasons. AppStream
implementations will read the XML files as long as they end up in
the right location on the filesystem.
(!) Important: Legacy Path
AppStream tools scan the /usr/share/appdata/ path for legacy
compatibility as well. It should not be used anymore by new
software though, even on older Linux distributions (like RHEL 7 and
Ubuntu 16.04 LTS) the metainfo path is well supported. Support for
the legacy path will likely be dropped completely with a future
AppStream 1.0 release.
"
[4] [GNOME System Monitor] Install appdata to the new location
(bgo#790146)
43dc057771
[5] [Evince] build: Install appstream metadata to non-deprecated
location
8cae24ea48Closes#241 - Move appstream metadata out of legacy path
... code pattern. This is to make the code easier to understand by not
having to remember if condition context for indented code over longer
distances. This has been done before. Here are just 2 examples:
[1] 75bda733bb
Refactor run_blkid_load_cache() into if fail return early (#131)
[2] 407e0ac6e3
Refactor fat16::read_label() into if fail return early pattern (!104)
Closes!119 - Tidy-ups for file system interface classes
Restructure the variable parsing code into "if leading text found then
scan the number" pattern.
Closes!119 - Tidy-ups for file system interface classes
Restructure the variable parsing code into "if leading text found then
scan the number" pattern.
Anchor leading text matches to the start of a new line in the output.
Closes!119 - Tidy-ups for file system interface classes
Restructure the variable parsing code into "if leading text found then
scan the number" pattern.
Closes!119 - Tidy-ups for file system interface classes
And restructure the variable parsing code into "if leading text found
then scan the number" pattern.
Anchor leading text matches to the start of a new line in the output.
Closes!119 - Tidy-ups for file system interface classes
FileSystem member variables T, N & S are being used like local variables
in many of the file system specific set_used_sectors() methods. They
are only used within each set_used_sectors() call and not used to
represent persistent information of a FileSystem interface class or to
pass information between separate methods. Therefore stop using them
and replace them with local variables instead.
This block of code finds a field in the output and scans the number:
Glib::ustring::size_type index = output.find("Block count:");
if (index >= output.length() ||
sscanf(output.substr(index).c_str(), "Block count: %lld", &T) != 1)
T = -1;
The if statement says "if leading text is not found or scanning the
number fails then assign -1". A sequence of two negatives leading to
assigning an error value is hard to understand. Instead this an
equivalent block from btrfs::set_used_sectors():
long long total_bytes = -1;
Glib::ustring::size_type index = output.find("\ntotal_bytes");
if (index < output.length())
sscanf(output.substr(index).c_str(), "\ntotal_bytes %lld", &total_bytes);
This assigns a default error value and the if statement says "if leading
text found then scan the number". Much simpler to understand.
Therefore change the code around to use this same pattern.
Anchor the leading text matches to the start of a new line in the
output where possible. Just because it's what some of the other file
system's set_used_sectors() methods do (btrfs, reiser4 and xfs) and it
seems like more robust text matching.
Closes!119 - Tidy-ups for file system interface classes
Replace floating point calculation to convert size and space figures
from file system block sized units to sectors with an integer
calculation. Do this for the same reasons discussed in commit "Stop
using floating point calculations in FS resize() methods" earlier in
this patchset. This will limit the largest file system that GParted can
read the usage of to 8 EiB - 1 bytes.
There is still a floating point calculation in btrfs::set_used_sectors()
which is being left because that is apportioning used space figure
between multiple devices.
Closes!119 - Tidy-ups for file system interface classes
A number of the file system specific resize() methods use floating point
calculations to convert from the new partition size in sectors to the
new file system size to be passed to the resize command in bytes or
kibibytes. This is bad because there could be rounding errors
converting from integer to floating point, performing the calculation
and converting back. Replace with integer only multiply and divide
calculations. Integer division always truncates [1] which is exactly
what is needed. The largest integer will be the size of the file system
in bytes held in a signed 64-bit long long, or Sector or Byte_Value
typedef of the same type. This will limit the size that a file system
can be shrunk to, to 8 EiB - 1 byte.
[1] C++ Arithmetic operators
https://en.cppreference.com/w/cpp/language/operator_arithmetic
"the algebraic quotient of integer division is truncated towards
zero (fractional part is discarded)"
Closes!119 - Tidy-ups for file system interface classes
The GUI displays the file system of an open encrypted file system as
"[Encrypted] FSTYPE" [1]. However saved details just writes the file
system type as "luks". Update saved details writing code to use the
same method the GUI currently uses [2].
[1] commit cb3cc505ce
Display "[Encrypted] FSTYPE" in the File System column (#760080)
[2] commit bd6fc67afb
Provide virtual Partition::get_filesystem_string() method (#774818)
Keep the paragraph discussing photorec and move just after testdisk is
mentioned in the Recovering Partition Tables section.
Closes!118 - Remove Attempt Data Rescue and use of gpart
gpart scans a drive trying to guess the location of partitions when an
MBR partition table is lost [1]. However the tool is unmaintained,
takes hours or days of 100% CPU time to scan a drive and provides no
progress indication [2][3][4]. We keep recommending killing the gpart
process and using TestDisk [5] instead.
Therefore remove Device > Attempt Data Rescue and the use of gpart from
GParted.
[1] Gpart
https://github.com/baruch/gpart
[2] Have you had a good or bad experience with Dev->Attempt Data Rescue?
http://gparted-forum.surf4.info/viewtopic.php?id=17992
No good, only bad experiences using gpart were reported.
[3] Gparted does not say anything
http://gparted-forum.surf4.info/viewtopic.php?id=17749
Forum user reported waiting 48 hours with no progress indication.
We recommended using TestDisk.
[4] How cancel Data Rescue process?
http://gparted-forum.surf4.info/viewtopic.php?id=18143
Forum user reported it will take 3 days to scan their external 480GB
drive. We recommended using TestDisk instead.
[5] TestDisk, Data Recovery
https://www.cgsecurity.org/wiki/TestDiskCloses!118 - Remove Attempt Data Rescue and use of gpart
Mike Fleetwood