# Generated by Makefile. Do not edit. 2024-02-26 Curtis Gedak ========== gparted-1.6.0 ========== 2024-02-26 Curtis Gedak Update copyright years 2024-02-24 Mike Fleetwood Document future Debian/Ubuntu build time dependency in README (!121) 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] 57ae8f888bb6f5fb8f06177a478a2374f07ee33c Fix .policy file translation failure in Alpine Linux CI image (!107) [3] 8450d8c6056a79508bdb91517eb4d8c5dc60fb35 Fix .policy file translation failure in CentOS CI image (!107) Closed !121 - Document future Debian/Ubuntu build time dependency in README 2024-02-10 Cheng-Chia Tseng Update Chinese (Taiwan) translation 2023-11-06 Mike Fleetwood Remove final namespace qualifiers from use of GParted's own enums ... because it is not necessary and clutters the code. 2024-01-30 Mike Fleetwood Remove optional desktop filemanager dependency from 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: 8ce9074ac672b19f29fd7c1cdc836a874be314cd Remove Attempt Data Rescue and use of gpart (!118) 2024-01-29 Mike Fleetwood Rename Makefile.am variables to APPSTREAM*/appstream* (#241) 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.html Closes #241 - Move appstream metadata out of legacy path 2024-01-24 Mike Fleetwood Install AppStream file into ${datadir}/metainfo (#241) 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) https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/commit/43dc0577712a6cd0979e4d85ec5196d507bd6e80 [5] [Evince] build: Install appstream metadata to non-deprecated location https://gitlab.gnome.org/GNOME/evince/-/commit/8cae24ea48deafc85265ce42adecb55aa2b57a6f Closes #241 - Move appstream metadata out of legacy path 2024-02-07 Daniel Rusek Update Czech translation 2024-01-30 Daniel Mustieles Updated Spanish translation 2024-01-26 Fran Dieguez Update Galician translation 2024-01-20 Danial Behzadi Update Persian translation 2023-12-28 Anders Jonsson Update Swedish translation 2023-11-30 Juliano de Souza Camargo Update Brazilian Portuguese translation 2023-10-10 Mike Fleetwood Refactor xfs::set_used_sectors() into if fail return early pattern (!119) Closes !119 - Tidy-ups for file system interface classes 2023-10-10 Mike Fleetwood Refactor reiserfs::set_used_sectors() into if fail return early pattern (!119) Closes !119 - Tidy-ups for file system interface classes 2023-10-10 Mike Fleetwood Refactor reiser4::set_used_sectors() into if fail return early pattern (!119) Closes !119 - Tidy-ups for file system interface classes 2023-10-08 Mike Fleetwood Refactor nilfs2::set_used_sectors() into if fail return early pattern (!119) Closes !119 - Tidy-ups for file system interface classes 2023-10-09 Mike Fleetwood Refactor ext2::set_used_sectors() into if fail return early (!119) ... 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] 75bda733bbfcc00cf0cee8a2efca536f5a183f94 Refactor run_blkid_load_cache() into if fail return early (#131) [2] 407e0ac6e3922306133b24359e997b637599f2b3 Refactor fat16::read_label() into if fail return early pattern (!104) Closes !119 - Tidy-ups for file system interface classes 2023-10-10 Mike Fleetwood Remove now unused T, N & S FileSystem member variables (!119) Now those member variables are unused remove them. Closes !119 - Tidy-ups for file system interface classes 2023-10-08 Mike Fleetwood Stop using member variables T, N & S in xfs class (!119) Restructure the variable parsing code into "if leading text found then scan the number" pattern. Closes !119 - Tidy-ups for file system interface classes 2023-10-08 Mike Fleetwood Stop using member variables T, N & S in reiserfs class (!119) 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 2023-10-08 Mike Fleetwood Stop using member variables T, N & S in reiser4 class (!119) Restructure the variable parsing code into "if leading text found then scan the number" pattern. Closes !119 - Tidy-ups for file system interface classes 2023-10-08 Mike Fleetwood Stop using member variables T, N & S in nilfs2 class (!119) 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 2023-10-08 Mike Fleetwood Stop using member variables T & N in linux_swap, luks & lvm2_pv classes (!119) Closes !119 - Tidy-ups for file system interface classes 2023-10-09 Mike Fleetwood Stop using member variables T, N & S in ext2 class (!119) 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 2023-10-14 Mike Fleetwood Stop using floating point calculation in most FS set_used_sectors() methods (!119) 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 2023-10-09 Mike Fleetwood Reorder construction of ext2/3/4 resize command (!119) So that it is similar to other calls to execute_command() and for grep friendliness. Closes !119 - Tidy-ups for file system interface classes 2023-10-08 Mike Fleetwood Reorder construction of nilfs2 resize command (!119) Pass string literal containing the nilfs2 resize command to execute_command() rather than a string variable containing the same command. This makes it the same as how most of the other calls to execute_command() are written and it makes it more grep friendly. Before: $ grep execute_command src/nilfs2.cc if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -L " + Glib::shell_quote( partition.get_filesystem_label() ) + if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -U " + Glib::shell_quote( Utils::generate_uuid() ) + return ! execute_command( "mkfs.nilfs2 -L " + Glib::shell_quote( new_partition.get_filesystem_label() ) + success &= ! execute_command( "mount -v -t nilfs2 " + Glib::shell_quote( partition_new.get_path() ) + >> success &= ! execute_command( cmd, operationdetail, EXEC_CHECK_STATUS ); success &= ! execute_command( "umount -v " + Glib::shell_quote( mount_point ), After: $ grep execute_command src/nilfs2.cc if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -L " + Glib::shell_quote( partition.get_filesystem_label() ) + if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -U " + Glib::shell_quote( Utils::generate_uuid() ) + return ! execute_command( "mkfs.nilfs2 -L " + Glib::shell_quote( new_partition.get_filesystem_label() ) + success &= ! execute_command( "mount -v -t nilfs2 " + Glib::shell_quote( partition_new.get_path() ) + >> success &= ! execute_command("nilfs-resize -v -y " + Glib::shell_quote(partition_new.get_path()) + size, success &= ! execute_command( "umount -v " + Glib::shell_quote( mount_point ), Closes !119 - Tidy-ups for file system interface classes 2023-10-07 Mike Fleetwood Stop using floating point calculations in FS resize() methods (!119) 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 2023-10-22 Sergej A Update Russian translation 2023-10-21 Florentina Mușat Update Romanian translation 2023-10-19 Anders Jonsson Update Swedish translation 2023-10-12 Alan Mortensen Update Danish translation 2023-10-05 Yuri Chornoivan Update Ukrainian translation 2023-09-28 Mike Fleetwood Write file system type as "[Encrypted] FSTYPE" to saved details 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 cb3cc505ce89d6f6fbb488defa826a389ae86cdc Display "[Encrypted] FSTYPE" in the File System column (#760080) [2] commit bd6fc67afb772ffa11ac904e3a7130f2253daa66 Provide virtual Partition::get_filesystem_string() method (#774818) 2023-09-29 Mike Fleetwood Increment GParted Manual version 2023-09-25 Mike Fleetwood Remove Attempt Data Rescue from the GParted Manual (!118) 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 2023-09-25 Mike Fleetwood Remove Attempt Data Rescue and use of gpart (!118) 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/TestDisk Closes !118 - Remove Attempt Data Rescue and use of gpart 2023-09-03 Mike Fleetwood Replace deprecated Google Test API INSTANTIATE_TEST_CASE_P() (!117) When compiling the tests, this warning is reported: $ make check ... warning: ...: INSTANTIATE_TEST_CASE_P is deprecated, please use INSTANTIATE_TEST_SUITE_P [-Wdeprecated-declarations] static_assert(::testing::internal::InstantiateTestCase_P_IsDeprecated(), \ ^ test_SupportedFileSystems.cc:625:1: note: in expansion of macro 'INSTANTIATE_TEST_CASE_P' Google Test 1.10.0 release notes [1] say: High Level Changes: This release deprecated "....TEST_CASE" API in favor of "....TEST_SUITE". In a nutshell if you have code that uses something like "INSTANTIATE_TYPED_TEST_CASE_P " - this and all other "*_TEST_CASE " are now deprecated in favor of more standard _TEST_SUITE. Replace the deprecated API with the new API. [1] Google Test release v1.10.0 https://github.com/google/googletest/releases/tag/release-1.10.0 Closes !117 - Require C++11 compilation 2023-09-03 Mike Fleetwood Update to Google Test 1.10.0 (!117) So far GParted includes Google Test 1.8.1 [1], which was the latest release which supported pre-C++11 compilers [2]. Now that GParted requires C++11 compilation, update to Google Test 1.10.0. Replace the following files and directories from Google Test 1.10.0: LICENSE README.md include/ src/ Note the LICENSE file is identical, where as the other files have changed. This includes file additions and removals, hence the change to Makefile.am too. Even though Google Test releases up to and including 1.12.1 are compilable with C++11 compilers [3], it is not possible to upgrade beyond Google Test 1.10.0 at this time because later releases fail to compile on on still supported RHEL / CentOS 7 with this error: $ cd lib/gtest $ make check ... ./include/gtest/gtest-matchers.h:414:12: error: 'is_trivially_copy_constructible' is not a member of 'std' std::is_trivially_copy_constructible::value && ^ This failure turns out to be because GCC libstdc++ 4.8.5 doesn't include is_trivially_copy_constructible et al [4][5]. [1] commit 2b222978f5e68964a3fa6d9e05e56bfdf6ab0526 Update to Google Test 1.8.1 [2] Google Test release v1.8.1 https://github.com/google/googletest/releases/tag/release-1.8.1 "The 1.8.x is the last release supporting pre-C++11 compilers." [3] Google Test release v1.12.1 https://github.com/google/googletest/releases/tag/release-1.12.1 "This will be the last release to support C++11. Future releases will require at least C++14." [4] 'is_trivially_copyable' is not a member of 'std' https://stackoverflow.com/questions/25123458/is-trivially-copyable-is-not-a-member-of-std/25123551#25123551 "Some of them are not implemented. If we look at libstdc++'s C++11 status page: Type properties are listed as partially implemented. They list as missing: ... is trivially_copy_constructible " [5] The GNU C++ Library, 1. Status, C++11 https://gcc.gnu.org/onlinedocs/gcc-4.8.3/libstdc++/manual/manual/status.html#status.iso.2011 " | Section | Description | Status | Comments ... | 20.9.4.3 | Type properties | Partial | Missing is_trivially_copyable, is_trivially_constructible, is_trivially_default_constructible, is_trivially_copy_constructible, is_trivially_move_constructible, is_trivially_assignable, is_trivially_default_assignable, is_trivially_copy_assignable, is_trivially_move_assignable | " Closes !117 - Require C++11 compilation 2023-09-12 Mike Fleetwood C++11: Also convert NULL to nullptr in unit tests (!117) Closes !117 - Require C++11 compilation 2023-08-31 Mike Fleetwood C++11: Convert NULL to nullptr (!117) In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword. " [4] What is nullptr in C++? Advantages, Use Cases & Examples https://favtutor.com/blogs/nullptr-cpp "Advantages of nullptr ... Compatible: Null pointers are compatible with null pointer constants in the C style (such as NULL and 0). This implies that old C code that uses these constants and null pointers can communicate with each other in C++. " Closes !117 - Require C++11 compilation 2023-08-31 Mike Fleetwood Increase minimum required gtkmm to 3.18.0 (!117) As discussed in the previous commit the oldest supported distributions now provide gtkmm versions higher that 3.18.0 (which requires C++11 compilation). Therefore increase the minimum required version to gtkmm 3.18.0. This allows removal of HAVE_LABEL_SET_XALIGN autoconf definition and associated fallback code. Closes !117 - Require C++11 compilation 2023-08-30 Mike Fleetwood Always require C++11 compilation (!117) All the oldest supported distributions now have versions of GTK C++ libraries which require C++11 compilation, therefore forcing GParted to require C++11 compilation [1][2][3]. Fragment of existing ./configure output which lists the library versions requiring C++11 compilation: $ ./configure ... checking for glibmm >= 2.45.40 which requires C++11 compilation... yes checking for libsigc++ >= 2.5.1 which requires C++11 compilation... yes checking for gtkmm >= 3.18.0 which requires C++11 compilation... yes checking whether g++ supports C++11 features with -std=gnu++11... yes The oldest supported distributions and their versions of GTK C++ libraries and GCC compiler: Distribution gtkmm glibmm libsigc++ gcc Debian 10 3.24.0 2.58.0 2.10.1 4.8.3 RHEL / CentOS 7.9 3.22.2 2.56.0 2.10.0 4.8.5 SLES 12 SP5 3.20.1 2.48.1 2.8.0 4.8 Ubuntu 20.04 LTS 3.24.2 2.64.2 2.10.2 9.3.0 Technically GCC didn't have full C++11 support until GCC 4.8.1 [6] and SLES 12 SP5 only has GCC 4.8 (as well as many later versions of GCC). However which ever version of the GCC compiler is being used to compile the GTK C++ libraries it must have all the features needed to compile those libraries. Simplify the configure script and just always require a C++11 capable compiler. This also allows the use of C++11 features in the GParted code. [1] commit cc0740148e6ba0da9e30608deea2aa13078c2584 port-to-gtk3: Switch to Gtkmm3 (#7) [2] commit 707bae6fed6783e84600c6143f0f4bfd7989f56f Enable C++11 compilation when using libsigc++ 2.5.1 and later (#758545) [3] commit d6d7cb2bbf2fc381b890f63bbbf626eacfc8cdf8 Enable C++11 compilation when using glibmm 2.45.40 and later (#756035) [4] SUSE Product Support Lifecycle, SUSE Linux Enterprise Server 12 https://www.suse.com/lifecycle/#suse-linux-enterprise-server-12 [5] SUSE package search https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=12.5&arch=x86_64&query=&module= [6] C++ Standards Support in GCC, C++11 Support in GCC https://gcc.gnu.org/projects/cxx-status.html#cxx11 Closes !117 - Require C++11 compilation 2023-09-03 Daniel Rusek Update Czech translation 2023-09-02 Luming Zh Update Chinese (China) translation 2023-08-28 Danial Behzadi Update Persian translation 2023-08-20 Baurzhan Muftakhidinov Update Kazakh translation 2023-08-18 Sabri Ünal Update Turkish translation 2023-06-02 Mike Fleetwood Add missing .gitignore entry for test_EraseFileSystemSignatures 2023-08-06 Mike Fleetwood Also find system default udev rules in /usr/lib/udev/rules.d (!116) When blanking of udev rules was first tested [1][2] and added [3] all the distributions at the time (CentOS 6, Debian 6, Fedora 19, openSUSE 12.2, Ubuntu 12.04 LTS) stored the system default rules in directory /lib/udev/rules.d. Now most distributions (CentOS Stream 9, Debian 11, Fedora 38, Ubuntu 22.04 LTS, openSUSE Leap 15.4) store the system default rules in directory /usr/lib/udev/rules.d. Most of these distributions have a merged /usr file system [4][5] so /lib is a symlink to /usr/lib and the system default rules can still found using the original directory. But openSUSE 15.4 doesn't have a merged /usr so the gparted shell wrapper doesn't find the system default rules in directory /usr/lib/udev/rules.d and doesn't prevent auto starting of Linux Software RAID arrays and bcache devices during a storage probe. An extra consideration is that Alpine Linux 3.17 doesn't have a merged /usr file system, but has both /lib/udev/rules.d and /usr/lib/udev/rules.d directories with different rules files. Therefore fix this by checking for system default udev rules in both directories. [1] Bug 709640 - Linux Swap Suspend and Software RAID partitions not recognised, comment 7 https://bugzilla.gnome.org/show_bug.cgi?id=709640#c7 [2] Bug 709640 - Linux Swap Suspend and Software RAID partitions not recognised, comment 12 https://bugzilla.gnome.org/show_bug.cgi?id=709640#c12 [3] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) [4] The Case for the /usr Merge http://0pointer.de/blog/projects/the-usr-merge [5] The Case for the /usr Merge https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ Closes !116 - Systemd mount masking and udev rule location updates 2023-08-02 Mike Fleetwood Avoid masking/unmasking the empty list of mount units (!116) After the previous commit "Stop masking the root file system mount unit", GParted now reports this error to the terminal on Debian 10 and 11: # gparted To few arguments. GParted 1.5.0-git configuration --enable-online-resize libparted 3.2 Debian installations, at least on PC hardware and using BIOS booting so they don't have a /boot/efi file system, only have a single file system, / (root). That is now excluded from masking so gparted shell wrapper runs systemctl without any mount units to mask. Hence the error. # systemctl --runtime mask --quiet -- Too few arguments. # echo $? 1 Fix this by only masking and unmasking units when the list of mounts is non-empty. Closes !116 - Systemd mount masking and udev rule location updates 2023-08-05 Mike Fleetwood Stop masking the root file system mount unit (!116) Masking the root file system (-.mount) unit lead to a Debian package upgrade failing as reported here [1]. This was fixed in systemd 245 [2][3] by not allowing perpetual units to be masked. As the root file system can't be mounted or unmounted while GParted is running, it doesn't need to be prevented by masking the unit. Therefore stop masking the root file system mount unit. [1] Debian bug #948710 - handle masked .mount unit more gracefully https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948710 [2] systemd issue #14550 - Handle masked .mount units more gracefully https://github.com/systemd/systemd/issues/14550 [3] core: never allow perpetual units to be masked https://github.com/systemd/systemd/commit/88414eed6f45f738ae765d9f72d67c6dc5a51950 Closes !116 - Systemd mount masking and udev rule location updates 2023-08-01 Mike Fleetwood Add fallback of removing systemd mount unit masks directly (!116) On RHEL / CentOS 8 GParted reports this error to the terminal when it is closed: # gparted GParted 1.5.0-git configuration --enable-online-resize libparted 3.2 >> --runtime cannot be used with unmask # $? 0 and leaves mount units masked: # systemctl list-units '*.mount' UNIT LOAD ACTIVE SUB DESCRIPTION ------------------------------------------------------------------ * -.mount masked active mounted Root Mount * boot.mount masked active mounted boot.mount ... This is because of this change [1] released in systemd 239. Systemd bug 9393 [2] was raised and the change was reverted [3] in systemd 240. According to repology.org only RHEL / CentOS 8 (and clones) and Fedora 29 shipped with systemd 239 [4]. Fix by detecting non-zero exit status from systemctl and falling back to directly removing the runtime mount unit mask files instead. Then have to use systemctl daemon-reload to inform systemd to reload it's configuration from disk to discover the masks have been removed. [1] systemctl: when removing enablement or mask symlinks, cover both /run and /etc https://github.com/systemd/systemd/commit/4910b35078ad24dcbc63f372b2fee087640201d0 [2] systemctl no longer allows unmask in combination with --runtime #9393 https://github.com/systemd/systemd/issues/9393 [3] Revert "systemctl: when removing enablement or mask symlinks, cover both /run and /etc" https://github.com/systemd/systemd/commit/1830ac51a4ad1d82a198e587207df451b581c821 [4] Versions for systemd https://repology.org/project/systemd/versions Closes !116 - Systemd mount masking and udev rule location updates 2023-07-25 Balázs Úr Update Hungarian translation 2023-07-15 Yosef Or Boczko Update Hebrew translation 2023-07-14 Jürgen Benvenuti Update German translation 2023-07-11 Sergej A Update Russian translation 2023-07-09 Kukuh Syafaat Update Indonesian translation 2023-07-02 Hugo Carvalho Update Portuguese translation 2023-06-29 Anders Jonsson Update Swedish translation 2023-06-25 Yuri Chornoivan Update Ukrainian translation 2023-06-25 Piotr Drąg Update Polish translation 2023-06-24 Ekaterine Papava Update Georgian translation 2023-06-24 Marcin Zepp Fix crash when dealing with 0000-0000 exfat UUID (!115) GParted crashes when blkid doesn't provide the UUID of the exfat partition and its serial has preceding zeroes (and it isn't mounted). blkid doesn't report UUID if the serial number is 0000-0000 (a.k.a. 0x0). Steps to reproduce: # truncate -s 4M /tmp/disk.img # losetup -f --show /tmp/disk.img /dev/loop0 # mkfs.exfat /dev/loop0 [...] exFAT format complete! # partprobe /dev/loop0 # blkid /dev/loop0 /dev/loop0: UUID="F7BF-ABFF" BLOCK_SIZE="512" TYPE="exfat" PTTYPE="dos" # exfatlabel /dev/loop0 -i 0x0 exfatprogs version : 1.1.3 New volume serial : 0x0 # blkid /dev/loop0 /dev/loop0: BLOCK_SIZE="512" TYPE="exfat" PTTYPE="dos" # gparted /dev/loop0 GParted 1.3.1 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.4 ** (gpartedbin:94926): ERROR **: 10:45:01.894: unhandled exception (type std::exception) in signal handler: what: basic_string::assign: __pos (which is 18446744073709551615) > this->size() (which is 3) Trace/breakpoint trap (core dumped) # losetup -d /dev/loop0; rm /tmp/disk.img As blkid doesn't report exfat UUID 0000-0000 FS_Info cache can't report it so exfat::read_uuid() is called. Then `tune.exfat -i /dev/loop0` is executed: # tune.exfat -i /dev/loop0 exfatprogs version : 1.1.3 volume serial : 0x0 And exfat::serial_to_blkid_uuid() is called with "0x0", which causes a crash. Fix by safely handling volume serial numbers of any length, specifically shorter than 8 hexadecimal digits. Closes !115 - Fix crash when dealing with 0000-0000 exfat UUID 2023-06-12 Mike Fleetwood Return constant reference from ProgressBar::get_text() get_text() only performs const access on the ProgressBar object so return the member string by constant reference. Previously done for other string returning getters, even though the value is assigned to a variable and doesn't save anything: 1f6e81295b5190a0a67daf9e85b4206faafb725e Return constant reference from OperationDetail::get_description() (!94) 2023-06-12 Mike Fleetwood Return const reference from OperationDetail::get_progressbar() The only use of the reference returned from OperationDetail::get_progressbar() is to call const methods ProgressBar::running(), ::get_fraction() and ::get_text(). Therefore make OperationDetail::get_progressbar() return a const reference. 2023-06-12 Mike Fleetwood Generate time remaining text for fraction complete progress bars As described in the previous commit "Clear progress bar text when starting the bar (#230)" progress bar data is either reporting bytes copied or fraction complete. The bytes copied case gets in progress text like this: 544.00 MiB of 1.00 GiB copied (00:00:11 remaining) But the fraction complete gets no text. Now also generate time remaining text for progress bars only reporting fraction complete. As with the bytes copied text only add the time remaining estimate after 5 seconds have passed. Looks like: (00:01:59 remaining) This is most useful for NTFS partition copy and resize operations which can take a while depending on the amount of data involved. 2023-06-12 Mike Fleetwood Clear progress bar text when starting it (#230) These operations use steps which generate progress bar bytes copied information text: * Partition move or copy using GParted's internal block copy * EXT2/3/4 partition move or copy * XFS partition copy The bytes copied text looks like this (after the copy completes and the time remaining is no longer included): 1.00 GiB of 1.00 GiB copied And these operations use steps which generate progress bar information without text (because the progress bar data only represents a fraction complete): * EXT2/3/4 partition resize * EXT2/3/4 partition create * EXT2/3/4 partition format * EXT2/3/4 partition check * NTFS partition resize * NTFS partition copy In the Applying pending operations dialog, while an operation is being applied there are 2 progress bars. The top progress bar displays either a pulse bar or the progress bar data for the current step. Additionally for the relevant steps the progress bar generates the bytes copied text. This text, when available, is displayed in small grey characters just above the progress bar itself. Copy a FAT partition and apply. Bytes copied text is displayed just above the top progress bar. Copy an NTFS partition and apply. The left behind bytes copied text from the previous operation is displayed, instead of nothing. Restart GParted and copy an NTFS partition and apply. As intended, this time there is no bytes copied text displayed just above the top progress bar. As there is just a single ProgressBar object, single_progressbar, fix this by clearing the progress bar text each time it is started. Closes #230 - Missing progress bar text reset when applying operation 2023-06-06 Olga Smirnova Add Interlingue translation 2023-05-26 Sabri Ünal Update Turkish translation 2023-05-13 Mike Fleetwood Also check links to block devices when skipping BlockSpecial unit tests (!113) Fragment of a failed CI test job from a GiLab job runner which didn't allow creation of block special devices looked like: $ tests/makedev.sh mknod -m 0660 /dev/sda b 8 0 mknod: '/dev/sda': Operation not permitted chown: cannot access '/dev/sda': No such file or directory mknod -m 0660 /dev/sda1 b 8 1 mknod: '/dev/sda1': Operation not permitted chown: cannot access '/dev/sda1': No such file or directory mkdir: created directory '/dev/disk' mkdir: created directory '/dev/disk/by-id/' '/dev/disk/by-id/gparted-sda' -> '/dev/sda' test/makedev.sh attempted to create two block devices it wanted for testing, but that failed with "Operation not permitted". It then created dangling symbolic link /dev/disk/by-id/gparted-sda -> /dev/sda; gparted-sda pointed to a name which didn't exist. Despite the previous commit testing and skipping every test where the block device doesn't exist this unit test still failed: [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches test_BlockSpecial.cc:186: Failure Failed follow_link_name(): Failed to resolve symbolic link '/dev/disk/by-id/gparted-sda' test_BlockSpecial.cc:271: Skip test. Block device '' does not exist [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms) The unit test called get_link_name() which read the directory /dev/disk/by-id and found symbolic link gparted-sda. It then called follow_link_name() passing /dev/disk/by-id/gparted-sda which used realpath(3) to get the canonicalised absolute pathname, which includes following links. But as gparted-sda pointed to a non-existent file it failed and reported message "Failed to resolve symbolic link ...". Then after that the unit test skips the non-existent block device, but the test has already failed at that point. Fix the unit test by also checking the symbolic link points to an existing block device before calling follow_link_name() on it. This works because SKIP_IF_BLOCK_DEVICE_DOESNT_EXIST() uses stat(3), which follows symbolic links, in it's verification. Also put SKIP_IF_BLOCK_DEVICE_DOESNT_EXIST() immediately after each initialisation of a block device name for some sort of consistency with it's need in this fixed NamedBlockSpecialObjectBySymlinkMatches unit test. Closed !113 - Fix occasional GitLab CI test jobs failures on BlockSpecial unit tests 2023-05-08 Mike Fleetwood Skip BlockSpecial unit tests when devices don't exist, for CI test images (!113) Since November 2022 test_BlockSpecial has been occasionally failing in GNOME GitLab Docker CI test jobs like this: [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice test_BlockSpecial.cc:216: Failure Value of: bs.m_major > 0 || bs.m_minor > 0 Actual: false Expected: true [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice (0 ms) ... [ RUN ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices test_BlockSpecial.cc:244: Failure Value of: bs1.m_major != bs2.m_major || bs1.m_minor != bs2.m_minor Actual: false Expected: true [ FAILED ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices (0 ms) [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches test_BlockSpecial.cc:170: Failure Failed follow_link_name(): Failed to resolve symbolic link '/dev/disk/by-id/gparted-sda' [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms) ... 3 FAILED TESTS FAIL test_BlockSpecial (exit status: 1) As identified previously [1] the Docker CI images no longer have any block devices in /dev. test/makedev.sh script was added to create block devices test_BlockSpecial needs for it's testing. Now a subset of the GNOME GitLab job runners additionally prevent creation of block special device nodes. test/makedev.sh reports this: $ tests/makedev.sh mknod -m 0660 /dev/sda b 8 0 mknod: /dev/sda: Operation not permitted chown: cannot access '/dev/sda': No such file or directory mknod -m 0660 /dev/sda1 b 8 1 mknod: /dev/sda1: Operation not permitted chown: cannot access '/dev/sda1': No such file or directory Alternative rejected solutions: 1. Use fakeroot [2]. Package is available for the 3 distributions used in CI jobs. Does fake stat() call. Works when run like this in the CI test jobs: fakeroot -s test/fakeroot.env tests/makedev.sh fakeroot -i test/fakeroot.env make check fakeroot -i test/fakeroot.env make distcheck But if you run fakeroot ... make check on our development machines as a non-root user it causes the test_SupportedFileSystems unit tests which use losetup to fail. This is because test_SupportedFileSystems thinks it's root inside the fakeroot environment but fakeroot doesn't fake enough for losetup to work. This makes running tests in the GitLab CI jobs different from how we would have to run them on our development machines. Prefer not to do that. 2. Use GNU ld --wrap [3] to call our own __wrap_stat() allowing test_BlockSpecial to provide mocked results to the stat() call in constructor BlockSpecial::BlockSpecial(). This works with GNU C Library >= 2.33, released 01-Feb-2021, and musl libc, therefore it works on CI tested distributions Ubuntu LTS >= 22.04 and Alpine Linux respectively. However this fails on earlier glibc releases, so will fail on CentOS 7 CI image, as the compiler emits a call to __xstat() rather than stat(). This is something to do with how glibc's /usr/include/sys/stat.h supported multiple versions of stat(). Don't use this as it's doesn't work everywhere. Additional useful implementation hints. [4][5] Choose to fix by just skipping unit tests which need block special names to exist in the file system, but don't exist. This is the same technique that test_SupportedFileSystems uses. So tests/makedev.sh creates block devices if it can in the GNOME GitLab CI test images [1] and now if that fails the individual unit tests are skipped. [1] 57983b9fc20c9367f9dd83a8301e903fced5329e Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59) [2] FakeRoot https://wiki.debian.org/FakeRoot [3] ld(1) - Linux manual page https://man7.org/linux/man-pages/man1/ld.1.html "--wrap=symbol Use a wrapper function for symbol. Any undefined reference to symbol will be resolved to "__wrap_symbol". Any undefined reference to "__real_symbol" will be resolved to symbol. This can be used to provide a wrapper for a system function. The wrapper function should be called "__wrap_symbol". If it wishes to call the system function, it should call "__real_symbol". ... " [4] gcc: error: unrecognized option --wrap https://stackoverflow.com/questions/33278164/gcc-error-unrecognized-option-wrap [5] C++ ld linker --wrap option does not work for internal function calls https://stackoverflow.com/questions/44464961/c-ld-linker-wrap-option-does-not-work-for-internal-function-calls Closed !113 - Fix occasional GitLab CI test jobs failures on BlockSpecial unit tests 2023-05-08 Mike Fleetwood Cat /proc/partitions and list /dev in GitLab CI test jobs (!113) Add these simple debugging aids to the GNOME GitLab CI test job. They've been needed before [1] so add them permanently. [1] 57983b9fc20c9367f9dd83a8301e903fced5329e Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59) "Contents of /proc/partitions inside the Docker image when this test CI job failed: ... And the listing of /dev/: " Closed !113 - Fix occasional GitLab CI test jobs failures on BlockSpecial unit tests 2023-05-11 Mike Fleetwood Stick with Alpine Linux 3.17 in the GitLab CI images Alpine Linux just released new docker image 3.18, updating latest from 3.17 [1], which causes the GNOME GitLab CI jobs to fail like this: $ apk add gnome-common yelp-tools automake autoconf glib-dev libtool g++ parted-dev gtkmm3-dev itstool make git polkit-dev ERROR: unable to select packages: gnome-common (no such package): required by: world[gnome-common] Based on this blog [2] I printed the apk repository configuration file in Alpine Linux 3.17 and 3.18 docker images in GitLab CI jobs and found this contents: Alpine Linux 3.17 $ cat /etc/apk/repositories https://dl-cdn.alpinelinux.org/alpine/v3.17/main https://dl-cdn.alpinelinux.org/alpine/v3.17/community Alpine Linux 3.18 $ cat /etc/apk/repositories https://dl-cdn.alpinelinux.org/alpine/v3.18/main https://dl-cdn.alpinelinux.org/alpine/v3.18/community So what I conclude is that the packages GParted needs aren't yet available or being distributed for Alpine Linux 3.18. Therefore fix this by explicitly sticking with Alpine Linux 3.17. [1] Alpine docker images https://hub.docker.com/_/alpine/ * 3.18.0, 3.18, 3, latest https://github.com/alpinelinux/docker-alpine/blob/571516c7ce3ecec3c70541d13529a4abb33ba362/x86_64/Dockerfile Committed 2023-May-09 [2] ERROR: unable to select packages error on Alpine Linux https://www.hasanaltin.com/error-unable-to-select-packages-error-on-alpine-linux/ 2023-04-28 Boyuan Yang <073plan@gmail.com> Update Chinese (China) translation 2020-04-05 Mike Fleetwood Briefly comment STAT_* enumerators 2020-04-05 Mike Fleetwood Remove superfluous STAT_FORMATTED STAT_FORMATTED is only used inside snap_to_mebibyte() to suppress enforcement that partition boundaries must not overlay the MBR or EBRs when merely formatting existing partitions. However since commit [1], snap_to_mebibyte() is only called inside the dialogs composing Create New, Copy / Paste into New and Resize / Move operations and never when composing a Format operation or any other operation which doesn't change partition boundaries. Therefore remove STAT_FORMATTED. [1] 7c94b7d92060ef7b14be115edb95d6720186f75e Snap partition boundaries before dialogs update FS usage (#48) 2020-04-20 Mike Fleetwood Fix available space calculation in Dialog_Partition_New::set_data() The available number of sectors 'total_length' is calculated as one sector too few. However this doesn't matter because when composing a new partition in Dialog_Partition_New::Get_New_Partition() the dialog fits the end of the partition to the end of the unallocated partition 'new_partition->sector_end' in which it is being created, not the available space. Missed in earlier commit: 4f84cff781b6c2a1a9f8dd6d8438acddfb0fe5a0 cleanups Anyway correct the calculation. 2020-04-05 Mike Fleetwood Remove unnecessary portion of MiB alignment check As a partition's position is completely defined by it's starting and ending sector, it is aligned if both boundaries are aligned. The size of a partition just depends on the starting and ending sector. Therefore it is never necessary to also check if the size of the partition is also an exact multiple of MiB. Remove this unnecessary portion of the alignment check when resizing/moving a partition (or copy/pasting into a new partition). 2023-04-20 Mike Fleetwood Remove now duplicated Win_GParted::display_partitions member (#227) Now Win_GParted::m_display_device.partitions is an identical copy of Win_GParted::display_partitions with the same lifetime. That's wasteful and pointless. Therefore remove the later and use the former in it's place. Closes #227 - Unable to allocate 1 MiB between partitions when moving to the right 2023-04-19 Mike Fleetwood Use current Device object for Create and Paste dialogs too (#227) The Create New and Paste dialogs also create partitions and have to honour currently composed partitions while doing so. Therefore they must have a Device object containing the currently composed partition layout for passing into snap_to_alignment() and below. So copy the current Device object when refreshing the visual at the same time visual_partitions is generated and use in all 3 dialogs which compose new partitions. Note that Create New and Paste aren't subject to the same bug as Resize/ Move was because the code in snap_to_mebibyte() [1] checked the partition object being composed has status STAT_REAL. This is true for partition objects created by the Resize/Move dialog, but not true for the Create New and Paste dialogs which set status to STAT_NEW and STAT_COPY respectively instead. [1] Dialog_Base_Partition::snap_to_mebibyte() lines 418 to 438 https://gitlab.gnome.org/GNOME/gparted/-/blob/GPARTED_1_5_0/src/Dialog_Base_Partition.cc#L418 Closes #227 - Unable to allocate 1 MiB between partitions when moving to the right 2023-04-17 Mike Fleetwood Stop forcing 1 MiB gap when moving common partition boundary to the right (#227) Start with 2 partitions next to each other, containing file systems that GParted can move and resize. EG: |[#1 ext2 ][#2 swap ] | Move the start of partition #2 to the right. Then attempt to move the end of partition #1 to the right to meet it. EG: |[#1 ext2 ][#2 swap ] | The Resize/Move dialog will allow the free space following to be set to 0 so partition #1 is again adjacent to partition #2, but after closing the dialog a forced 1 MiB gap is added, shrinking the composed size of partition #1 by that 1 MiB. If instead the first operation to shrink and move partition #2 is applied, then partition #1 can be successfully resize right up to partition #2 without a 1 MiB gap. Relevant call sequence: Win_GParted::activate_resize() Dialog_Partition_Resize_Move::Dialog_Partition_Resize_Move() Dialog_Base_Partition::Get_New_Partition() prepare_new_partition() snap_to_alignment() snap_to_mebibyte() prepare_new_partition() created a new partition object to correctly represent the resized/moved partition #1. However this code in snap_to_mebibyte() [1] determined that the new location for partition #1 overlapped with where partition #2 currently is on disk, not where partition #2 will be after the previous operation is applied, therefore it forced a 1 MiB decrease in partition #1's size creating the gap. This is because snap_to_mebibyte() is working with the on disk view of the partitions obtained from devices[current_device] passed into the Dialog_Partition_Resize_Move() constructor. Hence why applying the operations one at a time doesn't suffer from the forced 1 MiB gap. Fix this by creating a copy of the current device object, replacing the on disk partition layout with the composed partition layout as displayed in the UI. Then pass this into the Dialog_Partition_Resize_Move constructor. [1] Dialog_Base_Partition::snap_to_mebibyte() lines 418 to 438 https://gitlab.gnome.org/GNOME/gparted/-/blob/GPARTED_1_5_0/src/Dialog_Base_Partition.cc#L418 Closes #227 - Unable to allocate 1 MiB between partitions when moving to the right 2023-04-09 Asier Sarasua Garmendia Update Basque translation 2023-03-12 Sabri Ünal Update Turkish translation 2023-03-07 Fabio Tomat Update Friulian translation 2023-02-28 Balázs Úr Update Hungarian translation 2023-02-26 Aurimas Černius Update Lithuanian translation 2023-02-26 Fabio Tomat Update Friulian translation 2023-02-24 Dušan Kazik Update Slovak translation 2023-02-21 Curtis Gedak Append -git to version for continuing development 2023-02-21 Curtis Gedak ========== gparted-1.5.0 ========== 2023-02-21 Curtis Gedak Update copyright years 2023-02-08 Mike Fleetwood Resolve compiler warning from gen_password() More recent g++ versions produce these warnings: test_PasswordRAMStore.cc: In member function ‘virtual void GParted::PasswordRAMStoreTest_TotalErasure_Test::TestBody()’: test_PasswordRAMStore.cc:61:32: warning: ‘ ’ directive output truncated writing 20 bytes into a region of size 10 [-Wformat-truncation=] snprintf( buf, sizeof( buf ), "password%03u ", i ); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test_PasswordRAMStore.cc:61:10: note: ‘snprintf’ output 32 bytes into a destination of size 21 snprintf( buf, sizeof( buf ), "password%03u ", i ); ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ snprintf() [1] truncates the printed string to the specified size so didn't overflow the buffer. However clear the warning by making the formatted string always exactly 20 characters long, followed by the terminating NUL character to exactly fill the buffer. [1] print3(f) - Linux manual page https://man7.org/linux/man-pages/man3/snprintf.3.html "The functions snprintf() and vsnprintf() write at most size bytes (including the terminating null byte ('\0')) to str. " 2023-02-07 Mike Fleetwood Use Automake noinst_HEADERS to list GParted header files Using Automake variable EXTRA_DIST [1] to list the GParted header files seems overly general. Instead use noinst_HEADERS [2] as it better describes GParted header files. Header files which need to be distributed in the archive, but not part of an installed library so not to be installed below /usr/include. [1] GNU Automake manual, 14.1 Basics of Distribution https://www.gnu.org/software/automake/manual/html_node/Basics-of-Distribution.html "..., it is still common to have files to be distributed which are not found by the automatic rules. You should listed these files in the EXTRA_DIST variable. You can mention files in subdirectories in EXTRA_DIST. " [2] GNU Automake manual, 9.2 Header files https://www.gnu.org/software/automake/manual/html_node/Headers.html "Usually, only header files that accompany installed libraries need to be installed. Headers used by programs or convenience libraries are not installed. The noinst_HEADERS variable can be used for such headers. However, when the header belongs to a single convenience library or program, we recommend listing it in the program's or library's _SOURCES variable (see Defining program sources) instead of in noinst_HEADERS. This is clearer for the Makefile.am reader. noinst_HEADERS would be the right variable to use in a directory containing only headers and no associated library or program. All header files must be listed somewhere; in a _SOURCES variable or in a _HEADERS variable. Missing ones will not appear in the distribution. " 2023-02-03 Mike Fleetwood Replace fragment of unit test code with trim_trailing_new_line() 2016-12-18 Mike Fleetwood Use libparted geometry to bound writing in erase_filesystem_signatures() The code in erase_filesystem_signatures() used libparted ped_device_write() which allowed any sector in the whole disk device to be written. The code only depended on calculations of somewhat complicated zero offset ranges and the start partition offset to ensure that it didn't zero sectors outside the target partition. The code doesn't overwrite partition boundaries, but there have been updates and bug fixes to the calculation code. To improve the safety create a libparted geometry representing the partition, or whole disk device, to be cleared and use ped_geometry_write() so that libparted enforces writes are only within the partition boundary being erased. Deliberately breaking erase_filesystem_signatures() code so that it tries to write past the end of the partition produces this dialog: Libparted Error (-) Attempt to write sectors 1024000-1024007 outside of partition on /dev/sdb. [ Cancel ] [ Ignore ] And trying to write before the start of the partition produces this dialog: Libparted Bug (-) Assert (offset >= 0) at cs/geom.c:375 in function ped_geometry_write() failed. [ No ] Followed by GParted aborting and producing a core dump. Not ideal from libparted, but it does prevent GParted writing outside the partition boundaries and only occurs in the case of a bug in erase_filesystem_signatures() which is exercised on every Create and Format Partition operation and now also unit tested. So not something we will let through to the users. 2023-02-05 Mike Fleetwood Add unit test of erasing Promise FastTrack RAID signatures (#220) Since the previous commit "Also erase all Promise FastTrack RAID signatures" the previous failing IntelSoftwareRAIDUnaligned test now passes along with the new PromiseFastTrackRaid* tests. $ ./test_EraseFileSystemSignatures Running main() from test_EraseFileSystemSignatures.cc DISPLAY=":0.0" [==========] Running 4 tests from 1 test case. [----------] Global test environment set-up. [----------] 4 tests from EraseFileSystemSignaturesTest [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned (158 ms) [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned (81 ms) [ RUN ] EraseFileSystemSignaturesTest.PromiseFastTrackRAIDAligned [ OK ] EraseFileSystemSignaturesTest.PromiseFastTrackRAIDAligned (74 ms) [ RUN ] EraseFileSystemSignaturesTest.PromiseFastTrackRAIDUnaligned [ OK ] EraseFileSystemSignaturesTest.PromiseFastTrackRAIDUnaligned (74 ms) [----------] 4 tests from EraseFileSystemSignaturesTest (387 ms total) [----------] Global test environment tear-down [==========] 4 tests from 1 test case ran. (387 ms total) [ PASSED ] 4 tests. Closes #220 - Format to Cleared not clearing "pdc" ataraid signature 2023-01-22 Mike Fleetwood Also erase all Promise FastTrack RAID signatures (#220) User reported that GParted didn't clear a pdc (Promise FastTrack) RAID signature [1]. Reproduce this issue by creating a 16 MiB - 512 byte test image with Promise FastTrack RAID signatures at all recognised offsets [2]. $ python << 'EOF' signature = b'Promise Technology, Inc.' import os fd = os.open('/tmp/test.img', os.O_CREAT|os.O_WRONLY) os.ftruncate(fd, 16*1024*1024 - 512) for offset in [63, 255, 256, 16, 399, 591, 675, 735, 911, 974, 991, 951, 3087]: os.lseek(fd, -(offset*512), os.SEEK_END) os.write(fd, signature) os.close(fd) EOF Then use GParted Format to > Cleared. $ sudo ./gpartedbin /tmp/test.img Afterwards blkid, and therefore GParted, still recognises this as a Promise FastTrack RAID member. $ blkid /tmp/test.img /tmp/test.img: TYPE="promise_fasttrack_raid_member" This is because the test image still contains multiple signatures. $ hexdump -C /tmp/test.img | grep Promise 00e7e000 50 72 6f 6d 69 73 65 20 54 65 63 ... |Promise Technolo| 00fce000 50 72 6f 6d 69 73 65 20 54 65 63 ... |Promise Technolo| 00fdfe00 50 72 6f 6d 69 73 65 20 54 65 63 ... |Promise Technolo| 00ff8000 50 72 6f 6d 69 73 65 20 54 65 63 ... |Promise Technolo| Used a test image not an exact multiple of MiBs because drives generally aren't an exact MiB multiple in size either and as the clearing of ZFS labels L2 and L3 by writes of zeros at the end of the drive is rounded to 256 KiBs there will be sectors after that not zeroed where other Promise signatures remain. The above signatures map back to these sectors before the end: 16*1024*1024 - 512 = 16776704 512b sectors KiB (0x00e7e000 - 16776704) / 512 = -3087 -1543.5 (0x00fce000 - 16776704) / 512 = -399 -199.5 (0x00fdfe00 - 16776704) / 512 = -256 -128 (0x00ff8000 - 16776704) / 512 = -63 -31.5 Promise FastTrack RAID signatures are always at multiples 512-byte sectors (code uses left shift 9 to convert from sectors to byte offset) [2]. Fix this by: 1. Replace existing zeroing of 3 ranges relative to the end of the device to be a single range covering the ZFS labels L2 and L3 to the end of the drive. This will also clear the SWRaid 0.90 & 1.0 super blocks, the Nilfs2 secondary super block, the Intel Software RAID signature found not zeroed in the unaligned unit test case and the above Promise FastTrack RAID signatures at -199.5 KiB and later. 2. Add zeroing of the final Promise FastTrack RAID signature at sector -3087. Performed a review of all the other ATARAID super blocks detected by blkid (files *_raid.c) [3] and they are all located within the last 11 sectors so will be zeroed by case 1. above. [1] GParted forum thread: How to remove a ataraid partition ? http://gparted-forum.surf4.info/viewtopic.php?id=18104 [2] blkid from util-linux promise_raid.c:probe_pdcraid() https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libblkid/src/superblocks/promise_raid.c?h=v2.38.1#n27 [3] blkid RAID member detection (files *_raid.c) https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libblkid/src/superblocks/?h=v2.38.1 Closes #220 - Format to Cleared not clearing "pdc" ataraid signature 2023-02-08 Mike Fleetwood Speed up signature erasing unit test in Alpine Linux CI test job (#220) Each test in test_EraseFileSystemSignatures is taking just over 10 seconds to run in the Alpine Linux CI image: [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned (10045 ms) [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned ... [ FAILED ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned (10048 ms) [----------] 2 tests from EraseFileSystemSignaturesTest (20093 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test case ran. (20093 ms total) This is because the udevadm command is not found and so settle_device() waits for 10 seconds in this call chain: erase_filesystem_signatures() settle_device(SETTLE_DEVICE_APPLY_MAX_WAIT_SECONDS) sleep(10) Install udevadm command into the Alpine Linux CI job docker image to fix this. Now it's on a par with the time taken in the other distro CI test jobs: [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned (417 ms) [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned ... [ FAILED ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned (165 ms) [----------] 2 tests from EraseFileSystemSignaturesTest (582 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test case ran. (582 ms total) Closes #220 - Format to Cleared not clearing "pdc" ataraid signature 2023-02-05 Mike Fleetwood Move duplicated test code into shared modules (#220) Move common testing code which doesn't need linking with GParted objects into the common module. Move the remaining common code used to print GParted objects using the insertion operator (operator<<) into the insertion_operators module. Split the common code like this so that the operator<<(std::ostream&, const OperationDetail&) function is not included in test_PipeCapture and it is not forced to link with all the non-UI related GParted objects. The Automake manual provides guidance that when a header belongs to a single program it is recommended to be listed in the program's _SOURCES variable and for a directory only containing header files listing them in the noinst_HEADERS variable is the right variable to use [1]. However the guidance doesn't cover this case for common.h and insertion_operators.h; header files in a directory with other files and used by multiple programs. So just because we have gparted_core_OBJECTS (normal Makefile, not Automake special variable) listing objects to link with, choose to use noinst_HEADERS Automake variable to list needed headers. [1] GNU Automake manual, 9.2 Header files https://www.gnu.org/software/automake/manual/html_node/Headers.html "Usually, only header files that accompany installed libraries need to be installed. Headers used by programs or convenience libraries are not installed. The noinst_HEADERS variable can be used for such headers. However, when the header belongs to a single convenience library or program, we recommend listing it in the program's or library's _SOURCES variable (see Defining program sources) instead of in noinst_HEADERS. This is clearer for the Makefile.am reader. noinst_HEADERS would be the right variable to use in a directory containing only headers and no associated library or program. All header files must be listed somewhere; in a _SOURCES variable or in a _HEADERS variable. Missing ones will not appear in the distribution. " Closes #220 - Format to Cleared not clearing "pdc" ataraid signature 2023-02-04 Mike Fleetwood Add initial unit test of erase_filesystem_signatures() (#220) Initially just testing erasing of Intel Software RAID signatures. Chosen because it was expected to work, but turned out not to be true in all cases. The code needs to initialise GParted_Core::mainthread, construct Gtk::Main() and execute xvfb-run because of this call chain: GParted_Core::erase_filesystem_signatures() GParted_Core::settle_device() Utils::execute_command ("udevadm settle ...") status.foreground = (Glib::Thread::self() == GParted_Core::mainthread) Gtk::Main::run() This was also needed when testing file system interface classes as discussed in commits [1][2]. The test fails like this: $ ./test_EraseFileSystemSignatures ... [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned (155 ms) [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned test_EraseFileSystemSignatures.cc:286: Failure Failed image_contains_all_zeros(): First non-zero bytes: 0x00001A00 "Intel Raid ISM C" 49 6E 74 65 6C 20 52 61 69 64 20 49 53 4D 20 43 test_EraseFileSystemSignatures.cc:320: Failure Value of: image_contains_all_zeros() Actual: false Expected: true [ FAILED ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned (92 ms) Manually write the same test image: $ python << 'EOF' signature = b'Intel Raid ISM Cfg Sig. ' import os fd = os.open('/tmp/test.img', os.O_CREAT|os.O_WRONLY) os.ftruncate(fd, 16*1024*1024 - 512) os.lseek(fd, -(2*512), os.SEEK_END) os.write(fd, signature) os.close(fd) EOF Run gpartedbin /tmp/test.img and Format to > Cleared. GParted continues to display the the image file as containing an ataraid signature. $ blkid /tmp/test.img /tmp/test.img: TYPE="isw_raid_member" $ hexdump -C /tmp/test.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00fffa00 49 6e 74 65 6c 20 52 61 69 64 20 49 53 4d 20 43 |Intel Raid ISM C| 00fffa10 66 67 20 53 69 67 2e 20 00 00 00 00 00 00 00 00 |fg Sig. ........| 00fffa20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00fffe00 This signature is not being cleared when the device/partition/image size is 512 bytes smaller than a whole MiB because the last 3.5 KiB is left unwritten. This is because the last block of zeros written is 8 KiB aligned to 4 KiB at the end of the device. [1] a97c23c57c693b77724970d2f99702d7be18b4bc Add initial create ext2 only FileSystem interface class test (!49) [2] 8db9a83b39b82785dcbcc776ac259aa7986c0955 Run test program under xvfb-run to satisfy need for an X11 display (!49) Closes #220 - Format to Cleared not clearing "pdc" ataraid signature 2023-01-29 Jordi Mas i Hernandez Update Catalan translation 2023-01-13 Goran Vidović Update Croatian translation 2023-01-09 Alan Mortensen Update Danish translation 2023-01-05 Seong-ho Cho Update Korean translation 2022-12-28 Enrico Nicoletto Update Brazilian Portuguese translation 2022-12-21 Mike Fleetwood Increase minimum XFS size to 300 MiB (#217) As documented in the previous commit xfsprogs >= 5.19.0 refuses to create an XFS file system smaller than 300 MiB. $ truncate -s $((300*1024*1024-1)) test.img $ ls -l test.img -rw-r--r-- 1 auser auser 314572799 Dec 21 11:01 test.img $ mkfs.xfs -V mkfs.xfs version 6.0.0 $ mkfs.xfs test.img Filesystem must be larger than 300MB. ... $ echo $? 1 Successfully create an XFS file system at minimum size of 300 MiB. $ truncate -s $((300*1024*1024)) test.img $ ls -l test.img -rw-r--r-- 1 auser auser 314572800 Dec 21 11:05 test.img $ mkfs.xfs test.img ... $ echo $? 0 $ blkid test.img test.img: UUID="..." BLOCK_SIZE="512" TYPE="xfs" Increase the GParted minimum XFS size to 300 MiB. For simplicity and because the XFS developers said of smaller XFS file systems [1]: "are known to have performance and redundancy problems that are not present on the volume sizes that XFS is best at handling" regardless of the version of mkfs.xfs used to create that XFS then apply to all versions of xfsprogs. [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=6e0ed3d19c54603f0f7d628ea04b550151d8a262 mkfs: stop allowing tiny filesystems Closes #217 - GitLab CI test job failing with new mkfs.xfs error "Filesystem must be larger than 300MB." 2022-12-21 Mike Fleetwood Increase minimum unit test FS image size to 320 MiB (#217) From 27-Nov-2022 the alpine_test GitLab CI job started failing, reporting errors creating XFS file systems in the test_SupportedFileSystems unit test like this: [ RUN ] My/SupportedFileSystemsTest.Create/xfs test_SupportedFileSystems.cc:501: Failure Value of: m_fs_object->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.xfs -f -L '' '/builds/GNOME/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (ERROR) Filesystem must be larger than 300MB. ... This is because Docker image "alpine:latest" has updated to Alpine Linux 3.17 which includes xfsprogs 6.0.0 which includes this change (first released in xfsprogs 5.19.0): https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=6e0ed3d19c54603f0f7d628ea04b550151d8a262 mkfs: stop allowing tiny filesystems Refuse to format a filesystem that are "too small", because these configurations are known to have performance and redundancy problems that are not present on the volume sizes that XFS is best at handling. Specifically, this means that we won't allow logs smaller than 64MB, we won't allow single-AG filesystems, and we won't allow volumes smaller than 300MB. Increase the default unit test file system image size from 256 MiB to 256+64 = 320 MiB to avoid this error. Closes #217 - GitLab CI test job failing with new mkfs.xfs error "Filesystem must be larger than 300MB." 2022-12-19 Mike Fleetwood Enable repair when checking exfat file systems (!109) GParted's check operation is a check and if possible repair. For most file system types GParted already requests that the file system is repaired. fsck.exfat -y flag has been available since the first release of exfatprogs 1.0.1 [1] so unconditionally add this. [1] exfatprogs 1.0.1 fsck/fsck.c:main() case 'y': https://github.com/exfatprogs/exfatprogs/blob/1.0.1/fsck/fsck.c#L1231 !109 - Enable repair when checking exfat file systems 2022-12-20 Aleksandr Melman Update Russian translation 2022-12-01 Hugo Carvalho Update Portuguese translation 2022-11-28 Anders Jonsson Update Swedish translation 2022-11-27 Yaron Shahrabani Update Hebrew translation 2022-11-27 Andika Triwidada Update Indonesian translation 2022-11-20 Yuri Chornoivan Update Ukrainian translation 2022-11-20 Zurab Kargareteli Update Georgian translation 2022-11-20 Jürgen Benvenuti Update German translation 2022-11-20 Piotr Drąg Update Polish translation 2022-11-20 Jürgen Benvenuti Update German translation 2022-11-19 Yuri Chornoivan Update Ukrainian translation 2022-11-13 Mike Fleetwood Rewrite GParted_Core::update_bootsector() (#164) The code was overly complicated in how it converted to the 32-bit little endian on-disk representation of the Hidden Sectors field. It did: 1. Formatted the partition start sector as a hexadecimal string. 2. Padded it to 8 digits. 3. Reversed pairs of digits. 4. Converted pairs of hexadecimal digits to bytes of binary data. 5. Wrote the 4 bytes of binary data to the Hidden Sectors field. There is no need for all this string manipulation to convert to a 32-bit little endian value. Just do this: 1. Truncate (signed 64-bit) partition start sector to 32-bit. 2. Convert from host native to little endian. 3. Write as 4 bytes of binary data to the Hidden Sectors field. The code also ignores write errors. ofstream.write() only copies the data into an in process buffer [1] and the data is not passed to the OS to write to the open file handle until ofstream.close() [2] is called. However the status of close() was not checked so a failure of the OS to perform the write would go unreported. In the case of a failure providing the user with a command line to set the Hidden Sectors field is excessive. Updating the Hidden Sectors is no more or less likely to fail than for any other storage manipulation action. For example GParted doesn't provide command line instructions to update a partition size if a libparted call fails. Therefore remove. Rewrite the code to resolve the above issues and lay it out using if-operation-fails-return-early pattern. [1] std::ostream::write() "... it inserts characters into associated stream_buffer object as if calling its member function sputc until n characters have been written or until an insertion fails ..." https://cplusplus.com/reference/ostream/ostream/write/ [2] std::ofstream::close() "Any pending output sequence is written to the file." https://cplusplus.com/reference/fstream/ofstream/close/ Closes #164 - GParted crashes copying NTFS partition to starting beyond 2TiB 2022-11-12 Mike Fleetwood Fix crash when copying NTFS to starting beyond 2 TiB (#164) Create test setup using a 4 TiB loop device: # truncate -s 4T /tmp/disk.img # losetup -f --show /tmp/disk.img /dev/loop0 Create 2 x 1 TiB partitions. First at offset 1 MiB, second at offset 2 TiB: # sgdisk --new 1:2048:2147485696 --typecode 1:0700 /dev/loop0 # sgdisk --new 2:4294967296:6442450944 --typecode 2:0700 /dev/loop0 # partprobe /dev/loop0 Create NTFS file system in the first partition: # mkntfs -Q /dev/loop0p1 Then use GParted to copy the first NTFS partition into the second partition. GParted crashes: # gpartedbin /dev/loop0 ... (gpartedbin:14660): glibmm-ERROR **: 20:39:01.191: unhandled exception (type std::exception) in signal handler: what: basic_string::_M_replace_aux Trace/breakpoint trap # echo $? 133 Overview of what is happening is that GParted_Core::update_bootsector() is attempting to set the Hidden Sectors [1] field in the NTFS Partition Boot Sector (PBS) to the start sector of the newly copied /dev/loop0p2 partition. But the sector number is greater than will fit in a 32-bit unsigned integer, which the code doesn't handle. Specifically the code prints the sector number as a hexadecimal number into string 'hex'. As the target partition starts at exactly 2 TiB then hex="100000000" (9 hexadecimal digits long). Next: hex.insert(0, 8 - hex.length(), '0'); is meant to pad the beginning of the 'hex' string with '0's to make the string 8 character long. But the string is already 9 character long so 8 - 9 is -1 which as unsigned integral type size_t [2] is 2^64-1. So insert() is trying to insert 18446744073709551615 '0's at the start of the 'hex' string! Hence the crash. mkntfs refuses to accept an explicit partition start sector of 2^32 or larger: # mkntfs -Q --partition-start 4294967296 /dev/loop0p2 Invalid partition start sector. Maximum is 4294967295 (2^32-1). # echo $? 1 When mkntfs can't determine the drive geometry and partition offset, as is the case on loop devices or the partition start sector is 2^32 or larger, then mkntfs writes zero into Hidden Sectors: # mkntfs -Q /dev/loop0p1 The partition start sector was not specified for /dev/loop0p1 and it could not be obtained automatically. It has been set to 0. ... To boot from a device, Windows needs the 'partition start sector', ... Windows will not be able to boot from this device. Creating NTFS volume structures. mkntfs completed successfully. Have a nice day. # echo $? 0 # hexdump -C /dev/loop0p1 | head -2 00000000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....| 00000010 00 00 00 00 00 f8 00 00 00 00 00 00 00 00 00 00 |................| ^^ ^^ ^^ ^^ Hidden Sectors value at offset 0x1C in the NTFS Partition Boot Sector. So mkntfs is warning, writing the Hidden Sectors as zero and reporting success. Fix GParted in an equivalent way when it is updating the Hidden Sectors for a moved or copied NTFS which starts at sector 2^32 and beyond. After this fix the operational details for the same copy operation are: Copy /dev/loop0p1 to /dev/loop0p2 * calibrate /dev/loop0p1 (SUCCESS) * calibrate /dev/loop0p2 (SUCCESS) * set partition type on /dev/loop0p2 (SUCCESS) * copy file system from /dev/loop0p1 to /dev/loop0p2 (SUCCESS) * update boot sector of ntfs file system on /dev/loop0p2 (WARNING) Partition start (4294967296) is beyond sector 4294967295 (2^32-1). Windows will not be able to boot from this file system. * check file system on /dev/loop0p2 for errors and if p... (SUCCESS) [1] NTFS, Partition Boot Sector (PBS) " Byte Field Field name Purpose offset length 0x1C 5 bytes Hidden Sectors The number of sectors preceding the partition. " https://en.wikipedia.org/wiki/NTFS#Partition_Boot_Sector_(PBS) [2] std::string::insert "fill (5) string& insert(size_t pos, size_t n, char c); Insert into string Inserts additional characters into the string right before the character indicated by pos (or p): (5) fill Insert n consecutive copies of character c. " https://cplusplus.com/reference/string/string/insert/ Closes #164 - GParted crashes copying NTFS partition to starting beyond 2TiB 2022-09-23 Mike Fleetwood Remove mention of devkit-disks from README Missed at the time by commit: ddb334705efa4c340c33b64ce8e5eefada3deb31 Remove support for obsolete devkit-disks automount inhibitor 2022-09-23 Mike Fleetwood Update README for intltool to gettext migration (!107) Remove mention of intltool as it's now unused. Add polkit to the list of dependencies to build GParted from source as gettext always explicitly translates the org.gnome.gparted.policy file. Add polkit-devel and gettext-devel packages to the packages needing installing on various distributions to get the gettext translation rules for .policy files and the autopoint build tool installed. (Distributions such as Debian and Ubuntu split the packages differently. Gettext translation rules for .policy files are in the base policykit-1 package and the autopoint tool is in the autopoint package which I assume is always installed as part of the development tool set. Hence no change to the command to install dependent packages on these distributions. See the earlier commit messages for more details). Closes !107 - Migrate from intltool to gettext translation 2022-09-19 Mike Fleetwood Update .gitignore for intltool to gettext translation migration (!107) Remove no longer needed intltool related ignores. Add extra ignores for direct use of gettext for translation. ABOUT-NLS and most of the po/* files are copied during autogen. autogen.sh -> gnome-autogen.sh -> autoreconf -> autopoint extracts these from gettext's archive of application support files /usr/share/gettext/archive.*. Looks like this: $ ./autogen.sh ... Processing ./configure.ac Running autoreconf... autoreconf: Entering directory `.' autoreconf: running: autopoint --force Copying file ABOUT-NLS ... Copying file po/Makefile.in.in Copying file po/Makevars.template Copying file po/Rules-quot Copying file po/boldquot.sed Copying file po/en@boldquot.header Copying file po/en@quot.header Copying file po/insert-header.sin Copying file po/quot.sed Copying file po/remove-potcdate.sin And these files are created by make in the po directory: po/gparted.pot po/remove-potcdate.sed Closes !107 - Migrate from intltool to gettext translation 2022-11-06 Mike Fleetwood Revert workaround for .intltool-merge-cache.lock file being left behind (!107) Now that intltool is no longer used, the workaround for it leaving file .intltool-merge-cache.lock behind is no longer needed. Therefore revert merge !103 "Fix make distcheck failure found in GitLab CI job unbuntu_test". This commit reverts both of these earlier commits in one go: 053691378c6cc3d153dc32b4d75da50f901e0062 Resolve messages from configure in VPATH build (!103) 0bd636a34b945469d8644464518f78b9f9e1e92d Fix up intltool leaving .intltool-merge-cache.lock file behind (!103) Closes !107 - Migrate from intltool to gettext translation 2022-09-23 Mike Fleetwood Stop installing intltool package into Alpine and CentOS CI images (!107) ... as the GParted build no longer uses it. (Intltool is not explicitly installed into the Ubuntu CI image). However removing intltool from the GitLab CentOS Continuous Integration image causes the build job to fail like this: $ ./autogen.sh ... **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. Processing ./configure.ac Running autoreconf... autoreconf: Entering directory `.' autoreconf: running: autopoint --force Can't exec "autopoint": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 345. autoreconf: failed to run autopoint: No such file or directory autoreconf: autopoint is needed because this package uses Gettext This is because on CentOS 7 autopoint is provided by the gettext-devel package which was installed as a requirement for intltool. Fix the build by explicitly installing the package. (On Alpine Linux the gettext-dev package is automatically installed and on Ubuntu the autopoint package is automatically installed so those CI images don't need to explicitly include the relevant package). Closes !107 - Migrate from intltool to gettext translation 2022-09-11 Mike Fleetwood Fix .policy file translation failure in CentOS CI image (!107) Build in CentOS 7 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]: *** [org.gnome.gparted.policy] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/builds/mfleetwo/gparted' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builds/mfleetwo/gparted' make: *** [all] Error 2 As with Alpine Linux fixed in the previous commit, CentOS doesn't install the needed rules files by default. Add polkit-devel package to CentOS CI image to fix this. Closes !107 - Migrate from intltool to gettext translation 2022-09-11 Mike Fleetwood Fix .policy file translation failure in Alpine Linux CI image (!107) In the Alpine Linux 3.16 CI build job, file org.gnome.gparted.policy is not translated with this warning: $ make -j $nproc ... /usr/bin/xgettext: warning: a fallback ITS rule file '/usr/share/gettext-0.21/its/metainfo.its' is used; it may not be in sync with the upstream /usr/bin/xgettext: warning: file 'org.gnome.gparted.policy.in.in' extension 'policy' is unknown; will try C In my Alpine Linux 3.15 VM building GParted fails like this: $ make ... make[2]: Entering directory '/home/alpine/programming/c/gparted' sed -e 's,[@]libexecdir[@],/usr/local/libexec,g' -e 's,[@]bindir[@],/usr/local/bin,g' -e 's,[@]gksuprog[@],pkexec --disable-internal-agent,g' -e 's,[@]enable_xhost_root[@],no,g' < ./org.gnome.gparted.policy.in.in > org.gnome.gparted.policy.in /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:1059: org.gnome.gparted.policy] Error 1 make[2]: Leaving directory '/home/alpine/programming/c/gparted' make[1]: *** [Makefile:617: all-recursive] Error 1 make[1]: Leaving directory '/home/alpine/programming/c/gparted' make: *** [Makefile:451: all] Error 2 This is because gettext's msgfmt doesn't have rules for what elements to translate in .policy XML files. Add polkit-dev package to Alpine Linux CI image to provide these files: /usr/share/gettext/its/policy.its /usr/share/gettext/its/policy.loc Now the .policy file is translated successfully: $ make ... make[2]: Entering directory '/home/alpine/programming/c/gparted' /usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy make[2]: Leaving directory '/home/alpine/programming/c/gparted' Closes !107 - Migrate from intltool to gettext translation 2022-09-11 Mike Fleetwood Install git into Alpine CI image to fix autopoint error (!107) Alpine Linux build CI job fails like this: $ ./autogen.sh ... Running autoreconf... autoreconf: export WARNINGS=no-portability autoreconf: Entering directory '.' autoreconf: running: autopoint --force autopoint: *** git program not found autopoint: *** Stop. autoreconf: error: autopoint failed with exit status: 1 This is because gettext's autopoint command in Alpine Linux is built with a git archive of application support files: $ autopoint --version /usr/bin/autopoint (GNU gettext-tools) 0.21 Uses a versions archive in git format. ... $ ls -l /usr/share/gettext/archive* -rw-r--r-- 1 root root 752320 Jan 14 2021 /usr/share/gettext/archive.git.tar.gz Where as for other distributions gettext's autopoint command uses plain compressed tar archive, for example in Ubuntu 22.04 LTS: $ autopoint --version /usr/bin/autopoint (GNU gettext-tools) 0.21 Uses a versions archive in dirxz format. ... $ ls -l /usr/share/gettext/archive* -rw-r--r-- 1 root root 407064 Mar 25 10:31 /usr/share/gettext/archive.dir.tar.xz Fix by adding git to the packages installed into the Alpine Linux CI docker image. Closes !107 - Migrate from intltool to gettext translation 2022-08-26 Mike Fleetwood Migrate build from intltool to gettext translation (!107) [0] GNOME Goal: Gettext Migration https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration This goal from 2016 is to migrate away from using intltool to help translate especially GNOME application related files, and instead use gettext directly now that gettext can handle a lot more file formats [1][2][3]. The GNOME Goal: Gettext Migration [0] says: "With gettext 0.19.8, there is really no need anymore to use intltool or GLib's dated gettext glue (AM_GLIB_GNU_GETTEXT and glib-gettextize)." This version or later of gettext is available in the oldest supported distributions except for SLES 12: Distribution EOL gettext -V Debian 10 2022-Aug 0.19.8.1 RHEL / CentOS 7 2024-Jun 0.19.8.1 Ubuntu 18.04 LTS 2023-Apr 0.19.8.1 SLES 12 SP5 2024-Oct 0.19.2 [4][5] As SLES 12 SP5 doesn't contain GParted and SLES 15 contains GParted 0.31.0 [6] loosing the ability to compile future GParted 1.5 release on SLES 12 SP5 is acceptable. Additionally the use of intltool and the associated GLib provided macro AM_GLIB_GNU_GETTEXT was the source of the remaining warnings from autoconf 2.71 seen in Fedora 36 and Ubuntu 22.04 LTS about the use of obsolete macros: $ ./autogen.sh ... autoreconf: running: /usr/bin/autoconf --force configure.ac:59: warning: The macro `GLIB_GNU_GETTEXT' is obsolete. configure.ac:59: You should run autoupdate. aclocal.m4:426: GLIB_GNU_GETTEXT is expanded from... >> aclocal.m4:526: AM_GLIB_GNU_GETTEXT is expanded from... >> configure.ac:59: the top level configure.ac:59: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:59: You should run autoupdate. ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from... lib/m4sugar/m4sh.m4:699: AS_IF is expanded from... ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from... ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from... aclocal.m4:111: GLIB_LC_MESSAGES is expanded from... aclocal.m4:426: GLIB_GNU_GETTEXT is expanded from... >> aclocal.m4:526: AM_GLIB_GNU_GETTEXT is expanded from... >> configure.ac:59: the top level configure.ac:59: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:59: You should run autoupdate. ... Note that use of AM_GLIB_GNU_GETTEXT was deprecated in GLib 2.47.5 released 2016-01-18 [7]. Newer versions of GLib are included in the oldest supported distributions: Distro Package containing Version glib-gettext.m4 Debian 10 libglib2.0-dev-bin 2.58.3 RHEL / CentOS 7 glib2-devel 2.56.1 Ubuntu 18.04 LTS libglib2.0-dev-bin 2.56.4 SLES 12 SP5 glib2-devel 2.48.2 Therefore perform the migration described in the GNOME wiki documents [0][1]. This involves: 1. Replacing the macros used in configure.ac; 2. Copying Makevars.template to po/Makevars and setting PO_DEPENDS_ON_POT and DIST_DEPENDS_ON_UPDATE_PO to "no"; 3. Replace @INTLTOOL_*@ macros in Makefile.am with rules to use gettext to directly translate the relevent GNOME application files; 4. Removing (_) underscore marking translation prefixes from XML tags in GNOME application files as gettext understands which tags of which files need translating. For reference are these commits in projects GNOME-System-Monitor [8], Reversi [9] and Evince [10] making the same transition. At this point "./autogen.sh && make" succeeds, at least on Ubuntu which provides the instructions gettext needs to correctly translate .policy files by default. These: /usr/share/gettext/its/polkit.its /usr/share/gettext/its/polkit.loc are included in the base policykit-1 package. [1] Migrating from Intltool to Gettext https://wiki.gnome.org/MigratingFromIntltoolToGettext [2] Using Modern Gettext https://blogs.gnome.org/mclasen/2016/07/21/using-modern-gettext/ [3] On the killing of intltool https://blogs.gnome.org/mcatanzaro/2016/07/27/on-the-killing-of-intltool/ [4] SUSE package search, SLES 12 SP5, gettext https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=12.5&arch=x86_64&query=gettext&module= [5] SUSE Long Term Service Pack Support https://links.imagerelay.com/cdn/3404/ql/f3a083e9bcd34c76addd096d7f60ec00/long_term_service_pack_support_flyer.pdf [6] SUSE package search, SLES 15, gparted https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=15&arch=x86_64&query=gparted&module= [7] Deprecate GLIB_GNU_GETTEXT macro, use upstream gettext instead https://gitlab.gnome.org/GNOME/glib/-/commit/6b577196eed0754d2805fd48caa64f58f9bb8ee4 [8] [GNOME-System-Monitor] Migrate from intltool https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/commit/9185b9c713980391a6f1a2377eb5ea249a0df182 [9] [Reversi] Gettext migration (bgo#793040) https://gitlab.gnome.org/GNOME/iagno/-/commit/d22f560ac80d0ded2cb3a38cb10a65e17ead3850 [10] [Evince] build: Migrate from Intltool to Gettext https://gitlab.gnome.org/GNOME/evince/-/commit/4fd682132430feb8c012e4b0aa0c2c5da5ffe5ac Closes !107 - Migrate from intltool to gettext translation 2022-10-09 Dušan Kazik Update Slovak translation 2022-09-22 Matej Urbančič Update Slovenian translation 2022-09-20 Alan Mortensen Update Danish translation 2022-09-17 Irénée THIRION Update French translation 2022-09-14 Kukuh Syafaat Update Indonesian translation 2022-09-13 Luna Jernberg Update Swedish translation 2022-06-04 Mike Fleetwood Update AC_PROG_LIBTOOL to LT_INIT in configure.ac (!106) Autoconf 2.71 on Fedora 36 and Ubuntu 22.04 LTS has started reporting a number of warnings about configure.ac containing obsolete macros. One of them is this: $ ./autogen.sh ... Processing ./configure.ac configure.ac:17: warning: The macro `AC_PROG_LIBTOOL' is obsolete. configure.ac:17: You should run autoupdate. m4/libtool.m4:99: AC_PROG_LIBTOOL is expanded from... configure.ac:17: the top level ... AC_PROG_LIBTOOL is deprecated and the replacement is LT_INIT [1]. LT_INIT is available in all supported distributions, for example RHEL / CentOS 7 has libtool 2.4.2 with LT_INIT defined in /usr/share/aclocal/libtool.m4 serial 57. The last known distribution without LT_INIT was RHEL / CentOS 5 [2]. Update accordingly. [1] Libtool Manual, 5.4.1 The LT_INIT macro https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html "Macro: LT_INIT(options) ... AC_PROG_LIBTOOL and AM_PROG_LIBTOOL are deprecated names for older versions of this macro; autoupdate will upgrade your configure.ac files." [2] 654cdc7335beda48f0da095a1d06e91870d9ac76 Update AM_PROG_LIBTOOL to AC_PROG_LIBTOOL in configure.ac (#734718) Closes !106 - Update AC_PROG_LIBTOOL to LT_INIT in configure.ac 2022-09-11 Yosef Or Boczko Update Hebrew translation 2022-09-08 Muhammet Kara Update Turkish translation 2022-09-03 Sabri Ünal Update Turkish translation 2022-08-29 Balázs Úr Update Hungarian translation 2022-07-01 Mike Fleetwood Use apt to install packages on Debian and related distros Apt is the modern recommended command to use when installing packages these days on Debian and related distributions [1][2][3]. Convert the Ubuntu GitLab CI jobs and update the README accordingly. [1] What is the difference between apt and apt-get? https://askubuntu.com/questions/445384/what-is-the-difference-between-apt-and-apt-get [2] Difference Between apt and apt-get Explained https://itsfoss.com/apt-vs-apt-get-difference/ [2] Apt and Apt-get - Which One to Use https://linoxide.com/apt-and-apt-get-which-one-to-use/ 2022-07-04 Mike Fleetwood Automate exclusion of loop device tests from CI image (!105) Avoid having to manually maintain the list of excluded File System tests in the GitLab Docker CI image. Scan the unit test source extracting those tests marked with SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS() to automatically construct the setting for the GTEST_FILTER environment variable. Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-08-10 Mike Fleetwood Allow execution of more btrfs CI unit tests (!105) Now that reading btrfs usage, UUID and label can be performed on a file system image remove the need for a loop device for the relevant unit tests. Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-07-27 Mike Fleetwood Use btrfs inspect-internal dump-super to read usage (!105) GParted has been using 'btrfs filesystem show' to report file system usage but that doesn't work on a file system image so doesn't work in a GitLab CI test job, as discussed earlier in this patchset. There is 'btrfs inspect-internal min-dev-size' but: 1. That only works on a mounted file system and GParted isn't going to mount an unmounted file system just to query it's used space, so by extension won't work on image files. 2. It reports a figure which is almost the same as the chunk usage of the device within the btrfs file system. However if some files have been deleted leaving chunks partially used, then 'btrfs filesystem resize' will successfully shrink a btrfs smaller than the reported minimum device size. And there is also 'btrfs filesystem usage' but that also only works on a mounted file system. So instead use 'btrfs inspect-internal dump-super' to report some of the figures previously obtained from 'btrfs filesystem show'. For example for a single device btrfs in an image file: $ truncate -s 256M /tmp/test.img $ mkfs.btrfs /tmp/test.img $ btrfs inspect-internal dump-super /tmp/test.img | egrep 'total_bytes|bytes_used|sectorsize|devid' total_bytes 268435456 bytes_used 114688 sectorsize 4096 dev_item.total_bytes 268435456 dev_item.bytes_used 92274688 dev_item.devid 1 Comparing with results from 'btrfs filesystem show' for the same file system, after adding a loop device to allow 'btrfs filesystem show' to succeed: $ su - # losetup --find --show /tmp/test.img # btrfs filesystem show --raw /dev/loop0 Label: none uuid: 32a1eb31-4691-41ae-9ede-c45d723655a3 Total devices 1 FS bytes used 114688 devid 1 size 268435456 used 92274688 path /dev/loop0 This does bring a forced change in the calculation which affects multi- device btrfs file systems. 'btrfs filesystem show' provided chunk allocation information per device ("used" figure for each "devid"). The file system wide used bytes ("FS bytes used") was apportioned according to the fraction of the chunk allocation each device contained. However 'btrfs inspect-internal dump-super' doesn't provide chunk allocation information for all devices, only for the current device ("dev_item.bytes_used"). Instead the calculation now has to apportion the file system wide used bytes ("bytes_used") according to the fraction of the size of the current device ("dev_item.total_bytes") within the total size ("total_bytes"). This can't make any difference to a single device btrfs file system as both fractions will be 1. It only affects how the file system wide used bytes is distributed among multiple devices. As an example to see the difference between calculation methods, create a 2 GiB btrfs taking the defaults so getting duplicated metadata and single data. Add another 2 GiB partition and populate with some files. # mkfs.btrfs /dev/sdb1 btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Label: (null) UUID: 68195e7e-c13f-4095-945f-675af4b1a451 Node size: 16384 Sector size: 4096 Filesystem size: 2.00GiB Block group profiles: Data: single 8.00MiB Metadata: DUP 102.38MiB System: DUP 8.00MiB SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: ID SIZE PATH 1 2.00GiB /dev/sdb1 # mount /dev/sdb1 /mnt/1 # btrfs device add /dev/sdc1 /mnt/1 # cp -a /home/$USER/programming/c/gparted/ /mnt/1/ Usage figures using the old calculation apportioning file system wide usage according to chunk allocation per device: # btrfs filesystem show --raw /dev/sdb1 Label: none uuid: 68195e7e-c13f-4095-945f-675af4b1a451 Total devices 2 FS bytes used 178749440 devid 1 size 2147483648 used 239861760 path /dev/sdb1 devid 2 size 2147483648 used 436207616 path /dev/sdc1 sum_devid_used = 239861760 + 436207616 = 676069376 sdb1 usage = 178749440 * 239861760 / 676069376 = 63418277 sdc1 usage = 178749440 * 436207616 / 676069376 = 115331163 Usage figures using the new calculation apportioning file system wide usage according to device sizes: # btrfs inspect-internal dump-super /dev/sdb1 | egrep 'total_bytes|^bytes_used' total_bytes 4294967296 bytes_used 178749440 dev_item.total_bytes 2147483648 # btrfs inspect-internal dump-super /dev/sdc1 | egrep 'total_bytes|^bytes_used' total_bytes 4294967296 bytes_used 178749440 dev_item.total_bytes 2147483648 sdb1 usage = 178749440 * 2147483648 / 4294967296 = 89374720 sdc1 usage = 178749440 * 2147483648 / 4294967296 = 89374720 Both calculation methods ignore that btrfs allocates chunks at the volume manager level. So when fully compacted the last chunk for metadata and data for each storage profile (RAID level) will be partially filled and this is not accounted for. Also for multi-device btrfs file systems the new calculation provides different results. However given that shrinking a device in a multi- device btrfs file system can and does relocate extents to other devices (redundancy requirements of chunks permitting) it's minimum size is virtually impossible to calculate and may not restrict how small the btrfs device can be shrunk anyway. If it turns out that this new calculation causes problems it's been made a separate commit from the previous commit for easier reverting. Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-07-25 Mike Fleetwood Use btrfs filesystem show --raw to read usage (!105) 'btrfs filesystem show' only used to report rounded human readable size figures. Therefore the actual figure could have been anywhere within the rounding limit. GParted also applied a heuristic to snap the file system size figure to the partition size if the partition size was within the rounding limit of the reported file system size [1]. btrfs-progs v4.1 added the --raw option to print the figures in bytes [2][3][4]. # btrfs filesystem show --raw /dev/sdb1 Label: none uuid: 003a619e-856f-4b9c-bd29-4d0ae0296d66 Total devices 2 FS bytes used 178765824 devid 1 size 2147483648 used 239861760 path /dev/sdb1 devid 2 size 2147483648 used 436207616 path /dev/sdc1 Since the oldest supported distributions now use btrfs-progs v4.5.3 and later (see the distribution End-of-Life table in the previous commit message), unconditionally use this to get accurate figures. [1] 7fc16a1b6905f7f2d6876d317c4757ff09cdd57c Handle btrfs tools rounding of figures (#499202) [2] btrfs-progs: Allow "filesystem show" command to handle different units https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=15379fa2257bf937cf7830c0b1b79f2daf5df72c [3] btrfs-progs: docs: new size options for fi show https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=81225f11d9ea58590476612e69211113ddb9b943 [4] Btrfs progs release 4.1 https://lore.kernel.org/linux-btrfs/20150622150023.GX6761@twin.jikos.cz/ Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-07-22 Mike Fleetwood Use btrfs inspect-internal dump-super to read UUID (!105) GParted so far uses 'btrfs filesystem show' to read the file system UUID. But this doesn't work on a file system image so doesn't work in the GitLab CI test jobs, as discussed in the earlier commit "Use btrfs filesystem label to read the FS label (!105)". $ truncate -s 256M /tmp/test.img $ mkfs.btrfs /tmp/test.img ... UUID: 5ea62f88-fef3-4ece-a726-b88f3d81fe1c ... $ btrfs filesystem show /tmp/test.img ERROR: not a valid btrfs filesystem: /tmp/test.img Instead use 'btrfs inspect-internal dump-super' which works on image files too. $ btrfs inspect-internal dump-super /tmp/test.img ... fsid 5ea62f88-fef3-4ece-a726-b88f3d81fe1c ... 'btrfs inspect-internal dump-super' was added in btrfs-progs 4.5 [1][2] so is available in the oldest supported distributions and can be used unconditionally. Distro EOL btrfs --version Debian 10 2022-Jun v4.20 RHEL / CentOS 7 2024-Jun v4.9.1 Ubuntu 18.04 LTS 2023-Apr v4.15.1 SLES 12 SP5 2024-Oct v4.5.3 [3][4] Unfortunately it returns 0 status on failure so use non-empty stderr to identify failure. $ rm /tmp/test.img $ truncate -s 256M /tmp/test.img $ btrfs inspect-internal dump-super /tmp/test.img 1> /dev/null ERROR: bad magic on superblock on /tmp/test.img at 65536 $ echo $? 0 [1] btrfs-progs: introduce inspect-internal dump-super https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=eaa93e3b0295fc94c774ec73056559a6b8c78b42 [2] Btrfs progs release 4.5 https://lore.kernel.org/linux-btrfs/20160320235330.GG21722@suse.cz/ "* new/moved commands * btrfs-show-super -> btrfs inspect-internal dump-super " [3] SUSE Long Term Service Pack Support https://links.imagerelay.com/cdn/3404/ql/f3a083e9bcd34c76addd096d7f60ec00/long_term_service_pack_support_flyer.pdf [4] SUSE package search https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=12.5&arch=x86_64&query=btrfsprogs&module= Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-08-12 Mike Fleetwood Extract repeated code into trim_trailing_new_line() (!105) Create function to replace repeated code which optionally removes trailing new line character from a string. Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-07-22 Mike Fleetwood Use btrfs filesystem label to read the FS label (!105) Until now GParted has run 'btrfs filesystem show' to read the file system label. This has a number of issues and limitations: 1. Doesn't work on a file system image so can't be unit tested in the GitLab CI test job where a loop device can't be created [1] or as a non-root user. 2. Reported failed exit status 1 when successfully showing a mounted btrfs, but only when using btrfs-progs v3.14 and 3.14.1 [2][3]. 3. Failed to distinguish between label set to "none" and no label reported as none, but only when mounted and with btrfs-progs v3.12 [3]. As non-root user run btrfs read label unit test: $ tests/test_SupportedFileSystems --gtest_filter='*CreateAndReadLabel/btrfs' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs test_SupportedFileSystem.cc:539: Skip test. Not root to be able to create required loop device [ OK ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs (0 ms) Even as root, 'btrfs filesystem show' fails to work on an image file: # truncate -s 256M /tmp/test.img # mkfs.btrfs /tmp/test.img # btrfs filesystem show /tmp/test.img ERROR: not a valid btrfs filesystem: /tmp/test.img # echo $? 1 # rm /tmp/test.img Instead use 'btrfs filesystem label' to read the label. It also works on an image file, the exit status is informative and output is just the label followed by a new line character [4] so very simple to parse. Error case: $ truncate -s 256M /tmp/test.img $ btrfs filesystem label /tmp/test.img No valid Btrfs found on /tmp/test.img $ echo $? 255 No label case: $ mkfs.btrfs /tmp/test.img $ btrfs filesystem label /tmp/test.img $ echo $? 0 $ btrfs filesystem label /tmp/test.img | hexdump -C 00000000 0a |.| 00000001 Label case: $ mkfs.btrfs -L 'label with > new line and trailing space ' /tmp/test.img $ btrfs filesystem label /tmp/test.img label with new line and trailing space $ echo $? 0 $ btrfs filesystem label /tmp/test.img | hexdump -C 00000000 6c 61 62 65 6c 20 77 69 74 68 0a 6e 65 77 20 6c |label with.new l| 00000010 69 6e 65 20 61 6e 64 20 74 72 61 69 6c 69 6e 67 |ine and trailing| 00000020 20 73 70 61 63 65 20 0a | space .| 00000028 Run 'btrfs filesystem label' always passing the block device as this works for both mounted and unmounted file systems. This is in contrast to writing the label for a mounted btrfs where the mount mount must be used [5]. # mkfs.btrfs -L 'test label' /dev/sdb1 # btrfs filesystem label /dev/sdb1 test label # mount /dev/sdb1 /mnt/1 # btrfs filesystem label /dev/sdb1 test label [1] 07ad43a1072a104543bfc45bc5d357f3d8f8d6f6 Create loop devices for BTRFS read file system interface tests (!49) [2] 82c6265fa5599bd5acfe33abecaa99de150d71e9 Update parsing of btrfs filesystem show for the UUID (#733601) [3] eca732fb0cefe35db76a7ac96145e2004e8eed08 Update parsing of btrfs filesystem show for the label (#733601) [4] btrfs-progs v3.14, cmd_label() function https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/tree/cmds-filesystem.c?h=v3.14#n984 [5] eb034b17597713bbc08dd3ab90444eaa2c0e7ff5 Add labelling of mounted btrfs (#163) Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5 2022-08-13 Goran Vidović Update Croatian translation 2022-06-20 Mike Fleetwood Fix typo in comment in xfs::write_label() 2022-07-01 Mike Fleetwood Add unit testing of GParted exFAT interface to ubuntu_test CI job Now that the docker image for ubuntu:latest has updated to Ubuntu 22.04 LTS [1] and exfatprogs is available [2] add the package to the CI job to include it in the testing. [1] Ubuntu Docker official image https://hub.docker.com/_/ubuntu/ "Supported tags and respective Dockerfile links ... 22.04, ..., latest, ... " [2] Ubuntu > Packages > jammy (22.04LTS) > otherosfs > exfatprogs https://packages.ubuntu.com/jammy/exfatprogs [3] 3783cb41732264b12b6ccd9cf6a9f36e1c2a4241 Add unit testing of GParted exFAT interface (!30) 2022-06-20 Mike Fleetwood Add clearing FS label to CreateAndWriteLabel unit test For FAT16/32 and XFS file systems clearing the label uses different command options and code path in file system specific ::write_label() method. Therefore extend this unit test to also test clearing the label. 2022-07-01 Mike Fleetwood Stop clearing FAT16/32 label when setting a new UUID (!104) Now fix the error with GParted clearing the label when setting a new UUID on a FAT16/32 file system. Reproduce the issue on the command line: # mkfs.fat -F 16 -v -I -n TEST_LABEL /dev/sdb1 # mdir -f -i /dev/sdb1 ::/ Volume in drive : is TEST_LABEL Volume Serial Number is 5D4C-6E6E ... # mlabel -n -i /dev/sdb1 :: # mdir -f -i /dev/sdb1 ::/ Volume in drive : has no label Volume Serial Number is 77BB-A883 ... This was broken by commit "Fix writing FAT16/32 FS UUID on Alpine Linux (!104)" earlier in this patchset, which included this comment: "... Also drop the '-s' option as showing the current label is unrelated to writing a new UUID." It is not mentioned in the mlabel[1] manual page that option -s is needed in order to avoid clearing the label when assigning a new UUID. Anyway add the option back. [1] mlabel(1) https://linux.die.net/man/1/mlabel "s Shows the existing label, without prompting the user. n Assigns a new (random) serial number to the disk " Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-07-01 Mike Fleetwood Add CreateAndWriteUUIDAndReadLabel unit test (!104) During review and testing of this patchset it was discovered that using GParted to set a new UUID on a FAT16 or FAT32 file system that there was a new unwanted side effect of clearing the label. Add unit test to cover this error scenario. It does the following: 1. Creates a file system with a known label; 2. Writes a new UUID; 3. Reads the label and confirms it matches the initial label. This new unit test captures the fault like this: $ ./test_SupportedFileSystems --gtest_filter='*CreateAndWriteUUIDAndReadLabel*' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat16 test_SupportedFileSystems.cc:645: Failure Expected equality of these values: fs_label Which is: "TEST_LABEL" m_partition.get_filesystem_label().c_str() Which is: "" [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat16, where GetParam() = 13 (21 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat32 test_SupportedFileSystems.cc:645: Failure Expected equality of these values: fs_label Which is: "TEST_LABEL" m_partition.get_filesystem_label().c_str() Which is: "" [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat32, where GetParam() = 14 (22 ms) Don't forget to exclude this unit test for file systems which need a loop device but which fails to be created inside the docker CI image. Reference: 39fdfe51da4bddecb2c99a9b544b270130423e72 Exclude unit tests needing losetup in Docker CI image (!59) Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-19 Mike Fleetwood Fix make distcheck in Alpine Linux CI test job (!104) The make distcheck step of the CI test job fails like this on Alpine Linux: $ make distcheck ... make[1]: Leaving directory '/home/alpine/programming/c/gparted' if test -d "gparted-1.4.0-git"; then find "gparted-1.4.0-git" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "gparted-1.4.0-git" || { sleep 5 && rm -rf "gparted-1.4.0-git"; }; else :; fi case 'gparted-1.4.0-git.tar.gz' in \ *.tar.gz*) \ eval GZIP= gzip --best -dc gparted-1.4.0-git.tar.gz | ${TAR-tar} xf - ;;\ *.tar.bz2*) \ bzip2 -dc gparted-1.4.0-git.tar.bz2 | ${TAR-tar} xf - ;;\ *.tar.lz*) \ lzip -dc gparted-1.4.0-git.tar.lz | ${TAR-tar} xf - ;;\ *.tar.xz*) \ xz -dc gparted-1.4.0-git.tar.xz | ${TAR-tar} xf - ;;\ *.tar.Z*) \ uncompress -c gparted-1.4.0-git.tar.Z | ${TAR-tar} xf - ;;\ *.shar.gz*) \ eval GZIP= gzip --best -dc gparted-1.4.0-git.shar.gz | unshar ;;\ *.zip*) \ unzip gparted-1.4.0-git.zip ;;\ *.tar.zst*) \ zstd -dc gparted-1.4.0-git.tar.zst | ${TAR-tar} xf - ;;\ esac gzip: unrecognized option: best BusyBox v1.35.0 (2022-05-09 17:27:12 UTC) multi-call binary. Usage: gzip [-cfkdt123456789] [FILE]... Compress FILEs (or stdin) -1..9 Compression level -d Decompress -c Write to stdout -f Force -k Keep input files -t Test integrity tar: short read make: *** [Makefile:844: distcheck] Error 1 Busybox gzip is erroring because it doesn't make sense to request best compression when decompressing to stdout in this command: eval GZIP= gzip --best -dc gparted-1.4.0-git.tar.gz | ${TAR-tar} xf - Fix by installing the GNU gzip package into Alpine Linux test CI job docker image. Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-19 Mike Fleetwood Fix writing FAT16/32 FS UUID on Alpine Linux (!104) Unit test writing FAT16/32 file system UUIDs fails on Alpine Linux like this: $ ./test_SupportedFileSystems --gtest_filter='*CreateAndWriteUUID/fat16' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteUUID/fat16 test_SupportedFileSystems.cc:616: Failure Value of: m_fs_object->write_uuid(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.fat -F16 -v -I '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (SUCCESS) ... mlabel -s -n :: -i '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (ERROR) Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteUUID/fat16, where GetParam() = 13 (38 ms) Using GParted on Alpine Linux to perform the same action produces the same error in the operation results. Reproduce this on the command line: # mkfs.fat -F 16 -v -I /dev/sdb1 # mlabel -s -n :: -i /dev/sdb1 Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: # echo $? 1 Again fix the same way, by moving the non-option '::' drive specification to the end of the command line. Also drop the '-s' option as showing the current label is unrelated to writing a new UUID. # mdir -f -i /dev/sdb1 ::/ | grep 'Volume Serial Number is' Volume Serial Number is B97E-59A3 # mlabel -n -i /dev/sdb1 :: # echo $? 0 # mdir -f -i /dev/sdb1 ::/ | grep 'Volume Serial Number is' Volume Serial Number is 1552-96A6 Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-18 Mike Fleetwood Fix reading FAT16/32 FS UUID on Alpine Linux (!104) Unit test reading FAT16/32 file system UUIDs fails on Alpine Linux like this: $ ./test_SupportedFileSystems --gtest_filter='*CreateAndReadUUID/fat16' .... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16 test_SupportedFileSystems.cc:581: Failure Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9 test_SupportedFileSystems.cc:584: Failure Value of: m_partition.get_messages().empty() Actual: false Expected: true Partition messages: Drive '::' not supported Cannot initialize '::' Drive 'A:' not supported Cannot initialize 'A:' Drive 'A:' not supported Cannot initialize 'A:' [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16, where GetParam() = 13 (28 ms) This doesn't normally affect GParted because it uses blkid as first choice to read file system UUIDs, only using file system specific commands when blkid isn't available. Reproduce this on the command line: # mkfs.fat -F 16 -v -I /dev/sdb1 # mdir -f :: -i /dev/sdb1 Drive '::' not supported Cannot initialize '::' Drive 'A:' not supported Cannot initialize 'A:' Drive 'A:' not supported Cannot initialize 'A:' Again, this is caused by having non-option '::' drive specification before all the options on the mdir command line, which isn't supported by the POSIX strict getopt(3) on Alpine Linux. Apply the same fix of moving the non-option argument to the end. # mdir -f -i /dev/sdb1 ::/ Volume is drive : has no label Volume Serial Number is 7DC9-BCD9 Director for ::/ No files # echo $? 0 Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-18 Mike Fleetwood Refactor fat16::read_uuid() into if fail return early pattern (!104) Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-17 Mike Fleetwood Fix writing FAT16/32 FS labels on Alpine Linux (!104) Unit test writing FAT16/32 file system labels fails on Alpine Linux like this: $ ./test_SupportedFileSystems --gtest_filter='*CreateAndWriteLabel/fat16' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteLabel/fat16 test_SupportedFileSystems.cc:601: Failure Value of: m_fs_object->write_label(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.fat -F16 -v -I -n 'FIRST ' '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (SUCCESS) ... mlabel ::'SECOND ' -i '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (ERROR) Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteLabel/fat16, where GetParam() = 13 (29 ms) Using GParted on Alpine Linux to perform the same action produces the same error in the operation results. Reproduce this on the command line: # mkfs.fat -F 16 -v -I -n FIRST /dev/sdb1 # mlabel ::SECOND -i /dev/sdb1 Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: # echo $? 1 Again, this is because musl libc's getopt(3) is POSIX compliant and stops parsing options at '::', the first non-option argument. Apply the same fix of moving the non-option argument to the end of the mlabel command line: # mlabel -i /dev/sdb1 ::SECOND # echo $? 0 # mlabel -s -i /dev/sdb1 Volume label is SECOND And for the clearing label case: # mlabel -c -i /dev/sdb1 :: # echo $? 0 # mlabel -s -i /dev/sdb1 Volume has no label Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-17 Mike Fleetwood Fix reading FAT16/32 FS labels on Alpine Linux (!104) Several of the FAT16/32 file system unit tests fail on Alpine Linux. In this commit we are just looking at the failure to read the label. The test fails like this: $ ./test_SupportedFileSystems --gtest_filter='*CreateAndReadLabel/fat16' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadLabel/fat16 test_SupportedFileSystems.cc:551: Failure Expected equality of these values: fs_label Which is: "TEST_LABEL" m_partition.get_filesystem_label().c_str() Which is: "" test_SupportedFileSystems.cc:554: Failure Value of: m_partition.get_messages().empty() Actual: false Expected: true Partition messages: Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/fat16, where GetParam() = 13 (21 ms) The same error can be seen by using GParted to display a FAT16 or FAT32 file system on Alpine Linux. The Partition Information dialog displays this warning: Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: Reproduce this on the command line: # mkfs.fat -F 16 -v -I -n TEST_LABEL /dev/sdb1 # mlabel -s :: -i /dev/sdb1 Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: # echo $? 1 The mlabel.c source [1] uses getopt(3) to parse the command line arguments. musl libc's [2] getopt(3) must be strictly POSIX compliant [3][4] and stops reading options at the first non-option argument, '::' in this case. Move the non-option argument to the end of the command line and it works: # mlabel -s -i /dev/sdb1 :: Volume label is TEST_LABEL Where as GNU Libc's getopt(3) [5] says that by default it reorders argv eventually moving all non-option arguments to the end, hence why this has worked on every Linux distribution using GNU Libc. This can be broken on any Linux distribution using GNU Libc by enforcing strict POSIX behaviour from getopt(3). For example on Fedora 36: # mkfs.fat -F 16 -v -I -n TEST_LABEL /dev/sdb1 # export POSIXLY_CORRECT=1 # mlabel -s :: -i /dev/sdb1 Mtools version 4.0.39, dated April 10th, 2022 Usage: mlabel [-vscVn] [-N serial] drive: # echo $? 1 # mlabel -s -i /dev/sdb1 :: Hidden (2048) does not match sectors (63) Volume label is TEST_LABEL # echo $? 0 Fix by moving the non-option (image file drive specification) '::' to the end of the mlabel command line. [1] Mtools https://www.gnu.org/software/mtools/ [2] musl libc https://musl.libc.org/ "musl is an implementation of the C standard library built on top of the Linux system call API, including interfaces defined in the base language standard, POSIX, and widely agreed-upon extensions. " [3] POSIX.1-2017, Functions, getopt https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html [4] getopt(3p) https://man7.org/linux/man-pages/man3/getopt.3p.html [5] getopt(3) https://www.man7.org/linux/man-pages/man3/getopt.3.html "By default, getopt() permutes the contents of argv as it scans, so that eventually all the nonoptions are at the end. Two other scanning modes are also implemented. If the first character of optstring is '+' or the environment variable POSIXLY_CORRECT is set, then option processing stops as soon as a nonoption argument is encountered. " Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-17 Mike Fleetwood Refactor fat16::read_label() into if fail return early pattern (!104) Follows the "Return Early" design pattern making the code easier to understand without having to remember cases for elses or cascading ifs. Refactor before the following commit's fix so that capture of output on failure can be confirmed as still working. Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-16 Mike Fleetwood Avoid using += shell variable concatenation in CI test jobs (!104) The test CI job on Alpine Linux fails like this: $ GTEST_FILTER+=':My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs' /bin/sh: eval: line 135: GTEST_FILTER+=:My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs: not found This is because the busybox ash shell in Alpine Linux doesn't support += syntax for variable concatenation. Use plain variable assignment instead. Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-16 Mike Fleetwood Add Alpine Linux CI test job (!104) Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-16 Mike Fleetwood Add Alpine Linux CI build job (!104) There have been a number of GParted build issues [1][2] recently on Alpine Linux because it uses musl libc [3] which is stricter to POSIX, rather than the GNU C Library (glibc) which has numerous enhancements. Glibc is used by most Linux distributions, including CentOS and Ubuntu already used in the GNOME Continuous Integration jobs. So add a GParted build job on Alpine Linux to catch these issues in future. Uses the docker image of the latest Alpine Linux release. [1] 3d4b1c1e7b33f229efd254fb0cc06660af627ea0 Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100) [2] 45c00927b72319f00855c7feaf4dcf109b3e4414 Use POSIX basename() in BCache_Info.cc (!99) [3] musl libc https://musl.libc.org/ Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32 2022-06-18 Mike Fleetwood Print kernel and OS details first in the GitLab CI jobs When the CentOS 7 CI jobs were failing on a subset of the job runners [1] during March to May 2022, the docker image would hang even before the packages were fully installed so cat /proc/version and cat /etc/os-release were never run. Move them to the first thing done in the docker image. [1] Hanging of GitLab CI jobs on a subset of job runners https://discourse.gnome.org/t/hanging-of-gitlab-ci-jobs-on-a-subset-of-job-runners/9931 2022-06-27 Rafael Fontenelle Update Brazilian Portuguese translation 2022-06-24 Jürgen Benvenuti Update German translation 2022-06-24 Jordi Mas Update Catalan translation 2022-06-23 Hugo Carvalho Update Portuguese translation 2022-06-13 Sergej A Update Russian translation 2022-06-12 Мирослав Николић Update Serbian translation 2022-05-31 Mike Fleetwood Resolve messages from configure in VPATH build (!103) Even though this is fixed the execution of configure as part of make distcheck outputs this: checking whether po/Makefile.in.in deletes intltool cache lock file... /usr/bin/grep: po/Makefile.in.in: No such file or directory /usr/bin/sed: can't read po/Makefile.in.in: No such file or directory /usr/bin/grep: po/Makefile.in.in: No such file or directory no make distcheck [1] performs a VPATH build with a read-only srcdir and a separate writable build directory with files split between the two. The relevant layout looks like: ./gparted-1.4.0-git/configure ./gparted-1.4.0-git/po/Makefile.in.in ./gparted-1.4.0-git/_build/sub/ And make distcheck runs configure like this: cd ./gparted-1.4.0-git/_build/sub ../../configure --srcdir=../.. The file is ../../po/Makefile.in.in in this case, so not found by the existing check. A simple investigation technique is to run make distcheck, kill it shortly after configure completes and examine the build tree. Definitely before make distcheck completes successfully and deletes everything. Fix by using $srcdir prefix to access the file. Also handle the case of po/Makefile.in.in not existing, although this doesn't now occur in the scenario fixed by this commit. And only patch the file if it's writable, another case that doesn't occur in this scenario. Relevant output line from configure run by make distcheck now looks like: checking whether po/Makefile.in.in deletes intltool cache lock file... yes [1] GNU Automake, 14.4 Checking the Distribution https://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html Closes !103 - Fix make distcheck failure found in GitLab CI job unbuntu_test 2022-05-29 Mike Fleetwood Fix up intltool leaving .intltool-merge-cache.lock file behind (!103) On Ubuntu 22.04 LTS make distcheck fails like this: $ make distcheck ... ERROR: files left in build directory after distclean: ./po/.intltool-merge-cache.lock make[1]: *** [Makefile:920: distcleancheck] Error 1 make[1]: Leaving directory '/builds/GNOME/gparted/gparted-1.4.0-git/_build/sub' make: *** [Makefile:849: distcheck] Error 1 This was picked up by the GitLab ubuntu_test CI job after the Ubuntu 22.04 LTS release and the official Ubuntu docker image labelled latest was updated to match, circa April 2022. This is a known issue with intltool >= 0.51.0-5.1 [1][2][3], first included in Ubuntu 22.04 LTS. The pending proposed fix is to also delete the left behind .intltool-merge-cache.lock along with the associated cache file itself in the intltool provided Makefile.in.in [4]. Applying a fix to the GitLab ubuntu_test CI job does nothing for fixing it for us maintainers on our distributions. po/Makefile.in.in is not part of the GParted git repository, instead it is copied from /usr/share/intltool/Makefile.in.in by ./autogen.sh -> gnome-autogen.sh -> intltoolize --force --copy --automake. Add a configure check which patches po/Makefile.in.in as needed. This will fix it for those building from git, and be a harmless check for those building from a tar release. Configure output line looks like: checking whether po/Makefile.in.in deletes intltool cache lock file... fixed [1] Ubuntu bug 1712194 - Error when running make distcheck https://bugs.launchpad.net/intltool/+bug/1712194 [2] Debian bug #991623 - intltool: make distcheck broken https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991623 [3] Arch Linux bug FS#67098 - [intltool] latest patch for race condition breaks some builds https://bugs.archlinux.org/task/67098 [4] Remove cache lock file in mostlyclean https://code.launchpad.net/~danbnicholson/intltool/intltool/+merge/406321 Closes !103 - Fix make distcheck failure found in GitLab CI job unbuntu_test 2022-06-05 Piotr Drąg Update Polish translation 2022-06-03 Nathan Follens Update Dutch translation 2022-06-01 Yuri Chornoivan Update Ukrainian translation 2022-05-27 Mike Fleetwood Constify string parameters to add_mountpoint_entry() add_mountpoint_entry() doesn't modify the passed strings so use pass-by-constant-reference. This avoids pass-by-value and having to construct copies of the strings just to pass them to this method. 2022-05-22 Mike Fleetwood Always use directory mount point when resizing btrfs (#193) A user received the following error when attempting to resize a mounted btrfs file system on their NixOS distribution: Shrink /dev/nvme0n1p3 from 933.38 GiB to 894.32 GiB (ERROR) + calibrate /dev/nvme0n1p3 00:00:00 (SUCCESS) + btrfs filesystem resize 1:937759744K '/etc/machine-id' (ERROR) ERROR: not a directory: /etc/machine-id ERROR: resize works on mounted filesystems and accepts only directories as argument. Passing file containing a btrfs image would resize the underlying filesystem instead of the image. In the partition table section of the gparted_details /dev/nvme0n1p3 was reported with these mount points: /etc/machine-id, /etc/NetworkManager/system-connections, /etc/ssh/ssh_host_ed25519_key, /etc/ssh/ssh_host_ed25519_key.pub, /etc/ssh/ssh_host_rsa_key, /etc/ssh/ssh_host_rsa_key.pub, /home, /nix, /nix/store, /state, /var The user had a common configuration of NixOS which boots with an empty tmpfs as root with a few bind mounted files and directories to provide the needed persistent data [1][2]. Re-create an equivalent situation: 1. Create a btrfs file system and mount it: # mkfs.btrfs /dev/sdb1 # mkdir /mnt/store # mount /dev/sdb1 /mnt/store 2. Bind mount a file from this file system else where in the hierarchy. The only criteria is that this mount point sorts before /mnt/store. # echo 'Test contents' > /mnt/store/test # touch /boot/test # mount --bind /mnt/store/test /boot/test The kernel reports these mount mounts: # grep sdb1 /proc/mounts /dev/sdb1 /mnt/store btrfs rw,seclabel,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/sdb1 /boot/test btrfs rw,seclabel,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 3. Use GParted to resize this mounted btrfs file system. It fails with the above error. GParted read the mount points from /proc/mounts and sorted them. (See the end of Mount_Info::load_cache() for the sorting). When resizing the btrfs file system GParted just used the first sorted mount point. This was the file /etc/machine-id for the user and file /boot/test in the re-creation, hence the error. Fix by selecting the first directory mount point to pass to the btrfs resize command. [1] NixOS tmpfs as root https://elis.nu/blog/2020/05/nixos-tmpfs-as-root/ [2] Erase your darlings https://grahamc.com/blog/erase-your-darlings Closes #193 - path used to resize btrfs needs to be a directory 2022-05-11 Zurab Kargareteli Add Georgian translation 2022-04-10 Dominika Liberda Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100) GParted fails to build on Alpine Linux Edge (development tree for the next release) like this: GParted_Core.cc: In constructor 'GParted::GParted_Core::GParted_Core()': GParted_Core.cc:75:64: error: invalid 'static_cast' from type 'std::nullptr_t' to type 'PedPartitionFlag' 75 | for ( PedPartitionFlag flag = ped_partition_flag_next( static_cast( NULL ) ) ; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The code is failing to compile now because musl libc 1.2.3 has became more C++11 strict [1][2] by defining NULL [3] as nullptr [4] rather than as 0. The parameter to ped_partition_flag_next() [5] should always have been numeral 0 cast to an enumeration and never the NULL pointer. Fixes this commit [6] from 2004-12-27 which changed the parameter from 0 to NULL. [1] define NULL as nullptr when used in C++11 or later https://git.musl-libc.org/cgit/musl/commit?id=98e688a9da5e7b2925dda17a2d6820dddf1fb28 [2] NULL vs nullptr (Why was it replaced?) [duplicate] https://stackoverflow.com/questions/20509734/null-vs-nullptr-why-was-it-replaced [3] C++ reference, NULL https://en.cppreference.com/w/cpp/types/NULL [4] C++ reference, nullptr https://en.cppreference.com/w/cpp/language/nullptr [5] libparted Documentation, ped_partition_flag_next() https://www.gnu.org/software/parted/api/group__PedPartition.html#g0ce9ce4247b320011bc8e9d957c8cdbb [6] Added cylsize to Device and made Operation contain a Device instead commit 174f0cff77c5799a713954a22b2c54306d03036c Closes !100 - Fix NULL == 0 assumption in call to ped_partition_flag_next() 2022-04-08 Markus Volk Use POSIX basename() in BCache_Info.cc (!99) Musl libc [1][2] doesn't implement the GNU variant of basename() [3][4], obtained via #include . Therefore GParted fails to build on such distributions: fdebug-prefix-map=TOPDIR/build/tmp/work/cortexa57-yoe-linux-musl/gparted/1.4.0-r0/recipe-sysroot-native=-fvisibility-inlines-hidden -c -o ../../gparted-1.4.0/src/BCache_Info.cc:52:33: error: use of undeclared identifier 'basename'; did you mean 'g_basename'? return "/dev/" + Glib::ustring(basename(buf)); ^~~~~~~~ g_basename Fix by using the POSIX implementation of basename() [5] instead, obtained via #include , which musl libc does implement [6]. Note that the POSIX implementation of basename() is allowed to modify the string passed to it. This is okay because BCache_Info::get_bcache_device() is using a modifiable local character buffer. [1] musl libc https://musl.libc.org/ [2] Projects using musl https://wiki.musl-libc.org/projects-using-musl.html [3] The GNU C Library, 5.10 Finding Tokens in a String https://www.gnu.org/software/libc/manual/html_node/Finding-Tokens-in-a-String.html [4] basename(3) - Linux manual page https://man7.org/linux/man-pages/man3/basename.3.html [5] POSIX basename() https://pubs.opengroup.org/onlinepubs/009695399/functions/basename.html [6] musl source, basename.c http://git.musl-libc.org/cgit/musl/tree/src/misc/basename.c Closes !99 - Fix undeclared identifier 'basename' build failure with musl libc 2022-04-07 Jordi Mas Update Catalan translation 2022-03-31 Andika Triwidada Update Indonesian translation 2022-03-28 Curtis Gedak Append -git to version for continuing development 2022-03-28 Curtis Gedak ========== gparted-1.4.0 ========== 2022-03-28 Curtis Gedak Update copyright years 2022-03-27 Rūdolfs Mazurs Update Latvian translation 2022-03-27 Andika Triwidada Update Indonesian translation 2022-03-25 Alan Mortensen Update Danish translation 2022-03-23 Kjell Cato Heskjestad Update Norwegian Bokmål translation 2022-03-18 Marek Černocký Updated Czech help translation 2022-03-17 A S Alam Update Punjabi translation 2022-03-16 Milo Casagrande Update Italian translation 2022-03-13 Goran Vidović Update Croatian translation 2022-03-13 Goran Vidović Update Croatian translation 2022-03-10 Asier Sarasua Garmendia Update Basque translation 2022-01-27 Mike Fleetwood Disable unmount of busy jbds (#89) GParted automatically enables the Partition > Unmount action for busy partitions. This is not going to be supported for jbds so disable it. Closes #89 - GParted doesn't recognise EXT4 fs journal partition 2022-01-25 Mike Fleetwood Suppress "Unable to find mount point" warning for jbds (#89) Closes #89 - GParted doesn't recognise EXT4 fs journal partition 2022-01-25 Mike Fleetwood Report busy status of jbds (#89) Continuing from the state in the previous commit, create an ext4 file system using the previously created external journal and mount it. # mke2fs -t ext4 -J device=/dev/sdb1 -L test-ext4 /dev/sdb2 # mount /dev/sdb2 /mnt/2 Did some experimenting with trying to create a second file system using the same external journal which is already in use. # mke2fs -t ext4 -J device=/dev/sdb1 -L 2nd-test-ext4 /dev/sdb3 ... /dev/sdb1 is apparently in use by the system; will not make a journal here! # exit $? 1 Examined the source code of mke2fs and found that it performs an exclusive read-only open of the named journal block device to check if it is in use by the system or not [1]. Use the same method in GParted. Not used alternative method would be to mark the jbd active when the ext3/4 file system using it is active, but that requires working out the linkage between them. That can be done using either blkid or dumpe2fs output but that involves parsing more fields and caching more data so is much more code than just testing the block device busy status using the same method which mke2fs uses. Matching UUIDs via blkid output. # blkid /dev/sdb1 /dev/sdb2 /dev/sdb1: LABEL="test-jbd" UUID="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="jbd" /dev/sdb2: LABEL="test-ext4" UUID="cea5c2cd-b21c-4abf-a497-8c073bb12300" EXT_JOURNAL="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="ext4" Matching UUIDs via dumpe2fs output. # dumpe2fs -h /dev/sdb1 | egrep 'Filesystem UUID|Journal users' dumpe2fs 1.46.3 (27-Jul-2021) Filesystem UUID: 6e52858e-0479-432f-80a1-de42f9a4093e Journal users: cea5c2cd-b21c-4abf-a497-8c073bb12300 # dumpe2fs -h /dev/sdb2 | egrep 'Filesystem UUID|Journal UUID' dumpe2fs 1.46.3 (27-Jul-2021) Filesystem UUID: cea5c2cd-b21c-4abf-a497-8c073bb12300 Journal UUID: 6e52858e-0479-432f-80a1-de42f9a4093e If GParted was going to show the journal to file system linkage in the UI then doing this would be needed. However so far there has only been a single reported case of a GParted user using an external journal, therefore adding the code complexity for this feature is not currently justified. The simple busy detection method used by mke2fs is all that is needed. [1] mke2fs source code https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/ misc/mke2fs.c:main() check_mount(journal_device, force, _("journal")); misc/util.c:check_mount() ext2fs_check_if_mounted(device, &mount_flags); lib/ext2fs/ismounted.c:ext2fs_check_if_mounted() ext2fs_check_mount_point(file, mount_flags, NULL, 0); lib/ext2fs/ismounted.c:ext2fs_check_if_mounted() if (stat(device, &st_buf) == 0 && ext2fsP_is_disk_device(st_buf.st_mode)) { int fd = open(device, O_RDONLY | O_EXCL); if (fd >= 0) { /* * The device is not busy so it's * definitelly not mounted. No need to * to perform any more checks. */ close(fd); *mount_flags = 0; return 0; } else if (errno == EBUSY) { busy = 1; } } Closes #89 - GParted doesn't recognise EXT4 fs journal partition 2022-01-24 Mike Fleetwood Recognise jbd (journaling block device) (#89) A user reported that they were using an external journal with an ext4 file system, but that GParted didn't recognise it. (They had the jbd on an Intel Optane drive and the ext4 file system on an SSD). Create a jbd like this: # mke2fs -O journal_dev -L test-jbd /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: LABEL="test-jbd" UUID="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="jbd" Add recognition of jbd. Use Blue Shadow colour, the same as ext4, because jbd is primarily used by ext3/4 [1][2]. jbd is also used by ocfs2 [1][3] and lustre [4][5] clustered file systems, but they are very unlikely to encountered by GParted users. Also xfs [6] and jfs [7] can have external journals so if recognition of them is ever added they will get the same colour as their respective file systems too. [1] Journaling block device https://en.wikipedia.org/wiki/Journaling_block_device "JBD is filesystem-independent. ext3, ext4 and OCFS2 are known to use JBD" [2] https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_the_key_differences_between_jbd_and_jbd2.3F [3] OCFS2: The Oracle Clustered File System, Version 2 https://www.kernel.org/doc/ols/2006/ols2006v1-pages-289-302.pdf "Metadata journaling is done on a per node basis with JBD" [4] Efficient Object Storage Journaling in a Distributed Parallel File System https://www.usenix.org/legacy/event/fast10/tech/full_papers/oral.pdf [5] Lustre Software Release 2.x Operations Manual https://doc.lustre.org/lustre_manual.pdf 6.4.2. Choosing Parameters for an External Journal [6] mkfs.xfs(8) - construct an XFS filesystem https://man7.org/linux/man-pages/man8/mkfs.xfs.8.html "OPTIONS ... logdev=device This is used to specify that the log section should reside on the device separate from the data section. The internal=1 and logdev options are mutually exclusive. " [7] jfs_mkfs(8) - create a JFS formatted partition https://manpages.debian.org/testing/jfsutils/jfs_mkfs.8.en.html "OPTIONS ... -j journal_device Create the external JFS journal on journal_device, ... " Closes #89 - GParted doesn't recognise EXT4 fs journal partition 2022-03-01 Mike Fleetwood Fix translation of DocBook markup tag of the GParted Manual (!98) As found by the GitLab Continuous Integration job on CentOS 7 with itstool 2.0.2, building the GParted Manual breaks on the Russian translation like this: $ ./autogen.sh $ make clean $ cd help $ make ... if ! test -d "ru/"; then mkdir "ru/"; fi if test -d "C"; then d="../"; else d="/home/mike/programming/c/gparted/help/"; fi; \ mo="ru/ru.mo"; \ if test -f "${mo}"; then mo="../${mo}"; else mo="/home/mike/programming/c/gparted/help/${mo}"; fi; \ (cd "ru/" && itstool -m "${mo}" ${d}/C/index.docbook) && \ touch "ru/ru.stamp" Error: Could not merge translations: 'NoneType' object has no attribute 'node' make: *** [ru/ru.stamp] Error 1 On Fedora 35 with itstool 2.0.6 building the GParted Manual merely reports a warning, leaving one paragraph untranslated, but the build completes successfully: $ ./autogen.sh $ make clean $ cd help $ make ... if ! test -d "ru/"; then mkdir "ru/"; fi if test -d "C"; then d="../"; else d="/home/fedora/programming/c/gparted/help/"; fi; \ mo="ru/ru.mo"; \ if test -f "${mo}"; then mo="../${mo}"; else mo="/home/fedora/programming/c/gparted/help/${mo}"; fi; \ (cd "ru/" && itstool -m "${mo}" ${d}/C/index.docbook) && \ touch "ru/ru.stamp" Warning: Could not merge translation for msgid: Set the grub root device by specifying the device returned by the find command. This should be the partition containing the boot directory. <_:screen-1/> ... $ echo $? 0 Fix translation of DocBook markup tag in the Russian translation of the GParted Manual by commit: 17f4c3176d3be29d2867c080c0b292643d470627 Update Russian translation Closes !98 - Fix translation of DocBook markup tag of the GParted Manual 2022-01-08 Mike Fleetwood Remove support for old volatile udev rules below /dev/.udev Udev stopped supporting volatile udev rules in /dev/.udev/rules.d in udev 176, released 2012-01-11 [1]. The oldest supported distributions use much more recent combined systemd and udev releases. Distro EOL udevadm -V Debian 9 2022-Jun 232 RHEL / CentOS 7 2024-Jun 219 Ubuntu 18.04 LTS 2023-Apr 237 Now udev only reads volatile rules from /run/udev/ruled.d [2]. Simplify the code a little. [1] udev 176 NEWS https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/NEWS?h=176 "A writable /run directory (ususally tmpfs) is required now for a fully functional udev, there is no longer a fallback to /dev/.udev." [2] man 7 udev "RULES FILES The udev rules are read from the files located in the system rules directory /usr/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d." 2022-01-08 Mike Fleetwood Prevent GParted probe starting stopped bcache (#183) From the setup in the previous commit, unregister (stop) all of the bcache backing and cache devices. # bcache unregister /dev/sdb2 # bcache unregister /dev/sdb1 # bcache unregister /dev/sdc1 # bcache show Name Type State Bname AttachToDev /dev/sdb2 1 (data) inactive Non-Exist Alone /dev/sdb1 1 (data) inactive Non-Exist Alone /dev/sdc1 3 (cache) inactive N/A N/A Run GParted. Just the device scanning causes the stopped bcache devices to be restarted. # bcache show Name Type State Bname AttachToDev /dev/sdb2 1 (data) clean(running) bcache1 /dev/sdc1 /dev/sdb1 1 (data) clean(running) bcache0 /dev/sdc1 /dev/sdc1 3 (cache) active N/A N/A This is nothing new with this patchset, but as a result of existing udev behaviour. The chain of events goes like this: 1. GParted calls ped_device_get() on each whole device; 2. Libparted opens each partition read-write to flush the cache; 3. When each is closed the kernel emits a block change event; 4. Udev fires block rules to detect the possibly changed content; 5. Udev fires bcache register (AKA start) rule. More details with the help of udevadm monitor, strace and syslog: GParted | set_devices_thread() GParted | ped_device_get("/dev/sdb") Libparted| ... Libparted| openat(AT_FDCWD, "/dev/sdb1", O_WRONLY) = 9 Libparted| ioctl(9, BLKFLSBUF) = 0 Libparted| close(9) KERNEL | change /devices/.../block/sdb/sdb1 (block) KERNEL | add /devices/virtual/bdi/250:0 (bdi) KERNEL | add /devices/virtual/block/bcache0 (block) KERNEL | change /devices/virtual/block/bcache0 (block) UDEV | change /devices/.../block/sdb/sdb1 (block) UDEV | add /devices/virtual/bdi/250:0 (bdi) UDEV | add /devices/virtual/block/bcache0 (block) UDEV | change /devices/virtual/block/bcache0 (block) SYSLOG | kernel: bcache: register_bdev() registered backing device sdb1 # grep bcache-register /lib/udev/rules.d/69-bcache.rules RUN+="bcache-register $tempnode" Fix this by temporarily adding a blank udev override rule to suppress automatic starting of bcache devices, just as was previously done for Linux Software RAID arrays [1]. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Closes #183 - Basic support for bcache 2022-01-07 Mike Fleetwood Show bcache device as mount point of registered backing device (#183) A bcache device provides accelerated access to a backing device in a one to one relationship. Multiple bcache backing devices can be attached to and accelerated by the same cache device. Extending the setup from the previous commit, create an additional backing device and attach it to the same cache. # bcache make -B /dev/sdb2 # bcache attach /dev/sdc1 /dev/sdb2 # bcache show Name Type State Bname AttachToDev /dev/sdb2 1 (data) clean(running) bcache1 /dev/sdc1 /dev/sdb1 1 (data) clean(running) bcache0 /dev/sdc1 /dev/sdc1 3 (cache) active N/A N/A List a couple of bcache specific sysfs files which identify registered (active) bcache devices (components). # ls -l /sys/block/sd?/sd??/bcache/{dev,set} lrwxrwxrwx. 1 root root 0 Jan 7 10:08 /sys/block/sdb/sdb1/bcache/dev -> ../../../../../../../../../../virtual/block/bcache0 lrwxrwxrwx. 1 root root 0 Jan 7 11:53 /sys/block/sdb/sdb2/bcache/dev -> ../../../../../../../../../../virtual/block/bcache1 lrwxrwxrwx. 1 root root 0 Jan 7 11:53 /sys/block/sdc/sdc1/bcache/set -> ../../../../../../../../../../../fs/bcache/9945e165-0604-4f29-94bd-b155d01080ad As was done with previous software block devices [1][2][3][4] show the bcache (access) device as the mount point of a backing device (component). Use the /sys/block/DEV[/PTN]/bcache/dev sysfs symlinks to provide the bcache device names. Bcache cache devices (components) don't get mount points because they aren't accessible. [1] commit 8083f11d84dbd4f186271a3cdbf5170db259f8b8 Display LVM2 VGNAME as the PV's mount point (#160787) [2] commit f6c2f00df7858a7f4b97e699b9bcf1023bba850a Populate member mount point with SWRaid array device (#756829) [3] commit 538c866d099bc1f2bab3a41dc13a00b3d4336bbf Display array device as mount point of mdadm started ATARAID members (#75) [4] commit 538c866d099bc1f2bab3a41dc13a00b3d4336bbf Display array device as mount point of mdadm started ATARAID members (#75) Closes #183 - Basic support for bcache 2022-01-26 Mike Fleetwood Disable unmount of busy bcache devices (#183) GParted automatically enables the Partition > Unmount action for busy partitions. Unregister (deactivate) bcache devices is not going to be supported so disable it. Closes #183 - Basic support for bcache 2022-01-07 Mike Fleetwood Report busy status of bcache (#183) Make (format as) bcache backing device (-B) and cache device (-C) and implicitly attach the backing device to the cache to enable caching, all in one. # bcache make -B /dev/sdb1 -C /dev/sdc1 # bcache show Name Type State Bname AttachToDev /dev/sdb1 1 (data) clean(running) bcache0 /dev/sdc1 /dev/sdc1 3 (cache) active N/A N/A After experimenting with 'bcache unregister', 'bcache register' and stracing 'bcache show' the bcache kernel module creates the sysfs directory /sys/block/DEV[/PTN]/bcache and it's contents only when the bcache device is registered with the kernel (bcache component is active). Use this to identify whether any bcache device (component) should be displayed as active or not in GParted. # ls -ld /sys/block/sd?/sd?1/bcache drwxr-xr-x. 6 root root 0 Jan 7 10:08 /sys/block/sdb/sdb1/bcache drwxr-xr-x. 2 root root 0 Jan 7 10:08 /sys/block/sdc/sdc1/bcache Closes #183 - Basic support for bcache 2022-01-07 Mike Fleetwood Also pass device_path into GParted_Core::is_busy() (#183) Will use this extra parameter when determining if a device or partition containing bcache is busy or not. Closes #183 - Basic support for bcache 2022-01-06 Mike Fleetwood Enable GParted to present bcache devices (#183) Add pattern to recognise block cache devices as valid devices for GParted to work with. Devices are named by the Linux kernel device driver like /dev/bcache0 [1] with partitions named like /dev/bcache0p1 [2]. Note bcache devices can be partitioned but all the documents I have seen guide users to create file systems directly in a bcache device and not partition it [3][4] (plus all other Internet search results I looked at). This might be because bcache is a specialist use case and the bcache backing device can be a partition itself. [1] linux 5.15 drivers/md/bcache/super.c bcache_device_init() https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/md/bcache/super.c?h=v5.15#n945 [2] Contents of /proc/partitions for a bcache partitioned backing device $ grep bcache /proc/partitions 251 0 524280 bcache0 251 1 523256 bcache0p1 [3] Linux kernel document: A block layer cache (bcache) https://www.kernel.org/doc/Documentation/bcache.txt [4] The Linux kernel user's and administrator's guide > A block layer cache (bcache) https://www.kernel.org/doc/html/latest/admin-guide/bcache.html Closes #183 - Basic support for bcache 2022-01-04 Mike Fleetwood Add detection of bcache (#183) Use blkid to detect bcache formatted devices. Requires blkid from util-linux >= 2.24 for detection of bcache devices [1]. Use util-linux's FS images when testing GParted detection. # wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/bcache-B.img.xz # xzcat bcache-B.img.xz > /dev/sdb1 # wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/bcache-C.img.xz # xzcat bcache-C.img.xz > /dev/sdc1 # blkid /dev/sdb1 /dev/sdc1 /dev/sdb1: UUID="8fb7f716-4c19-4517-bfbb-6f4a2becad60" TYPE="bcache" PARTUUID="f8f1485e-01" /dev/sdc1: UUID="7a343627-ac87-4bf0-b76f-46067cbc9b8c" TYPE="bcache" PARTUUID="f46e8c86-01" To tidy-up after testing GParted detection, stop the bcache device in case it was automatically started and wipe the signatures. This is to prevent udev rules from automatically starting the bcache device on every subsequent reboot. # echo 1 > /sys/block/sdb/sdb1/bcache/stop # wipefs -a /dev/sdb1 /dev/sdc1 Closes #183 - Basic support for bcache 2022-01-06 Mike Fleetwood Use face skin colours exclusively for software block devices (#183) Currently the Face Skin colour range from the GNOME palette represent a mixture of file systems and software block devices: JFS - Face Skin Medium LVM2_PV - Face Skin Dark NILFS2 - Face Skin Shadow LINUX_SWRAID - Dark Brown ATARAID - Dark Brown We are about to add recognition of bcache [1][2][3], another software block device. Reorganise the colour assignments so that Face Skin colour range is exclusively used by types of software block devices and assign JFS and NILFS2 new colours. Face Skin Light (#EFE0CD) - Face Skin Medium (#E0C39E) - BCACHE [New assignment] Face Skin Dark (#B39169) - LVM2_PV Face Skin Shadow (#826647) - LINUX_SWRAID [New assignment] Brown Dark (#5A4733) - ATARAID NILFS2 has flash friendly characteristics [4] so use Accent Red colours along with F2FS. Accent Red (#DF421E) - F2FS Accent Red Dark (#990000) - NILFS2 [New assignment] Move JFS to a group with XFS and UFS. The hue of the GNOME palette Accent Yellow Dark colour, as used by UFS, was more Orange compared to Accent Yellow and a bit too close to the Orange used by BTRFS. So use the hue of the GNOME Accent Yellow and extend the range and assign like this. Accent Yellow (#EED680) - XFS Accent Yellow Dark (#D6B129) - JFS [Updated hue. New assignment] Accent Yellow Shadow (#AA8F2C) - UFS [New colour. New assignment] Accent Yellow Dark Shadow (#826F2B) - [New colour] [1] bcache https://bcache.evilpiepirate.org/ [2] Linux kernel document: A block layer cache (bcache) https://www.kernel.org/doc/Documentation/bcache.txt [3] The Linux kernel user's and administrator's guide > A block layer cache (bcache) https://www.kernel.org/doc/html/latest/admin-guide/bcache.html [4] NILFS, Relative performance https://en.wikipedia.org/wiki/NILFS#Relative_performance Closes #183 - Basic support for bcache 2022-02-25 Sergej A Update Russian translation 2021-10-31 Mike Fleetwood Remove unnecessary Glib::ustring::compose() of constant string 2021-10-31 Mike Fleetwood Check copy destination instead of source (!95)(#723571) GParted currently performs these relevant steps for a copy operation: 1. Check source file system 2. Copy to destination 3. If destination partition is larger than source 3.1. check destination file system 3.2. grow destination file system Always checking the source was added by this commit: a54b52ea33abb1f5a44b52bcad5858ba41cd135d xfs copy now uses xfsdump and xfsrestore. icw some hacks in the other 2 ... Also the source file system is now checked before the actual copy is performed. If damaged beyond repair, the copy won't start. I think users have an expectation that a copy operation accesses the source read-only and performing a file system check on the source breaks that expectation. Also uses may accidentally or deliberately try to copy a file system off a failing drive, where trying to check the source could lead to further data loss. (ddrescue is the proper tool for recovering data from damaged drives but ddrescue is not a tool the user may know -- they know about GParted). For a failing drive, not checking the source first means the copy might fail instead, however a failed copy is preferable to greater chance of further damaging the source file system by checking it. In order to keep the new process as similar as possible to before, always check the destination instead. This changes the copy operation from performing one or two file system checks to always performing only one check. The new relevant copy operation steps are: 1. Copy to destination 2. check destination file system 3. If destination partition is larger than source 3.1. grow destination file system This has exactly the same error handling as before, if the check of the destination file system fails the operation stops and any grow step won't be performed. This represents the minimum change in behaviour from before. Bug 723571 - Copying ext4 partitions should not fix the source but the destination Closes !95 - Check copy destination instead of source 2022-02-05 Luming Zh Update Chinese (China) translation 2021-11-23 Matej Urbančič Update Slovenian translation 2021-11-06 Mike Fleetwood Return and use constant reference from SWRaid_Info::get_label() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-06 Mike Fleetwood Return constant reference from SWRaid_Info::get_uuid() (!94) Since the only use of SWRaid_Info::get_uuid() assign the returned value this doesn't actually save any copy construction. Do it for consistency with the other get_*() methods in SWRaid_Info. Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-06 Mike Fleetwood Return and use constant reference from SWRaid::get_array() (!94) Have to use a second constant reference variable array_path_2 in GParted_Core::set_mountpoints() because by design C++ does not implement rebinding of references [1]. [1] why doesn't C++ allow rebinding a reference? https://stackoverflow.com/questions/27037744/why-doesnt-c-allow-rebinding-a-reference Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-06 Mike Fleetwood Return constant reference from OperationDetail::get_treepath() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-06 Mike Fleetwood Return constant reference from OperationDetail::get_description() (!94) All uses of get_description() copy construct to a local variable, not assign to a reference, so this doesn't save anything. It is just being done to be consistent with making other getters return a constant reference. Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-02 Mike Fleetwood Use constant reference from LVM2_PV_Info::get_vg_cache_entry_by_name() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-02 Mike Fleetwood Return and use constant reference from LVM2_PV_Info::get_vg_name() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-02 Mike Fleetwood Use constant reference from LVM2_PV_Info::get_pv_cache_entry_by_name() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-02 Mike Fleetwood Use constant reference from btrfs::get_cache_entry() (!94) Method already returned a constant reference. Change local variables to constant references to avoid copy constructing them. Closes !94 - Make more getter methods use return-by-constant-reference 2021-10-31 Mike Fleetwood Return and use constant reference from Partition::get_mountpoints() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-02 Mike Fleetwood Return and use constant reference from Partition::get_mountpoint() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-02 Mike Fleetwood Return and use constant reference from Partition::get_filesystem_label() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-01 Mike Fleetwood Return and use constant reference from Partition::get_path() (!94) Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-01 Mike Fleetwood Return and use constant reference from Device::get_path() (!94) A number of GParted methods named get_*() are returning properties and are return-by-value. For objects this implies the returned value is copy constructed and later destroyed when it goes out of scope. Change them to use return-by-constant-reference to avoid unnecessary object duplication. Just have to make sure the reference goes out of scope before the referenced object is destroyed to avoid having a reference (pointer) to freed memory. Assigning to a local variable instead of of a local reference still duplicates the object so can be used when the lifetime of the gotten object needs to be longer that the referenced object. Previously done for other getters here: d948cbcb9143dc975dd3c66defd7289eb4113b2c Make get_custom_text() and get_generic_text() return by reference This change just makes Device::get_path() return a constant reference and updates uses to match to avoid copy constructing the returned value. Closes !94 - Make more getter methods use return-by-constant-reference 2021-11-14 Matej Urbančič Update Slovenian translation 2021-11-05 Yaron Shahrabani Update Hebrew translation 2021-11-05 Yaron Shahrabani Update Hebrew translation 2021-10-21 Mike Fleetwood Make MB_Needed_for_Boot_Record() a static member function Because it doesn't access any member variables or call any member methods. 2021-10-21 Mike Fleetwood Simplify logic in MB_Needed_for_Boot_Record() et al The first two clauses say is the partition object type unallocated inside an extended partition, or a logical partition (which only occur inside an extended partition). As these are the only two partition object types which can occur inside an extended partition, this is equivalent to saying is the partition object inside an extended partition. Simplify. 2021-10-20 Mike Fleetwood Use previous unallocated partition when determining 1 MiB reservation in resize/move dialog The create new and paste into new dialogs are both composing a new partition into the unallocated selected_partition they are passed. The starting sector of this unallocated partition is the first sector the newly composed partition could possibly have. To ensure it doesn't overlay with the partition table or EBR (Extended Boot Records) it calls MB_Needed_for_Boot_Record() to indicate if the first 1 MiB needs to be reserved in the dialog or not. Code: Dialog_Partition_New::set_data(..., selected_partition, ...) ... MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(selected_partition); Dialog_Partition_Copy::set_data(selected_partition, ...) ... MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(selected_partition); However the resize/move dialog is different. It is passed the existing selected_partition object and the vector of partitions from which it determines if there is a previous unallocated partition object or not. When there is no previous unallocated partition object, there is no need to reserve 1 MiB because the selected_partition can't be moved further to the left. In the other case when there is a previous unallocated partition object the start of the existing selected_partition can be moved to the left. However the code passes the selected_partition object to MB_Needed_for_Boot_Record() so doesn't have the first sector the newly composed partition could possibly have so doesn't reserve the first 1 MiB to prevent it overlapping with the partition table at the start of the drive. These two commits addressed this limitation: * Ensure 1 MiB reserved when moving extended partition to start of drive * Ensure 1 MiB reserved when moving partition to start of disk Code: Dialog_Partition_Resize_Move::set_data(selected_partition, ...) new_partition = selected_partition.clone(); if (selected_partition.type == TYPE_EXTENDED) Resize_Move_Extended(...); else Resoze_Move_Normal(...); Dialog_Partition_Resize_Move::Resize_Move_Normal(...) ... if (previous <= 0) MIN_SPACE_BEFORE_MB = 0; else { if (START < MEBIBYTE / new_partition->sector_size) MIN_SPACE_BEFORE_MB = 1; else MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(*new_partition); } Dialog_Partition_Resize_Move::Resize_Move_Extended(...) ... if (previous <= 0) MIN_SPACE_BEFORE_MB = 0; else { if (START < MEBIBYTE / new_partition->sector_size) MIN_SPACE_BEFORE_MB = 1; else MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(*new_partition); } So instead pass the previous unallocated partition object as that contains the left most start sector the newly composed partition could possibly have, therefore the check for overlapping the partition table in the first 1 MiB of the drive can succeed. 2021-10-20 Mike Fleetwood Ensure 1 MiB reserved when moving extended partition to start of drive On an MSDOS partitioned drive, create an extended partition at least 2 MiBs from the start of the drive. Like this: dd if=/dev/zero bs=1M of=dev/sdb echo 4096,4096,5 | sfdisk -uS --force /dev/sdb The resize/move dialog appears to allow the extended partition to be moved and/or resized to the very start of the drive, over the top of the partition table, without reserving the first 1 MiB. Ensure the dialog reserves the first 1 MiB, like it does when moving normal partitions. Reference: ceab9bde57fafbc96f9d90d2a86713cd07126f8b Ensure 1 MiB reserved when moving partition to start of disk 2021-10-19 Mike Fleetwood Allow resize/move of partition to sector 2048 when following another (#172) This case is an extension of the setup in the previous commit. Add a second partition several megabytes after the first. It looks like this: [TABLE][PTN#1] [PTN#2] <-- 1st MiB -><- several MiBs -> Just need to make the gap 2 MiB or more so that it can be seen what the resize/move dialog is allowing. Setup like this using an 8 MiB gap and 8 MiB partition #2. For MSDOS use: dd if=/dev/zero bs=1M of=/dev/sdb (echo 1,2047; echo 18432,16384) | sfdisk -uS --force /dev/sdb mkswap /dev/sdb2 For GPT use: sgdisk --zap-all /dev/sdb sgdisk --set-alignment=1 --new 1:34:2047 /dev/sdb sgdisk --new 2:18432:34815 /dev/sdb mkswap /dev/sdb2 In GParted try to move partition sdb2 to the left as much as possible, or try to resize the start to the left as much as possible. GParted insists on having a 1 MiB of padding before the start of sdb2, forcing it to start at sector 4096, even though sector 2048 is free and aligns to whole megabytes. Delete the preceding partition. Now GParted allows sdb2 to be moved or resize to start at sector 2048. Fix another off by one error in the sector comparison for the resizing/moving of partitions. Closes #172 - GParted doesn't allow creation of a partition starting at sector 2048 if there is a partition before it 2021-10-19 Mike Fleetwood Allow creation of partition at sector 2048 when following another (#172) [This commit message and test case is written assuming a drive with a (logical) sector size of 512 bytes. GParted equally well works with other sector sizes because the limit is expressed as 1 MiB / sector size. Adjust the test case sector counts as needed when testing with different sector sized drives.] Prepare an MSDOS or GPT partitioned disk with the first partition within the first 1 MiB. For MSDOS use: dd if=/dev/zero bs=1M of=/dev/sdb echo 1,2047 | sfdisk -uS --force /dev/sdb For GPT use: sgdisk --zap-all /dev/sdb sgdisk --set-alignment=1 --new 1:34:2047 /dev/sdb In GParted create a new partition on /dev/sdb as near to the start of the drive as possible. GParted insists on added an extra 1 MiB of space before the new partition, making it start at sector 4096, even though sector 2048 is free and aligns to whole megabytes. Delete the preceding partition. Now GParted allows the new partition to be created starting at sector 2048. GParted only needs to add padding of 1 MiB to account for the partition table at the start of the drive when the possible start is within the first MiB, not already at the first MiB. Fix this off by one error in the sector comparison. The reason this has bug has never occurred before is because it is very unusual to have the first partition entirely within the first 1 MiB. Normally either the (start of) the drive is free so GParted creates an unallocated partition object starting at sector 0, so adding 1 MiB of padding to preserve the partition table is correct; or the first partition starts at 1 MiB so the possible start for a second partition is much later in the drive. Closes #172 - GParted doesn't allow creation of a partition starting at sector 2048 if there is a partition before it 2021-10-02 Pascal Engélibert Add accessibility relations (!92) Accessibility relations are essential for usage with screen readers. It enables the screen reader to read the corresponding label along with the value of a widget when it gains focus, rather than just the value of the widget itself. Test by running Orca screen reader and tab around the elements of the UI and listen to what is read out. For example before it would be "500 GiB", where as after it would be "Unused 500 GiB". Closes !92 - Add accessibility relations 2021-10-06 Dušan Kazik Update Slovak translation 2021-10-03 Aleksandr Melman Update Russian translation 2021-09-20 Mike Fleetwood Fix crash scrolling quickly in the drive selection combobox (#165) A user reported that scrolling the mouse wheel quickly crashes GParted [1]. The minimum setup required to reproduce this crash is 3 drives partitioned like this: sda - any sdb - some unallocated space sdc - no unallocated space Then move the pointer over the drive selection combobox and scroll the mouse wheel quickly downwards. The sequence of events goes like this: 1. The first scroll wheel down event causes the device combobox selection to change to the second entry (sdb), which calls combo_devices_changed() -> Refresh_Visual(). 2. Refresh_Visual() sets selected_partition_ptr to point to the largest unallocated space partition object in sdb. 3. The first Gtk event processing loop in Refresh_Visual() comes across the next scroll wheel down event. This changes the selection to the third entry (sdc), which makes a recursive call to combo_devices_changed() -> Refresh_Visual(). 4. Refresh_Visual() sets selected_partition_ptr to NULL as sdc has no unallocated space and returns. 5. The first call to Refresh_Visual() resumes after the first Gtk event loop, continuing the processing for drive sdb. As sdb has a largest unallocated space partition (largest_unalloc_size >= 0), DrawingAreaVisualDisk::set_selected() is called with the now NULL selected_partition_ptr. 6. One of the DrawingAreaVisualDisk::set_selected() methods dereferences the NULL pointer, crashing GParted. As a comment says of selected_partition_ptr "Lifetime: Valid until the next call to Refresh_Visual()." It just wasn't expected that the next call to Refresh_Visual() would be half way through Refresh_Visual() itself. Considered but rejected fixes: 1. Remove automatic selection of the largest unallocated space. Removes functionality. 2. Return at the top of Refresh_Visual() when called recursively. This causes GParted to not update the main window with the latest selected drive. In the above example the combobox would show sdc, but the main window graphic and partition list would have only been updated once showing sdb, the first scrolled selection. Fix by only having a single Gtk event processing loop at the end of Refresh_Visual() with the optional calls to select the largest unallocated partition before that loop. This makes it impossible to call the ::set_selected() methods with selected_partition_ptr modified by a recursive call. This fix reverts this earlier commit: 0fb8cce6992f238b78272b603b69e070cfd46a00 Reduce flashing redraw from automatic partition selection (#696149) That commit was in GParted 0.20.0 when Gtk 2 was still used. Re-testing now doesn't see any flashing redrawing from the automatic partition selection, with GParted currently using Gtk 3. [1] Debian bug #991998 - gparted segfaults if scrolling quickly the device dropdown list https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991998 Closes #165 - GParted segfaults if scrolling quickly in the device dropdown 2021-09-18 Мирослав Николић Update Serbian translation 2021-09-04 Mike Fleetwood Fix warning from double assigning to gscreen Compiling GParted on an older distribution with gtk+-3.0 < 3.22.0, where HAVE_GTK_SHOW_URI_ON_WINDOW is undefined, produces this warning message: Win_GParted.cc: In member function 'void GParted::Win_GParted::show_help(const Glib::ustring&, const Glib::ustring&)': Win_GParted.cc:1822:56: warning: operation on 'gscreen' may be undefined [-Wsequence-point] GdkScreen *gscreen = gscreen = gdk_screen_get_default(); ^ Found on Ubuntu 16.04 LTS with gtk+ 3.18.0. Stop double assigning to gscreen. Fixes commit: 26f4dc504ab6837d717b1f047edc3853b1c67a5f Replace deprecated gtk_show_uri() method for help window (!82) 2021-09-05 Mike Fleetwood Replace /proc/mounts grep with Mount_Info cache reload and query (!89) Creating a grep process to check if a particular mount is still mounted is an unnecessary overhead. All that is needed is for the Mount_Info module to refresh it's copy of /proc/mounts and query that. To keep the code as simple as possible just reload the whole of the Mount_Info module and query the mount cache to determine if the particular block device is still mounted at this particular mount point. This therefore re-reads /proc/mounts (necessary) and /proc/swaps and /etc/fstab (unnecessary). This is still much less overhead than creating a separate grep process. Closes !89 - Fix unmount error when unmounting below a bind mount point 2021-08-20 Movie Ma Fix unmount error when unmounting below a bind mount point (!89) Bind mounts duplicate part of the file system hierarchy to an additional mount point [1]. When mounting and unmounting a second file system below a duplicating bind mount Linux automatically presents this lower file system as being mounted multiple times. GParted displays these multiple mount points. However using GParted to unmount this lower file system reports an error that the second mount point is no longer mounted, because all were unmounted by the first unmount command. Setup: 1. Mount an upper file system # mkdir /mnt/1 # mount /dev/sdb1 /mnt/1 # fgrep sdb /proc/mounts /dev/sdb1 /mnt/1 ext4 rw,seclabel,relatime,data=ordered 0 0 2. Bind mount it to a second directory # mkdir /mnt/b1 # mount --bind /mnt/1 /mnt/b1 # fgrep sdb /proc/mounts /dev/sdb1 /mnt/1 ext4 rw,seclabel,relatime,data=ordered 0 0 /dev/sdb1 /mnt/b1 ext4 rw,seclabel,relatime,data=ordered 0 0 3. Mount a file system below the first # mkdir /mnt/1/lower # mount /dev/sdb2 /mnt/1/lower # fgrep sdb /proc/mounts /dev/sdb1 /mnt/1 ext4 rw,seclabel,relatime,data=ordered 0 0 /dev/sdb1 /mnt/b1 ext4 rw,seclabel,relatime,data=ordered 0 0 /dev/sdb2 /mnt/1/lower xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 /dev/sdb2 /mnt/b1/lower xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 Two mount records for sdb2 were added to /proc/mounts from one mount command. Then use GParted to unmount sdb2. It reports this error dialog: +-------------------------------------+ | | | Could not unmount /dev/sdb2 | | | | # umount -v '/mnt/b1/lower' | | umount: /mnt/b1/lower: not mounted. | +-------------------------------------+ | [ OK ] | +-------------------------------------+ Fix by checking that the file system is still mounted before each unmount attempt. [1] mount (8), Description, Bind mount operation https://man7.org/linux/man-pages/man8/mount.8.html#DESCRIPTION Closes !89 - Fix unmount error when unmounting below a bind mount point 2021-09-11 Goran Vidović Update Croatian translation 2021-09-10 Balázs Úr Update Hungarian translation 2021-09-07 Andika Triwidada Add initial Indonesian translation of help (!90) Closes !90 - Add initial Indonesian translation of help 2021-09-07 Nathan Follens Update Dutch translation 2021-09-06 Aurimas Černius Updated Lithuanian translation 2021-09-05 Marek Černocký Updated Czech translation 2021-09-04 Seong-ho Cho Update Korean translation 2021-08-28 Hugo Carvalho Update Portuguese translation 2021-08-02 Mike Fleetwood Remove (N/A) from comment in FileSystem::rm_temp_dir() Extra hint of warning status being represented by enumeration constant STATUS_N_A is no longer needed since commit: 8c5c13d613474d3853d6071c5be8055d49bef5aa Rename OperationDetailStatus STATUS_N_A to STATUS_WARNING 2021-08-11 Mike Fleetwood Add missing includes to Mount_Info.cc 2021-08-11 Mike Fleetwood Reorder parameters to add_mountpoint_entry() To match the order of the members in struct MountEntry. 2021-08-11 Mike Fleetwood Extract common code into Mount_Info::lookup_uuid_or_label() (#162) Closes #162 - It is no longer possible to mount a LUKS encrypted file system 2021-08-10 Mike Fleetwood Resolve UUID= and LABEL= refs when searching Mount_Info (#162) Implemented the second half of the solution described in the previous commit. Resolve UUID= and LABEL= references when searching in the Mount_Info cache so that mount points of encrypted file systems listed in /etc/fstab can be found using the later added FS_Info details. Closes #162 - It is no longer possible to mount a LUKS encrypted file system 2021-08-10 Mike Fleetwood Load unresolved UUID= and LABEL= refs into Mount_Info cache (#162) ISSUE DETAILS GParted no longer enables Partition > Mount on, for unmounted encrypted file systems listed in /etc/fstab. Steps to reproduce: 1. Create LUKS mapping and open. # cryptsetup luksFormat /dev/sdb1 - # cryptsetup luksOpen /dev/sdb1 sdb1_crypt 2. Create any file system. # mkfs.ext4 /dev/mapper/sdb1_crypt # uuid=`blkid -o value -s UUID /dev/mapper/sdb1_crypt` 3. Add /etc/fstab entry. # mkdir /mnt/1 # echo "UUID=$uuid /mnt/1 ext4 defaults 0 0" >> /etc/fstab 4. Run GParted and try Partition > Mount on. With GParted >= 1.3 no mount point is available. With GParted <= 1.2 mount point /mnt/1 is available. EXPLANATION Up until GParted 1.2.0 it worked like this: 1. Ran blkid and loaded the details for every file system into the FS_Info cache. This included results for file systems in open LUKS mappings, such as /dev/mapper/sdb1_crypt in the above example. 2. Read /etc/fstab, resolved UUID= and LABEL= references into block device names and added those into the Mount_Info cache. 3. Looped through all partitions adding mount points known by the Mount_Info cache. After the changes for issue #131 "GParted hangs when non-named device is hung" and issue #148 "Encrypted file systems are no longer recognised" it works like this instead: 1. Runs blkid for specified devices and partitions only and loads file system details into the FS_Info cache. Does not include open LUKS mappings so no results for those file systems. 2. Loading of /etc/fstab into the Mount_Info cache is unable to resolve UUID= and LABEL= references for file systems in LUKS mappings, so they aren't included. 3. No mount points known for encrypted file systems. Note that currently when an encrypted file system is added into the data model it extends the FS_Info cache <2>, but this is after the Mount_Info cache has been loaded <1>. Call flow is like this: GParted_Core::set_devices_thread() FS_Info::clear_cache() FS_Info::load_cache_for_paths() 1> Mount_Info::load_cache() ... set_device_from_disk() set_device_one_partition() / set_device_partitions() set_luks_partition() detect_filesystem_in_encryption_mapping() 2> FS_Info::load_cache_for_paths() ... set_mountpoints() partition.add_mountpoints(Mount_Info::get_fstab_mountpoints()) SOLUTION Also save unresolved UUID= and LABEL= references from /etc/fstab into the Mount_Info cache. Then when searching the Mount_Info /etc/fstab cache resolve encountered UUID= and LABEL= references. THIS COMMIT Also save unresolved UUID= and LABEL= references into the Mount_Info cache. Closes #162 - It is no longer possible to mount a LUKS encrypted file system 2021-08-07 Fabio Tomat Update Friulian translation 2021-07-24 Mike Fleetwood Add note to README about needing gvfs to launch yelp 2021-07-24 Mike Fleetwood White space tidy-up some of DialogFeatures 2021-07-27 Mike Fleetwood Add labelling of mounted ext2/3/4 (#163)(#600496) E2label works the same way whether an ext2/3/4 file system is mounted or not, by directly reading and writing the superblock from the partition block device. (Technically the superblock will already be in the kernel device buffer cache because the kernel has the ext2/3/4 file system mounted and a reference to the superblock in the device buffer cache). This is safe and supported as confirmed here [1]. As this method has always worked, even on the oldest distributions, unconditionally enable this feature. # mkfs.ext4 -L label_1 /dev/sdb3 # mount /dev/sdb3 /mnt/3 # e2label /dev/sdb3 label_2 # blkid /dev/sdb3 /dev/sdb3: LABEL="label_2" ... [1] Is labelling a mounted ext2/3/4 file system safe and supported? https://lore.kernel.org/linux-ext4/CAMU1PDgNvW_3Jr91iii-Nh=DCuRytVG8ka3-J+a43gKwigx8Yg@mail.gmail.com/T/#u Bug 600496 - Allow changing ext2/3 label without unmounting Closes #163 - Feature request: set label on a mounted btrfs 2021-07-22 Mike Fleetwood Add labelling of mounted xfs (#163) XFS also supports labelling of the file system while it is mounted. This was added into Linux kernel 4.18 [1] and xfsprogs 4.17.0 [2]. These versions are newer than available in older but still supported distributions so we'll need to detect versions before enabling support. These are the oldest releases of distributions which meet the requirements. Distro EOL Linux kernel xfsprogs Debian 10 2024-Jun 4.19.0 4.20.0 RHEL 8 2029-May 4.18.0 5.0.0 Ubuntu 20.04 LTS 2030-Apr 5.4 5.3.0 As with btrfs a mounted XFS is labelled via it's mount point: # mkfs.xfs -L label_1 /dev/sdb2 # mount /dev/sdb2 /mnt/2 # xfs_io -c 'label -s mnt_label_2' /mnt/2 label = "mnt_label_2" # blkid /dev/sdb2 /dev/sdb2: LABEL="mnt_label_2" ... And cleared with: # xfs_io -c 'label -c' /mnt/2 label = "" Note that in some error situations xfs_io reports exit status zero and writes the failure message to stdout. # xfs_io -c 'label -s "mnt label 3"' /mnt/2 bad argument count 4 to label, expected between 0 and 3 arguments # echo $? 0 Therefore determine success based on stdout starting with 'label = "' reporting the new label or not. Also note that as seen in this failure case, it is not possible to set an XFS label which contains a space character using xfs_io. However that is nothing new as that can't be done using the existing xfs_admin command for an unmounted XFS either. # umount /mnt/2 # xfs_admin -L 'umnt label 4' /dev/sdb2 Usage: xfs_admin [-efjlpuV] [-c 0|1] [-L label] [-U uuid] device # echo $? 2 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7664b31975bd893190708e76b2c424328f0c49b xfs: implement online get/set fs label [2] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=cfa10b0f972005b38ed294bca66cebf2f65298ec xfs_io: add label command Closes #163 - Feature request: set label on a mounted btrfs 2021-07-22 Mike Fleetwood Show online file system labelling in the Features dialog (#163) Show support for online labelling using a second tick mark in the Features dialog. This matches how online grow and shrink are shown. Closes #163 - Feature request: set label on a mounted btrfs 2021-07-22 Mike Fleetwood Add labelling of mounted btrfs (#163) Btrfs supports labelling of the file system while it is mounted. This was added into Linux kernel 3.10 [1] and btrfs-progs 3.12 [2]. As the oldest supported distributions have the needed versions or newer, unconditionally enable without any checking for availability. Distro EOL Linux kernel btrfs-progs Debian 9 2022-Jun 4.19 4.7.3 RHEL / CentOS 7 2024-Jun 3.10.0 4.9.1 Ubuntu 18.04 LTS 2023-Apr 4.15.0 4.15.1 Unmounted btrfs is labelled via the block device containing it, where as a mounted btrfs is labelled via it's mount point. # mkfs.btrfs -L initial_label /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: LABEL="initial_label" ... # btrfs filesystem label /dev/sdb1 unmounted_label_2 # blkid /dev/sdb1 /dev/sdb1: LABEL="unmounted_label_2" ... # mount /dev/sdb1 /mnt/1 # btrfs filesystem label /dev/sdb1 mounted_label_3 # blkid /dev/sdb1 /dev/sdb1: LABEL="mounted_label_3" ... [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a8bfd4abea3da0e28f215e2a2b8c2f1ca27ebe80 Btrfs: set/change the label of a mounted file system [2] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=619dc61cae1420da2dec48f689d49b9b346abc15 Btrfs-progs: Change the label of a mounted file system Closes #163 - Feature request: set label on a mounted btrfs 2021-07-19 Curtis Gedak Append -git to version for continuing development 2021-07-19 Curtis Gedak ========== gparted-1.3.1 ========== 2021-07-15 Philipp Kiemle Update German translation 2021-07-14 Wolfgang Stöggl Update German translation 2021-07-14 Claude Paroz Updated French translation 2021-07-14 Ngọc Quân Trần Update Vietnamese translation 2021-07-13 Daniel Șerbănescu Update Romanian translation 2021-07-13 Daniel Mustieles Updated Spanish translation 2021-07-12 Enrico Nicoletto Update Brazilian Portuguese translation 2021-07-12 Baurzhan Muftakhidinov Update Kazakh translation 2021-06-03 Mike Fleetwood Copy XFS UUID when copying the file system (!85) For the same reason as in the previous commit, the UUID is copied when copying every file system type except for XFS, where a new XFS is created with a new UUID. Again preview of the copy operation expects the UUID to be copied. (Look in Partition > Information of the source and pasted partitions before the operation is applied). Fix as before by specifying the desired file system UUID when creating the new XFS as part of the copy operation. However there is an extra complication. The XFS kernel driver refuses to mount a file system with a duplicate UUID of an already mounted XFS. # mkfs.xfs -L xfs_copy /dev/sdb1 # mount /dev/sdb1 /mnt/1 # tail -2 /var/log/messages Jun 3 21:41:24 localhost kernel: XFS (sdb1): Mounting V5 Filesystem Jun 3 21:41:24 localhost kernel: XFS (sdb1): Ending clean mount # /dev/sdb1: LABEL="xfs_copy" UUID="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" TYPE="xfs" # mkfs.xfs -L xfs_copy -m uuid="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" /dev/sdb2 # mount /dev/sdb2 /mnt/2 mount: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. In some cases useful info is found in syslog - try dmesg | tail or so. # echo $? 32 # tail -1 /var/log/messages Jun 3 21:41:31 localhost kernel: XFS (sdb2): File system has duplicate UUID d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8 - can't mount Handle this specifying the needed option [1] when mounting the second XFS during the copy. # mount -o nouuid /dev/sdb2 /mnt/2 # mount | grep /dev/sdb /dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,attr2,inode64,noquota) /dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,noquota) Duplicating the UUID may seem troublesome, but it is being done: 1. To make the GParted copied XFS be as much a clone as possible, to match what is does with other file systems. 2. It has a valid use case; of cloning a Linux installation to a new drive or restoring a partition image backup. In these cases it is much simpler if the UUID of the copy remains the same because it avoids having to edit GRUB2 configuration and fstab file system mounting which is nearly always done via UUID. 3. GParted has the new UUID operation, to change the UUID for cases when a copied file system needs to be mounted at the same time as the source. [1] xfs(5) - xfs - layout, mount options, and supported file attributes for the XFS filesystem https://man7.org/linux/man-pages/man5/xfs.5.html "MOUNT OPTIONS ... nouuid Don't check for double mounted file systems using the file system uuid. " Closes !85 - Make XFS copy duplicate the file system label and UUID 2021-05-27 Mike Fleetwood Copy XFS label when copying the file system (!85) As GParted performs block copy of partitions then the label, which is stored in the file system superblock, is also copied. This is true for copies performed using the GParted internal block copy and for EXT2/3/4 and NTFS which are copied using the file system specific commands e2image and ntfsclone respectively. However when an XFS file system is copied the label is not copied because a new file system is created using mkfs.xfs and the files copied using xfsdump | xfsrestore. Preview of the copy operation in GParted also reflects the fact that the label will be copied. Fix this by simply specifying the desired label when creating the new destination XFS. Closes !85 - Make XFS copy duplicate the file system label and UUID 2021-05-29 Curtis Gedak Handle change in path for udisks2-inhibit executable (!84) Debian (and derived) distros with the udisks2 [1] repository and the additional 'udisks2-inhibit' executable had the location changed from: /usr/lib/udisks2/ to: /usr/libexec/udisks2/ with udisks2 version 2.8.4-2 and the following commit: f6744a33 - Move the daemons to /usr/libexec now that's allowed in the policy https://salsa.debian.org/utopia-team/udisks2/-/commit/f6744a3364eafdb07e3e78e329f202394804c574 Distros such as Fedora and openSUSE are unaffected as the udisks [2] repository does not contain 'udisks2-inhibit'. [1] udisks2 Debian (and derived) repository https://salsa.debian.org/utopia-team/udisks2 [2] udisks repository https://github.com/storaged-project/udisks Closes !84 - Handle change in path for udisks2-inhibit executable 2021-05-31 Andika Triwidada Update Indonesian translation 2021-05-23 Rafael Fontenelle Update Brazilian Portuguese translation 2021-05-23 Piotr Drąg Update Polish translation 2021-05-18 Mike Fleetwood Fix recognition of SD/MMC device names (!83) User reported that GParted didn't detect their eMMC drive [1]. Not recognised device name was /dev/mmcblk0. Confirmed that the regression was introduced by this commit [2]. Fix the code and regular expression used to recognise SD/MMC device names. [1] GParted forum thread: eMMC drive not detected...? http://gparted-forum.surf4.info/viewtopic.php?id=17994 [2] 52930f30ae8dc2c9dd1f64d2df654d9f1a1afb8a Refactor load_proc_partitions_info_cache() a bit (#131) Closes !83 - Fix recognition of SD/MMC device names 2021-05-19 Yuri Chornoivan Update Ukrainian translation 2021-05-18 Anders Jonsson Update Swedish translation 2021-05-15 Curtis Gedak Replace deprecated gtk_show_uri() method for help window (!82) The gtk_show_uri() [1] method was deprecated as of gtk3 version 3.22 and has been replaced with gtk_show_uri_on_window [2]. [1] https://developer.gnome.org/gtk3/stable/gtk3-Filesystem-utilities.html#gtk-show-uri [2] https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.7 Note that AppInfo::launch_uris() has been removed because with glib/glibmm >= 2.58 AppInfo::launch_uris() always reports success even when yelp is not launched and in such cases prevents the dialog reporting the error from being displayed. Closes !82 - Replace deprecated gtk_show_uri() method for help window 2021-05-17 Seong-ho Cho Update Korean translation 2021-05-11 Ask Hjorth Larsen Updated Danish translation 2021-05-04 Hugo Carvalho Update Portuguese translation 2021-05-03 Curtis Gedak Append -git to version for continuing development 2021-05-03 Curtis Gedak ========== gparted-1.3.0 ========== 2021-05-01 Jiri Grönroos Update Finnish translation 2021-05-01 Piotr Drąg Update Polish translation 2021-04-27 Ngọc Quân Trần Update Vietnamese translation 2021-04-26 Fran Dieguez Update Galician translation 2021-04-26 Kukuh Syafaat Update Indonesian translation 2021-04-26 Fran Dieguez Update Galician translation 2021-04-26 Hannie Dumoleyn Update Dutch translation 2021-04-26 Hannie Dumoleyn Update Dutch translation 2021-04-26 Daniel Mustieles Updated Spanish translation 2021-04-26 Daniel Mustieles Updated Spanish translation 2021-04-26 Baurzhan Muftakhidinov Update Kazakh translation 2021-04-25 Claude Paroz Updated French translation 2021-04-25 Rafael Fontenelle Update Brazilian Portuguese translation 2021-04-25 Daniel Șerbănescu Update Romanian translation 2021-04-25 Yuri Chornoivan Update Ukrainian translation 2021-04-25 Daniel Șerbănescu Update Romanian translation 2021-04-25 Anders Jonsson Update Swedish translation 2021-04-03 Mike Fleetwood Mark remaining get_filesystem_*() methods as returning const strings 2021-04-03 Mike Fleetwood Comment differences between FileSystem::execute_command() methods 2021-04-02 Mike Fleetwood Report this LUKS passphrase request reason as resize (#59) So far when prompting for the LUKS passphrase the dialog always looks like this: +------------------------------------------------+ | LUKS Passphrase /dev/sdb1 | +------------------------------------------------+ | Enter LUKS passphrase to open /dev/sdb1 | | Passphrase: [ ] | | | | | | [ Cancel ] [ Unlock ] | +------------------------------------------------+ Specifically the first line of the dialog says the reason to provide the passphrase is to open the encryption mapping. Now the passphrase may also be requested when resizing the encryption mapping, as part of a resize of check operation, show the appropriate reason in the password dialog. Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-04-07 Mike Fleetwood Also prompt for LUKS password as required for check operation (#59) A check operation involves (1) checking the file system, (2) growing the encryption volume and (3) growing the file system. Therefore prompt for the LUKS passphrase as required when composing a check operation too. Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-04-03 Mike Fleetwood Pass LUKS password as needed when resizing open mapping (#59) This is the final piece which enables GParted to pass the LUKS passphrase when resizing an open LUKS encryption mapping when 'cryptsetup resize' will prompt for it. Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-04-03 Mike Fleetwood Add ability for small writes to stdin of operation tracked child processes (#59) This is the equivalent to what was previously done when adding opening of LUKS mappings. Namely to add a way to pass the LUKS passphrase to 'cryptsetup luksOpen' via standard input. Previously the functionality was added to Utils::execute_command() [1]. Now it is also needed to pass the LUKS passphrase to 'cryptsetup resize', which is executed as part of applying resize and check operations to an encrypted file system. So add this functionality to FileSystem::execute_command(). For now writing to stdin is only needed for the one variant of FileSystem::execute_command() which doesn't have progress tracking callbacks. Writing to stdin can easily be added to the other progress tracking callback variants of execute_command() when needed. [1] 8dff80edc65b2923b400ddadebacf9bcf378d09f Add ability for small writes to stdin of child processes (#795617) Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-04-03 Mike Fleetwood Extract common code into generate_encryption_mapping_name() (#59) Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-03-26 Mike Fleetwood Ask for LUKS passphrase for resize operation as required (#59) When composing a resize operation on an open encryption mapping, use the existing LUKS password dialog to prompt for the passphrase, if and only if 'cryptsetup resize' will prompt and GParted doesn't already have a password. 'cryptsetup resize' will prompt for a LUKS passphrase when the passphrase was stored in the kernel keyring service, key_loc == KEYLOC_KeyRing. See the previous commit "Capture LUKS mapping master encryption key location (#59)" for more details. As commented in the code GParted specifically doesn't support the case where the LUKS passphrase is changed while GParted is running and it knew the old passphrase. When resizing an open encryption mapping GParted will just pass the old out of date passphrase it knows and the resize will fail like this: # cryptsetup status sdb2_crypt | egrep 'type|key location' type: LUKS2 key location: keyring # dmsetup table --target crypt sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768 # echo -n oldpassword | cryptsetup -v --size 491520 resize sdb2_crypt No key available with this passphrase. Command failed with code -2 (no permission or bad passphrase). # echo $? 2 To work around this either close and restart GParted or close and reopen the encryption mapping. The former because GParted doesn't save passwords across a restart so will prompt and the latter because GParted will use the wrong old passphrase to try to open the mapping and then prompt for the correct passphrase until successfully opened. Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-03-26 Mike Fleetwood Capture LUKS mapping master encryption key location (#59) ISSUE OVERVIEW When GParted tries to resize an open LUKS encryption mapping and the volume (master) key was stored in the kernel keyring service [1] it fails like this: Check and repair file system ([Encrypted] ext4) on /dev/...(ERROR) + calibrate /dev/sdd1 (SUCCESS) + check file system on /dev/mapper/sdd1_crypt for errors...(SUCCESS) + grow encryption volume to fill the partition (ERROR) + cryptsetup -v resize 'sdd1_crypt' (ERROR) Command failed with code -1 (wrong or missing parameters). Nothing to read on input. This error occurs with cryptsetup >= 2.0, kernel >= 4.10 and LUKS2 format because the crypt Device-Mapper target no longer has the volume key so cryptsetup resize prompts for a passphrase, but GParted doesn't provide it. THIS COMMIT Additionally capture the location of the volume (master) key location for active encryption mappings. Do this the using the same method that cryptsetup uses [2][3]. Namely if the first character of the KEY is a ":" then the key *was* stored in the kernel keyring service, otherwise it *is* store in the Device-Mapper crypt target as previously. # echo -n badpassword | cryptsetup luksFormat --type luks1 /dev/sdb1 - # echo -n badpassword | cryptsetup luksOpen /dev/sdb1 sdb1_crypt # cryptsetup status sdb1_crypt | egrep 'type|key location' type: LUKS1 key location: dm-crypt # echo -n badpassword | cryptsetup luksFormat --type luks2 /dev/sdb2 - # echo -n badpassword | cryptsetup luksOpen /dev/sdb2 sdb2_crypt # cryptsetup status sdb2_crypt | egrep 'type|key location' type: LUKS2 key location: keyring # dmsetup table --target crypt sdb1_crypt: 0 520192 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:17 4096 sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768 ^ First character of the KEY field --------------' [1] Integration with the kernel keyring service https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/Keyring.txt " Starting with cryptsetup 2.0 we load [Volume Key] VK in kernel keyring by default for LUKSv2 devices ... In summary, the key description visible in dm-crypt table line is a reference to VK that usually no longer exists in kernel keyring service if you used cryptsetup to for device activation. " [2] cryptsetup/v2.3.5/lib/libdevmapper.c:_dm_target_query_crypt() https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/lib/libdevmapper.c#L2031 if (key_[0] == ':') *act_flags |= CRYPT_ACTIVATE_KEYRING_KEY; [3] cryptsetup/v2.3.5/src/cryptsetup.c:action_status() https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/src/cryptsetup.c#L839 log_std(" key location: %s\n", (cad.flags & CRYPT_ACTIVATE_KEYRING_KEY) ? "keyring" : "dm-crypt"); Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing to read on input" 2021-04-11 Mike Fleetwood Ignore libparted unrecognised disk label message from encryption mappings (#152) When GParted probes an open encryption mapping which is either blank or contains a file system which libparted doesn't recognise, such as: exfat, f2fs, lvm2 pv, minix or reiser4, then the partition also gets this warning message: /dev/mapper/sdb11_crypt: unrecognised disk label Clear the message so that it isn't shown in the GUI. Note that the message is still written to stderr by GParted, like all libparted exceptions are. This is done by GParted's libparted exception handler: GParted_Core::ped_exception_handler() _ped_exception_handler() Closes #152 - GParted crashed when trying to probe an encrypted partition containing content that libparted doesn't recognise 2021-04-10 Mike Fleetwood Reorder cases in set_device_and_disk() and use if fail return early (#152) The previous commit "Resolve empty drive displayed as blank minor logic issue (#152)" left the code in set_device_and_disk() some what unsightly. Refactor the whole function. Use if fail return early pattern for failure of the get_device() call at the start of the function. Reorder the 4 cases into a single depth if then else if chain. Hopefully this is a little easier to follow. Closes #152 - GParted crashed when trying to probe an encrypted partition containing content that libparted doesn't recognise 2021-04-10 Mike Fleetwood Resolve empty drive displayed as blank minor logic issue (#152) The previous commit "Remove coding landmine in get_disk() (#152)" made an empty drive without a disk label (partition table) display as nothing, instead of the normal single unallocated partition with warning "unrecognised disk label". The previous commit said: 3. The two remaining direct calls to get_disk() where the strict parameter is explicitly set to false, from set_device_from_disk() and detect_filesystem_in_encryption_mapping(), are when scanning. As the pass strict=false they don't allow the PedDevice deletion to occur if no recognised disk label is found. This is true, but get_disk(..., strict=false) additionally returned true even if there was no disk label. And in set_device_from_disk() the empty drive case is inside the if branch of the get_disk() call returning true. Simply fix this by calling get_disk(), ignoring the return value. Closes #152 - GParted crashed when trying to probe an encrypted partition containing content that libparted doesn't recognise 2021-04-10 Mike Fleetwood Remove coding landmine in get_disk() (#152) get_disk() is the wrapper around libparted's ped_disk_new() which reads a disk label from the specified device and if successful creates the in memory PedDisk object to represent it. In the case that libparted doesn't recognise a disk label or a file system, having get_disk() go and destroy the passed in PedDevice object via parameter lp_device is very unexpected behaviour hence describing it as a coding landmine. BACKGROUND 1. Early on GParted only worked with devices with valid disk labels. FileSystem.h:open_device_and_disk() required both ped_device_get() and ped_disk_new() to succeed or neither to succeed. 2. Commit [1] added support for devices which didn't yet have a disk label. open_device_and_disk() had default parameter strict=true added. While scanning strict=false was passed which allowed open_device_and_disk() to return success if only ped_device_get() succeeded and ped_disk_new() failed when the disk was empty. All other times open_device_and_disk() was called with default strict=true, still requiring both or neither to succeed. 3. Commit [2] added support for whole disk file systems. The now named get_device_and_disk() had it's functionality split between get_device() and get_disk(). This result in the code landmine being left behind: get_disk() destroying the passed device object if default parameter strict=true and no disk label or file system was detected. ANALYSIS 1. Since support for whole disk file systems [2] all current calls to get_device_and_disk() let the strict parameter default to true and are only called on known partitions within disk labels when applying a change to that partition. Therefore they don't care about the behaviour of get_disk(), just that get_device_and_disk() maintains that both ped_device_get() and ped_disk_new() succeed or neither succeed. 2. Two direct calls to get_disk() where the strict parameter defaults to true, from calibrate_partition() and erase_filesystem_signatures(), only do so on known partitions within disk labels as part of applying a change to that partition. Therefore ped_disk_new() will succeed and so PedDevice isn't deleted when not wanted. 3. The two remaining direct calls to get_disk() where the strict parameter is explicitly set to false, from set_device_from_disk() and detect_filesystem_in_encryption_mapping(), are when scanning. As the pass strict=false they don't allow the PedDevice deletion to occur if no recognised disk label is found. FIX Remove the strict parameter from get_disk() and get_device_and_disk() as it's no longer needed. Remove the code landmine by removing the side affect of destroying the PedDevice object if a disk label isn't found. Make sure get_device_and_disk() maintains the all or nothing behaviour. Also don't pass lp_device by reference to a pointer to get_disk() so the code can't change where lp_device points. [1] 038c5c5d99ad842f1a57f12222c884be29f4df4f P (special thanks to mantiena-baltix for bringing this issue to my [2] 51ac4d56489653854cd22787238a14bfa66a6ad4 Split get_device_and_disk() into two (#743181) Closes #152 - GParted crashed when trying to probe an encrypted partition containing content that libparted doesn't recognise 2021-04-10 Mike Fleetwood Correctly const and assert detect_filesystem() parameters (#152) As discussed in the previous commit "Don't crash probing libparted unrecognised encrypted file system (#152)", detect_filesystem() accepted a NULL lp_device pointer and dereferenced it leading to the crash. Document the requirement for lp_device parameter to be non-NULL via an assert and also correctly const the parameters. This forces needing to const the lp_partition parameter to get_partition_path() too. Also assert it's non-NULL requirement. Closes #152 - GParted crashed when trying to probe an encrypted partition containing content that libparted doesn't recognise 2021-04-08 Mike Fleetwood Don't crash probing libparted unrecognised encrypted file system (#152) Create a LUKS encrypted partition and open it. Then either leave the contents blank or create a file system which libparted doesn't recognise, such as: exfat, f2fs, lvm2 pv, minix or reiser4. When GParted probes the disk device it crashes. # echo -n badpassword | cryptsetup luksFormat /dev/sdb11 # echo -n badpassword | cryptsetup luksOpen /dev/sdb11 sdb11_crypt # ./gpartedbin /dev/sdb GParted 1.2.0-git configuration (none) libparted 3.1 /dev/mapper/sdb11_crypt: unrecognised disk label Segmentation fault (core dumped) Backtrace: #0 0x0000000000460f68 in GParted::GParted_Core::detect_filesystem(_PedDevice*, _PedPartition*, std::vector >&) (lp_device=0x0, lp_partition=0x0, messages=std::vector of length 0, capacity 0) at GParted_Core.cc:1235 #1 0x00000000004615a6 in GParted::GParted_Core::detect_filesystem_in_encryption_mapping(Glib::ustring const&, std::vector >&) (path=..., messages=std::vector of length 0, capacity 0) at GParted_Core.cc:1096 #2 0x00000000004647c8 in GParted::GParted_Core::set_luks_partition(GParted::PartitionLUKS&) (this=this@entry=0x7fff43f974e0, partition=...) at GParted_Core.cc:1011 #3 0x000000000046511b in GParted::GParted_Core::set_device_partitions(GParted::Device&, _PedDevice*, _PedDisk*) (this=this@entry=0x7fff43f974e0, device=..., lp_device=0x7efc780008c0, lp_disk=0x7efc78000d10) at GParted_Core.cc:883 #4 0x00000000004658e3 in GParted::GParted_Core::set_device_from_disk(GParted::Device&, Glib::ustring const&) (this=this@entry=0x7fff43f974e0, device=..., device_path=...) at GParted_Core.cc:704 #5 0x0000000000465fff in GParted::GParted_Core::set_devices_thread(std::vector >*) (this=0x7fff43f974e0, pdevices=0x7fff43f96bc8) at GParted_Core.cc:266 #6 0x00007efc99ba413d in call_thread_entry_slot () at /lib64/libglibmm-2.4.so.1 #7 0x00007efc97dc8555 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #8 0x00007efc96ab4ea5 in start_thread () at /lib64/libpthread.so.0 #9 0x00007efc967dd9fd in clone () at /lib64/libc.so.6 The relevant sequence of events goes like this: detect_filesystem_in_encryption_mapping(path, ...) lp_device = NULL get_device(path, lp_device) lp_device = ped_device_get(path.c_str()) return true lp_disk = NULL lp_partition = NULL get_disk(lp_device, lp_disk) // + default parameter strict=true lp_disk = ped_disk_new(lp_device) // No libparted recognised disk label or file system found, so // NULL returned. destroy_device_and_disk(lp_device, lp_disk) ped_device_destroy(lp_device) lp_device = NULL return false detect_filesystem(lp_device, lp_partition, ...) path = lp_device->path The key points are: 1. get_device() created a PedDevice object pointed to by lp_device; 2. get_disk() didn't find a libparted recognised disk label or file system but also unexpectedly destroyed the PedDevice object and assigned NULL to lp_device; 3. detect_filesystem() dereferenced lp_device assuming it was still valid. Implement the simplest possible fix by telling get_disk() to not destroy the needed PedDevice object when there's no recognised content. This is the same as how get_disk() is called in set_device_from_disk(). Closes #152 - GParted crashed when trying to probe an encrypted partition containing content that libparted doesn't recognise 2021-04-14 Hugo Carvalho Update Portuguese translation 2021-03-29 Mike Fleetwood Also use libparted to probe for encrypted file systems (#148) Even though blkid is considered mandatory [1] GParted should still perform reasonably when blkid is not available, provided that is not too onerous a task. Also use libparted file system identification inside encryption mappings. [1] 749a2495716a82a7287fad943109b6cfb927245c Document blkid command as a mandatory requirement (#753436) Closes 148 - Encrypted file systems are no longer recognised 2021-03-29 Mike Fleetwood Probe encryption mappings as needed using blkid (#148) GParted no longer recognises file systems inside LUKS encryption, apart from the few recognised by GParted's internal detection. Bisected to this commit: 8b35892ea59958aa1eec596a48a36b0fa7950dca Pass device and partition names to blkid (#131) Prior to this commit blkid was run querying all known block devices including active encryption mappings, hence prior recognition. With this commit blkid was run only for named or found disk devices and associated found partitions from /proc/partitions, so no more recognition of encrypted file systems. Fix by running blkid on the encryption mapping just before querying for the file system. This restores the level of functionality that existed before. Closes 148 - Encrypted file systems are no longer recognised 2021-03-29 Mike Fleetwood Extract some code into detect_filesystem_in_encryption_mapping() (#148) To avoid making set_luks_partition() more complicated extract the file system detection portion into a new function. Closes 148 - Encrypted file systems are no longer recognised 2021-03-29 Mike Fleetwood Make FS_Info (blkid) cache incrementally loadable (#148) Since changes for issue #131 "GParted hangs when non-named device is hung" FS_Info cache is initialised, cleared and loaded via one call to load_cache_for_paths(). It runs blkid for named or found disk devices and associated found partitions from /proc/partitions, rather than running blkid and letting it report for all block devices. To avoid the possibility of using blkid on an encryption mapping on a non-specified and possibly hung block device GParted can't just specify all encryption mappings. Instead only encryption mappings which belong to the above identified block devices should be probed. That requires identifying LUKS encryption data in the block devices first so will require subsequently loading additional data into the FS_Info cache and running blkid again. To accommodate this make the FS_Info cache incrementally loadable, rather than doing everything in a single call to load_cache_for_paths(). Have a separate clear_cache() call which initialises and clears the cache and make load_cache_for_paths() just run blkid and insert data for the named paths. Closes 148 - Encrypted file systems are no longer recognised 2021-04-02 Nathan Follens Update Dutch translation 2021-03-27 Anders Jonsson Update Swedish translation 2021-03-25 Hugo Carvalho Update Portuguese translation 2021-03-19 Mike Fleetwood Update HACKING file with coding style hints and tips 2021-03-20 Mike Fleetwood Explicitly read the reiser4 volume UUID when present Reiser4 has introduced new disk format which includes support for spanning the file system over multiple block devices (subvolumes) [1][2]. As such the output of the debugfs.reiser4 for the UUID has changed slightly. So far the new reiser4progs package (version 2.0.x) is only available as a Debian experimental package. Using reiser4progs 1.2.1 the old output was like this: $ debugfs.reiser4 test.img debugfs.reiser4 1.2.1 Format release: 4.0.2 Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING. Master super block (16): magic: ReIsEr4 blksize: 4096 format: 0x0 (format40) uuid: 1116afce-99fd-4a6e-94cb-2d9f19c91d67 label: ... With reiser4progs 2.0.4 the new output is like this: $ debugfs.reiser4 test.img debugfs.reiser4 Package Version: 2.0.4 Software Framework Release: 5.1.3 Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING. Master super block (16): magic: ReIsEr4 blksize: 4096 volume: 0x1 (asym) distrib: 0x1 (fsx32m) format: 0x1 (format41) description: Standard layout for logical volumes. stripe bits: 14 mirror id: 0 replicas: 0 volume uuid: 9538bfa3-5694-4abe-864c-edc288a9d801 subvol uuid: d841c692-2042-49e6-ac55-57e454691782 label: ... GParted happens to read the correct UUID just because the first matching "uuid" string in the output is the volume UUID. Make the code more robust by explicitly reading the volume uuid when labelled as such. [1] Logical Volumes Howto https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Howto [2] Logical Volumes Background https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Background 2021-03-20 Mike Fleetwood Refactor reiser4::read_uuid() into if fail return early pattern 2021-03-18 Mike Fleetwood Ignore test failure when reiser4 reports null UUID (#145) The GitLab CI ubuntu_test job has occasionally been failing like this, perhaps once every few weeks or so. [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 test_SupportedFileSystems.cc:569: Failure Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4, where GetParam() = 24 (17 ms) [----------] 1 test from My/SupportedFileSystemsTest (17 ms total) Turns out there are 2 bugs in resier4progs. One causes debugfs.reiser4 to report a null UUID if the first byte of the UUID happens to be zero [1], and the other cases mkfs.resier4 to write a corrupted UUID, sometimes a null (all zeros) UUID [2]. There is a 1 in 256 chance of getting a null UUID [2] when creating and reading a reiser4 file system, hence the occasional failure of the CI job. The centos_test job isn't affected because CentOS doesn't have the reiser4progs package. Fix this by detecting when reiser4 reports a null UUID and assign a dummy UUID to make the test pass. This does mean that there is a 1 in 256 chance of not detecting a true failure. However that still means there is a 255 in 256 chance of detecting a true failure. That's good odds. When a null UUID is detected for a reiser4 file system the test output looks like this: [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 test_SupportedFileSystems.cc:580: Ignore test failure of a null UUID. [ OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 (46 ms) [1] https://github.com/edward6/reiser4progs/commit/4802cdb18ae03031d0e51a58b6655f3b99021ec2 Fix up repair_master_print() [2] https://github.com/edward6/reiser4progs/commit/44cc024f398f60adef1519426d65f3f081ee826a Stop occasionally making file systems with null UUIDs Closes #145 - Sporadic failure of test case My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 2021-03-13 Jordi Mas Update Catalan translation 2021-03-08 Mike Fleetwood Print kernel version, etc in GitLab CI (#147) Print the kernel version and supported file systems inside the GNOME GitLab CI jobs as a debugging aid. Kernel version helps identify the CI job runner's distribution to identify kernel features. Supported file systems identifies which ones can be mounted, should that be possible in future. Print supported file systems before and after the tests because checking for support may load additional modules. See calls to Utils::kernel_supports_fs() for: btrfs, jfs, nilfs2 and xfs. Closes #147 - GitLab CI test failure from *.CreateAndGrow/jfs 2021-03-08 Mike Fleetwood Exclude more GitLab CI file system tests needing loop devices (#147) For the first time ever the ubuntu_test GitLab CI job failed running the JFS grow test like this. Fragment from tests/test-suite.log: [ RUN ] My/SupportedFileSystemsTest.CreateAndGrow/jfs test_SupportedFileSystems.cc:387: Failure Failed create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img' losetup: cannot find an unused loop device create_loopdev(): Losetup failed with exit status 1 create_loopdev(): Failed to create required loop device Error: Could not stat device - No such file or directory. test_SupportedFileSystems.cc:446: Failure Value of: lp_device != NULL Actual: false Expected: true test_SupportedFileSystems.cc:649: Failure Value of: m_fs_object->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.jfs -q -L '' '' 00:00:00 (ERROR) mkfs.jfs version 1.1.15, 04-Mar-2011 The system cannot find the specified device. detach_loopdev(): Execute: losetup --detach '' losetup: : failed to use device: No such device detach_loopdev(): Losetup failed with exit status 1 detach_loopdev(): Failed to detach loop device. Test NOT affected [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/jfs, where GetParam() = 17 (24 ms) JFS can only be grown when mounted by the kernel and GParted only enables JFS grow support when, among other things, kernel support is detected. Unknowingly the JFS grow test had always previously been skipped, even in the ubuntu_test CI job which installs jfsutils, because the kernel didn't support JFS. Capture of this test from another run of the ubuntu_test CI job: [ RUN ] My/SupportedFileSystemsTest.CreateAndGrow/jfs test_SupportedFileSystems.cc:641: Skip test. grow not supported or support not found [ OK ] My/SupportedFileSystemsTest.CreateAndGrow/jfs (0 ms) Plus additional debug added into the job based on what Utils::kernel_supports_fs() does to identify kernel support: $ fgrep jfs /proc/filesystems || true $ modprobe jfs || true modprobe: FATAL: Module jfs not found in directory /lib/modules/3.10.0-1160.11.1.el7.x86_64 $ fgrep jfs /proc/filesystems || true Therefore until now every GitLab job runner machine kernel didn't support JFS, but for the first time ever this ubuntu_test job ran on a runner machine where the kernel did support JFS, hence the attempt to use losetup. Examining test_SupportFileSystems.cc there are 24 file system tests which specify SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS(), but only 17 exclusions in .gitlab-ci.yaml [1]. The 7 tests without exclusions are: *.CreateAndReadLabel/lvm2pv *.CreateAndReadUUID/lvm2pv *.CreateAndWriteLabel/lvm2pv *.CreateAndWriteUUID/lvm2pv *.CreateAndGrow/jfs *.CreateAndGrow/nilfs2 *.CreateAndShrink/nilfs2 For LVM2 PVs reading and writing of labels and UUIDs aren't implemented (only reading of UUIDs could be supported as the others are impossible) so those tests are always skipped. Add unit test exclusions just for completeness. JFS grow is this case. NILFS2 grow and shrink are more cases where kernel support is needed. Add unit test exclusions to stop attempting to run JFS and NILFS2 resizing tests, which don't currently work because losetup doesn't work in the GitLab CI docker images [1]. [1] 39fdfe51da4bddecb2c99a9b544b270130423e72 Exclude unit tests needing losetup in Docker CI image (!59) Closes #147 - GitLab CI job failure from *.CreateAndGrow/jfs 2021-03-06 Mike Fleetwood Pass constant string by reference to lvm2_pv_size_to_num() It is common C++ practice to pass a constant object by reference to avoid constructing a duplicate object for pass by value [1]. [1] How to pass objects to functions in C++? https://stackoverflow.com/questions/2139224/how-to-pass-objects-to-functions-in-c/2139254#2139254 2021-03-01 Mike Fleetwood Install gpartedbin into @libexecdir@ (#85) Executables which are not intended for execution by users, but by other programs, should be installed into /usr/libexec [1][2]. gpartedbin falls into this category. Update it's installation accordingly. Standard Autotools details: gpartedbin will be installed into EPREFIX/libexec by default. To install gpartedbin into a different directory set libexecdir when configuring the build system. Like this from git: ./autogen.sh --libexecdir=DIR or like this from tar release: ./configure --libexecdir=DIR [1] Filesystem Hierarchy Standard, version 3.0, 4.7. /usr/libexec : Binaries run by other programs (optional) https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html "/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. " [2] GNU Coding Standards, June 12, 2020, 7.2.5 Variables for Installation Directories https://www.gnu.org/prep/standards/html_node/Directory-Variables.html "libexecdir The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be /usr/local/libexec, but write it as $(exec_prefix)/libexec. (If you are using Autoconf, write it as '@libexecdir@'.) " Closes #85 - Please install gpartedbin under /usr/libexec instead of /usr/sbin 2021-03-08 Aurimas Černius Updated Lithuanian translation 2021-03-05 Kukuh Syafaat Update Indonesian translation 2021-02-23 Mike Fleetwood Update "Detecting BitLocker" URL code comment The document has moved on the Microsoft website. Update the URL accordingly, and add an Internet Archive URL too, for good measure. 2021-02-28 Mike Fleetwood Rename member variable to default_fs ... in class Dialog_Partition_New and slightly refactor the code in build_filesystems_combo() method which sets it. Change the name from first_creatable_fs to default_fs to be more immediately obvious what the variable represents. As default_fs is used to index the items in the combo_filesystem derived ComboBox, make it's type an int to match the type of the parameter passed to Gtk::ComboBox::set_active() [1]. Initialise default_fs to -1 (no selection) in the class constructor [2], which also allows removal of local variable set_first just used to track whether first_creatable_fs had been assigned yet or not. [1] gtkmm: Gtk::ComboBox Class Reference, set_active() https://developer.gnome.org/gtkmm/stable/classGtk_1_1ComboBox.html#a4f23cf08e85733d23f120935b235096d [2] C++ FAQ / Should my constructors use "initialization lists" or "assignment"? https://isocpp.org/wiki/faq/ctors#init-lists 2021-02-28 Mike Fleetwood Don't rely on unformatted being the last file system type ... in Dialog_Partition_New::build_filesystems_combo(). set_data() populates this->FILESYSTEMS[] vector with supported file systems with cleared, unformatted and extended added to the end. Then build_filesystems_combo() adds those items to combo_filesystem, skipping extended. It then makes the last item in the combobox sensitive, relying on the fact that it is unformatted. Refactor the code so build_filesystems_combo() no longer relies on unformatted being the last item in combo_filesystem to always enable it. 2021-02-28 Mike Fleetwood Remove unnecessary call to combobox_changed(false) ... in Dialog_Partition_New::set_data(). As the change signal for combo_filesystem has already been connected, combo_changed(false) is automatically called by setting the active selection. Therefore remove the unnecessary call. 2021-02-28 Mike Fleetwood Rename combobox_change() parameter to combo_type_changed "Type" was rather a generic name. Use "combo_type_changed" which makes it clear that the boolean parameter indicates whether a change to combo_type or one of the other ComboBoxes triggered this callback. 2021-02-28 Mike Fleetwood Fix crash in Create New Partition dialog when changing type (#101) On an MSDOS partitioned drive, open the Create New Partition dialog and change "created as" from Primary Partition to Extended Partition and back to Primary Partition. On Fedora and RHEL/CentOS 8, which builds packages with FORTIFY_SOURCE [1][2] and GLIBXX_Assertions [3][4] enabled, GParted will crash. Run GParted built with the default compilation options under valgrind and repeat the test. Multiple out of bounds reads are reported like this: # valgrind --track-origins=yes ./gpartedbin ... ==232613== Invalid read of size 8 ==232613== at 0x441AF6: GParted::Dialog_Partition_New::combobox_changed(bool) (Dialog_Partition_New.cc:354) ==232613== by 0x443DBD: sigc::bound_mem_functor1::operator()(bool const&) const (mem_fun.h:2066) Coming from Dialog_Partition_New.cc: 328 void Dialog_Partition_New::combobox_changed(bool type) 329 { ... 351 // combo_filesystem and combo_alignment 352 if ( ! type ) 353 { > 354 fs = FILESYSTEMS[combo_filesystem.get_active_row_number()]; When the partition type is changed to Extended the file system is forced to be "Extended" too. This is done in ::combobox_changed() method by modifying combo_filesystem to add "Extended", making that the selected item and setting the widget as inactive. Then when the partition type is changed back to primary the file system combobox is returned to it's previous state. This is done by first removing the last "Extended" item, making the widget active and setting the selected item. However as "Extended" is the currently selected item, removing it forces their to be no selected item and triggers a change to combo_filesystem triggering a recursive call to ::combobox_changed() where combo_filesystem.get_active_row_number() returns -1 (no selection) [5] and on line 354 the code accesses item -1 of the FILESYSTEMS[] vector. Fix by setting the new combo_filesystem selection before removing the currently selected "Extended" item. This has the added benefit of only triggering a change to combo_filesystem once when the default item is selected rather than twice when the currently "Extended" item is removed and again when the default item is selected. [1] [Fedora] Security Features, Compile Time Buffer Checks (FORTIFY_SOURCE) https://fedoraproject.org/wiki/Security_Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 [2] Enhance application security with FORTIFY_SOURCE https://access.redhat.com/blogs/766093/posts/1976213 [3] Security Features Matrix (GLIBXX_Assertions) https://fedoraproject.org/wiki/Security_Features_Matrix [4] GParted 1.2.0-1.fc33 package build.log for Fedora 33 https://kojipkgs.fedoraproject.org/packages/gparted/1.2.0/1.fc33/data/logs/x86_64/build.log CXXFLAGS='-O2 -g ... -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS ...' [5] gtkmm: Gtk::ComboBox Class Reference, get_active_row_number() https://developer.gnome.org/gtkmm/stable/classGtk_1_1ComboBox.html#a53531bc041b5a460826babb8496c363b Closes #101 - Crash changing Partition type in "Create new partition" dialog 2021-02-20 Yuri Chornoivan Fix minor typos in comments (!71) Closes !71 - Fix minor typos in comments 2021-02-23 Anders Jonsson Update Swedish translation 2021-02-22 Yuri Chornoivan Update Ukrainian translation 2021-02-16 Mike Fleetwood Update SystemRescue name and URL in the GParted Manual SystemRescue have dropped CD from their name and URL. Update the GParted Manual to reflect this. 2021-02-21 Mike Fleetwood Re-enable PipeCapture read NUL byte unit tests in GitLab CI jobs (#136) This reverts commit: e9223207e6b5224259716f05f84f80ca426acc42. Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60) now that PipeCapture has been fixed to read NUL characters again. Closes #136 - 1.2.0: test suite is failing in test_PipeCapture 2021-02-20 Mike Fleetwood Accept NUL as a valid UTF-8 character again (#136) On newer distributions the PipeCapture tests have been failing like this: $ ./test_PipeCapture ... [ RUN ] PipeCaptureTest.ReadEmbeddedNULCharacter test_PipeCapture.cc:336: Failure Expected: inputstr Of length: 6 To be equal to: capturedstr.raw() Of length: 5 With first binary difference: < 0x00000000 "ABC.EF" 41 42 43 00 45 46 -- > 0x00000000 "ABCEF" 41 42 43 45 46 [ FAILED ] PipeCaptureTest.ReadEmbeddedNULCharacter (0 ms) [ RUN ] PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character test_PipeCapture.cc:353: Failure Expected: expectedstr Of length: 7 To be equal to: capturedstr.raw() Of length: 6 With first binary difference: < 0x00000000 "._45678" 00 5F 34 35 36 37 38 -- > 0x00000000 "_45678" 5F 34 35 36 37 38 [ FAILED ] PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character (0 ms) ... Found that test_PipeCapture succeeds on Fedora 31 and fails on Fedora 32. Also test_PipeCapture binary from Fedora 31 and 32 both pass on Fedora 31 and both fail on Fedora 32. So something outside of the GParted code and tests is the cause. Confirmed that this GLib change "Add a missing check to g_utf8_get_char_validated()" [1], first released in GLib 2.63.0, made the difference. On Fedora 32 with GLib 2.64.6, rebuilt GLib with that change reverted and the tests passed. Anyway fix the wrapper GParted has around g_utf8_get_char_validated() to also handle this case of reading a NUL character. [1] https://gitlab.gnome.org/GNOME/glib/-/commit/568720006cd1da3390c239915337ed0a56a23f2e Add a missing check to g_utf8_get_char_validated() Closes #136 - 1.2.0: test suite is failing in test_PipeCapture 2021-02-20 Mike Fleetwood Refactor ::OnReadable() creating get_utf8_char_validated() (#136) Extract call to GLib's g_utf8_get_char_validated() and the associated workaround to also read NUL characters into a separate function to make PipeCapture::OnReadable() a little smaller and simpler, so easier to understand. Add max_len > 0 clause into get_utf8_char_validated() like this: if (uc == UTF8_PARTIAL && max_len > 0) so that the NUL character reading workaround is only applied when max_len specifies the maximum number of bytes to read, rather than when -1 specifies reading a NUL termination string. This makes get_utf8_char_validated() a complete wrapper of g_utf8_get_char_validated() [1], even though GParted always specifies the maximum number of bytes to read. No longer describe the inability to read NUL characters as a bug [2] since the GLib author's said it wasn't [3]. [1] GLib Reference Manual, Unicode Manipulation Functions, g_utf8_get_char_validated () https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-get-char-validated [2] 8dbbb47ce2db0ee733ff909c1ead2f4de9475596 Workaround g_utf8_get_char_validate() bug with embedded NUL bytes (#777973) [3] Bug 780095 - g_utf8_get_char_validated() stopping at nul byte even for length specified buffers https://bugzilla.gnome.org/show_bug.cgi?id=780095#18 "If g_utf8_get_char_validated() encounters a nul byte in the middle of a string of given longer length, it returns -2, indicating a partial gunichar. That is not the obvious behaviour, but since g_utf8_get_char_validated() has been API for a long time, the behaviour cannot be changed. " Closes #136 - 1.2.0: test suite is failing in test_PipeCapture 2021-02-18 Yuri Chornoivan Add Ukrainian screenshot (!70) Closes !70 - Add Ukrainian screenshot 2021-02-10 Mike Fleetwood Rename SupportedFileSystemsTest method to create_image_file() ... from extra_setup() to provide a more meaningful description of what it does. 2021-02-07 Mike Fleetwood Update allow partition deletion comment in set_valid_operations() This previous commit [1] suggested that in future partition deletion might be allowed even while a LUKS mapping was active in that partition. To allow deletion of a partition while it has active content is wrong. That is a significant reason GParted has busy detection of otherwise unrecognised file systems [2] and recognition and busy detection of, but otherwise not controllable support for, Linux Software RAID [3] and ATARAID [4][5] arrays. To automatically close the LUKS partition first would be against the pattern of behaviour that GParted has established, of requiring explicit deactivation of file systems, swap and volume groups before allowing deletion. Therefore update the comment accordingly. [1] f1e3d42b5604d93dc954f5f218ef489649f11284 Prevent deletion of open LUKS mappings (#774818) [2] 49a2e19462fdbe4b28a53cc21a2ddd29d256ff41 Restore busy detection of unknown mounted file systems (#723842) [3] d2e1130ad22eb3f52db4dc7f645ed4d5bf119d24 Detect busy status of Linux Software RAID members (#709640) [4] 6e990ea48ad4177fbf1a26b5f6d9dd60b218874d Detect busy status of mdadm started ATARAID members (#75) [5] caec22871e2fa869db85831c625f30d70738906e Detect busy status of dmraid started ATARAID members (#75) 2021-02-10 Mike Fleetwood Add support for updating the exFAT UUID (!67) Also with exfatprogs 1.1.0 [1], tune.exfat and exfatlabel gained the capability to report and set the exFAT Volume Serial Number [2][3][4]. This is what blkid and therefore GParted reports as the UUID. Report serial number: # tune.exfat -i /dev/sdb1 exfatprogs version : 1.1.0 volume serial : 0x772ffe5d # echo $? 0 # blkid /dev/sdb1 /dev/sdb1: LABEL="test exfat" UUID="772F-FE5D" TYPE="exfat" PTTYPE="dos" Set serial number: # tune.exfat -I 0xf96ef190 /dev/sdb1 exfatprogs version : 1.1.0 New volume serial : 0xf96ef190 # echo $? 0 tune.exfat exists in earlier releases of exfatprogs so check it has the capability by searching for "Set volume serial" in the help output before enabling this capability. # tune.exfat exfatprogs version : 1.1.0 Usage: tune.exfat -l | --print-label Print volume label -L | --set-label=label Set volume label -i | --print-serial Print volume serial -L | --set-serial=value Set volume serial -V | --version Show version -v | --verbose Print debug -h | --help Show help (Note the cut and paste error reporting the set volume serial flag as '-L' rather than actually '-S'). [1] exfatprogs-1.1.0 version released http://github.com/exfaoprogs/exfatprogs/releases/tag/1.1.0 [2] [tools][feature request] Allow To Change Volume Serial Number ("ID") #138 https://github.com/exfatprogs/exfatprogs/issues/138 [3] exfatlabel:add get/set volume serial option https://github.com/exfatprogs/exfatprogs/commit/b4d9c9eeb5c28b503e103e2c4ec22bc146446d9f [4] exFAT file system specification, 3.1.11 VolumeSerialNumber Field https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification#3111-volumeserialnumber-field Closes !67 - Add support for reading exFAT usage and updating the UUID 2021-02-08 Mike Fleetwood Add exFAT file system usage reporting (!67) exfatprogs 1.1.0 released 2021-02-09 [1] has gained support for reporting file system usage [2][3] so add that capability to GParted. It works like this: # dump.exfat /dev/sdb1 | egrep 'Volume Length\(sectors\):|Sector Size Bits:|Sector per Cluster bits:|Free Clusters:' Volume Length(sectors): 524288 Sector Size Bits: 9 Sector per Cluster bits: 3 Free Clusters: 23585 Unfortunately dump.exfat returns a non-zero status on success so that can't be used to check for failure: # dump.exfat /dev/sdb1 exfatprogs version : 1.1.0 -------------- Dump Boot sector region -------------- Volume Length(sectors): 524288 ... # echo $? 192 dump.exfat only writes errors to stderr, so use this to identify failure: # dump.exfat /dev/sdb1 1> /dev/null # echo $? 192 # dump.exfat /dev/zero 1> /dev/null invalid block device size(/dev/zero) bogus sector size bits : 0 # echo $? 234 [1] exfatprogs-1.1.0 version released http://github.com/exfaoprogs/exfatprogs/releases/tag/1.1.0 [2] [feature request] File system usage reporting https://github.com/exfatprogs/exfatprogs/issues/139 [3] exfatprogs: add dump.exfat https://github.com/exfatprogs/exfatprogs/commit/7ce9b2336b06e76521f7e041d8f0712b2d98a15b Closes !67 - Add support for reading exFAT usage and updating the UUID 2021-02-16 Anders Jonsson Update Swedish translation 2021-02-16 Yuri Chornoivan Update Ukrainian translation 2021-02-15 Yuri Chornoivan Add Ukrainian translation of docs (!69) Closes !69 - Add Ukrainian translation of docs 2021-02-15 Yuri Chornoivan Fix minor typos in docs (!68) Closes !68 - Fix minor typos in docs 2021-02-15 Balázs Úr Update Hungarian translation 2021-02-02 Mike Fleetwood Avoid detecting exfat-utils commands as exfatprogs commands (#137) A user had exfat-utils installed and tried to use GParted to create an exfat file system. GParted ran this command but it failed: # mkfs.exfat -L '' '/dev/sdb1' mkexfatfs 1.3.0 mkfs.exfat: invalid option -- 'L' Usage: mkfs.exfat [-i volume-id] [-n label] [-p partition-first-sector] [-s sectors-per-cluster] [-V] The problem is that both exfat-utils and exfatprogs packages provide mkfs.exfat and fsck.exfat commands but they have incompatible command line options and GParted is programmed for exfatprogs. So far GParted just checks the executable exists, hence the mis-identification. Reported version of exfat-utils commands: $ mkfs.exfat -V 2> /dev/null mkexfatfs 1.3.0 Copyright (C) 2011-2018 Andrew Nayenko $ fsck.exfat -V 2> /dev/null exfatfsck 1.3.0 Copyright (C) 2011-2018 Andrew Nayenko Reported versions of exfatprogs commands: $ mkfs.exfat -V 2> /dev/null exfatprogs version : 1.0.4 $ fsck.exfat -V 2> /dev/null exfatprogs version : 1.0.4 Fix this by only enabling exfat support also when the version string of each command starts "exfatprogs version". Note that this extra checking is not needed for tune.exfat because only exfatprogs provides that executable. Closes #137 - Creating exfat partition with a label fails with error 2021-01-16 Mike Fleetwood Make gparted shell wrapper report exit status from gpartedbin gparted shell wrapper always exits with a 0 status even if gpartedbin fails. For example make gpartedbin fail with a non-zero exit status like this: $ (unset DISPLAY; unset XAUTHORITY; /usr/sbin/gpartedbin) (gpartedbin:3936): Gtk-WARNING **: 16:36:06.263: cannot open display: $ echo $? 1 However the gparted shell wrapper instead exits with successful status 0: $ (unset DISPLAY; unset XAUTHORITY; gparted) (gpartedbin:4282): Gtk-WARNING **: 16:39:23.514: cannot open display: $ echo $? 0 Fix this. 2020-01-03 Mike Fleetwood Replace Win_GParted::hbox member with local variables hbox is a very generic name for a member variable and used as a local variable in two methods. Change to local variables instead. 2021-01-31 Mike Fleetwood Remove now unused return value from run_blkid_load_cache() (#131) Closes #131 - GParted hangs when non-named device is hung 2021-01-31 Mike Fleetwood Remove now superfluous load_fs_info_cache() (#131) This method is now only called from one location in the code so put it's two lines of code there. Closes #131 - GParted hangs when non-named device is hung 2021-01-31 Mike Fleetwood Ensure FS_Info (blkid) cache is populated before first use (#131) Now we always want to run blkid naming all paths, ensure the FS_Info cache is explicitly loaded first. Report an error if not done so and remove the cache loading code from running blkid without naming all paths. Fewer code paths to consider and reason about. Closes #131 - GParted hangs when non-named device is hung 2021-01-27 Mike Fleetwood Remove extra execution of blkid for any unreported paths (#131) Again on Fedora 31 with a slightly different disk layout to the previous commit. sdb is partitioned with 1 empty partition and sdc remains completely empty: # lsblk -o name,maj:min,rm,size,ro,type,fstype,label,mountpoint NAME MAJ:MIN RM SIZE RO TYPE FSTYPE LABEL MOUNTPOINT sda 8:0 0 20G 0 disk |-sda1 8:1 0 1G 0 part ext4 /boot \-sda2 8:2 0 19G 0 part LVM2_member |-fedora-root 253:0 0 17G 0 lvm ext4 / \-fedora-swap 253:1 0 2G 0 lvm swap [SWAP] sdb 8:16 0 8G 0 disk \-sdb1 8:17 0 1G 0 part sdc 8:32 0 8G 0 disk sr0 11:0 1 1024M 0 rom # blkid -v blkid from util-linux 2.34 (libblkid 2.34.0, 14-Jun-2019) # blkid /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 /dev/sdc /dev/sda: PTUUID="5012fb1f" PTTYPE="dos" /dev/sda1: UUID="3cd48816-7817-4636-9fec-5f1afe76c1b2" TYPE="ext4" PARTUUID="5012fb1f-01" /dev/sda2: UUID="PH94ej-C8xU-bnMJ-UIh8-ZimI-4B7f-dHlZxh" TYPE="LVM2_member" PARTUUID="5012fb1f-02" /dev/sdb: PTUUID="1d120b57" PTTYPE="dos" /dev/sdb1: PARTUUID="1d120b57-01" Stracing GParted shows these executions of blkid: # strace -f -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | egrep -v 'ENOENT|SIGCHLD' ... [pid 160040] execve("/usr/sbin/blkid", ["blkid", "/dev/sda", "/dev/sda1", "/dev/sda2", "/dev/sdb", "/dev/sdb1", "/dev/sdc"], 0xa4e1b0 /* 32 vars */ [pid 160041] execve("/usr/sbin/blkid", ["blkid", "/dev/sdc"], 0xa4e1b0 /* 32 vars */ ... On Fedora 31 with blkid from util-linux 2.34 it reports information for sdb (partitioned drive) and sdb1 (empty partition) with only no information for sdc (empty whole disk drive). Hence no FS_Info cache entry and re-execution of blkid just for sdc. On older CentOS 7 with the same disk layout blkid reports this: # blkid -v blkid from util-linux 2.23.2 (libblkid 2.23.0, 25-Apr-2013) # blkid /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 /dev/sdc /dev/sda: PTTYPE="dos" /dev/sda1: UUID="e7d559e4-3e1d-4fbc-b034-3fdeb498f44d" TYPE="xfs" /dev/sda2: UUID="B7ODFx-BfTE-hq7N-UlrF-f5ML-CPRe-klSy26" TYPE="LVM2_member" /dev/sdb: PTTYPE="dos" And stracing GParted shows these executions of blkid: # strace -f -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | egrep -v 'ENOENT|SIGCHLD' ... [pid 1889] execve("/sbin/blkid", ["blkid", "/dev/sda", "/dev/sda1", "/dev/sda2", "/dev/sdb", "/dev/sdb1", "/dev/sdc"], 0x10b8b10 /* 26 vars */ [pid 1890] execve("/sbin/blkid", ["blkid", "/dev/sdb1"], 0x10b8b10 /* 26 vars */ [pid 1891] execve("/sbin/blkid", ["blkid", "/dev/sdc"], 0x10b8b10 /* 26 vars */ ... This time on CentOS 7 with blkid from util-linux 2.23.2 it reports information for only sdb (partitioned drive), but not sdb1 (empty partition) or sdc (empty whole disk drive). Hence no FS_info cache entries and re-execution of blkid for both sdb1 and sdc. GParted needs blkid identification of file system images, LVM Logical Volumes or any other partitions named on the command line which it wouldn't normally scan [1]. Now every name of interest is passed to blkid, additional executions of blkid won't get any extra information and are redundant. Therefore remove this unnecessary code. Note that these last 2 commits remove creation of "blank" cache entries (just block special with blank fstype and other attributes) when blkid reports no information for a particular path. Those entry were needed to suppress unnecessary additional execution of blkid. However now that blkid is only executed once (excluding querying the label) this is no longer necessary. All the getter functions return suitable blank values when no cache entry is found. [1] e8f0504b13d98e23e70021f70638184daab228ec Make sure that FS_Info cache is loaded for all named paths (#787181) Closes #131 - GParted hangs when non-named device is hung 2021-01-24 Mike Fleetwood Remove extra execution of blkid for whole disk devices (#131) On Fedora 31 with this simple disk layout where both sdb and sdc are completely empty: # lsblk -o name,maj:min,rm,size,ro,type,fstype,label,mountpoint NAME MAJ:MIN RM SIZE RO TYPE FSTYPE LABEL MOUNTPOINT sda 8:0 0 20G 0 disk |-sda1 8:1 0 1G 0 part ext4 /boot \-sda2 8:2 0 19G 0 part LVM2_member |-fedora-root 253:0 0 17G 0 lvm ext4 / \-fedora-swap 253:1 0 2G 0 lvm swap [SWAP] sdb 8:16 0 8G 0 disk sdc 8:32 0 8G 0 disk sr0 11:0 1 1024M 0 rom # blkid /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdc /dev/sda: PTUUID="5012fb1f" PTTYPE="dos" /dev/sda1: UUID="3cd48816-7817-4636-9fec-5f1afe76c1b2" TYPE="ext4" PARTUUID="5012fb1f-01" /dev/sda2: UUID="PH94ej-C8xU-bnMJ-UIh8-ZimI-4B7f-dHlZxh" TYPE="LVM2_member" PARTUUID="5012fb1f-02" Stracing GParted shows extra executions of blkid: # strace -f -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | egrep -v 'ENOENT|SIGCHLD' ... [pid 7659] execve("/usr/sbin/blkid", ["blkid", "/dev/sda", "/dev/sda1", "/dev/sda2", "/dev/sdb", "/dev/sdc"], 0x1d300f0 /* 32 vars */ [pid 7660] execve("/usr/sbin/blkid", ["blkid", "/dev/sdb"], 0x1d300f0 /* 32 vars */ [pid 7661] execve("/usr/sbin/blkid", ["blkid", "/dev/sdc"], 0x1d300f0 /* 32 vars */ ... blkid is only run again for sdb and sdc, not sda, because blkid didn't report anything for them from the first execution. GParted needs blkid identification of whole disk devices to ensure that ISO9660 images on whole disk devices are correctly identified [1]. Now the first run of blkid passes all the device names, so this additional execution of blkid won't get any extra information and is redundant. Therefore remove this unnecessary code. [1] b2190372d04f09bd38a7395b38e43034f1733d81 Ensure blkid FS_Info cache has entries for all whole disk devices (#771244) Closes #131 - GParted hangs when non-named device is hung 2021-01-24 Mike Fleetwood Pass device and partition names to blkid (#131) A user reported that GParted would hang at "scanning all devices...", when a fully working disk was named on the command line, but another device on the machine was hung. This can be replicated like this: (on Ubuntu 20.04 LTS for it's NBD support) 1. Export and import NBD: # truncate -s 1G /tmp/disk-1G.img # nbd-server -C /dev/null 9000 /tmp/disk-1G.img # nbd-client localhost 9000 /dev/nbd0 2. Hang the NBD server and therefore /dev/nbd0: # killall -STOP nbd-server 3. Run GParted: $ gparted /dev/sda Tracing GParted shows that execution of blkid never returns. # strace -f -tt -q -bexecve -eexecve ./gpartedbin 2>&1 1> /dev/null | fgrep -v ENOENT ... [pid 37823] 13:56:24.814139 execve("/usr/sbin/mkudffs", ["mkudffs", "--help"], 0x55e2a3f2d230 /* 20 vars */ [pid 37814] 13:56:24.829246 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37823, si_uid=0, si_status=1, si_utime=0, si_stime=0} --- [pid 37825] 13:56:25.376796 execve("/usr/sbin/blkid", ["blkid", "-v"], 0x55e2a3f2d230 /* 20 vars */ [pid 37824] 13:56:25.380824 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37825, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- [pid 37826] 13:56:25.402512 execve("/usr/sbin/blkid", ["blkid"], 0x55e2a3f2d230 /* 20 vars */ Tracking of blkid shows that it hangs on either the open of or first read from /dev/nbd0. # strace blkid ... lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0 lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0 lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 access("/dev/nbd0", F_OK) = 0 stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 openat(AT_FDCWD, "/sys/dev/block/43:0", O_RDONLY|O_CLOEXEC) = 4 openat(4, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) close(4) = 0 openat(AT_FDCWD, "/dev/nbd0", O_RDONLY|O_CLOEXEC Clean up: 1. Resume NBD server: # killall -CONT nbd-server 2. Delete NBD setup: # nbd-client -d /dev/nbd0 # killall nbd-server # rm /tmp/disk-1G.img Fix this by making GParted specify the whole disk device and partition names that it is interested in to blkid, rather than letting blkid scan and report all block devices. Do this both when GParted determines the devices for itself and when they are named on the command line. Also update example blkid command output being parsed and cache value with this change to how blkid is executed. Closes #131 - GParted hangs when non-named device is hung 2021-01-24 Mike Fleetwood Refactor run_blkid_load_cache() into if fail return early (#131) ... code pattern. Simplifies the code a little. Closes #131 - GParted hangs when non-named device is hung 2021-01-23 Mike Fleetwood Read partition names from /proc/partitions too (#131) GParted already always reads /proc/partitions for whole disk device names no matter whether it uses whole disk devices named on the command line, from /proc/partitions or from libparted. As /proc/partitions lists all the block devices that the kernel knows about, and therefore all the possible ones blkid could probe, so use it to provide partition names and device to partition mapping. See code comments for more details about the assumptions the /proc/partition parsing code makes and the fact that these are confirmed by examining the Linux kernel source. This commit just adds debugging to print the existing vector of validated devices GParted shows in the UI and the vector with all partitions added, ready for but not yet passed to blkid. # ./gpartedbin ... DEBUG: device_paths=["/dev/sda","/dev/sdb"] DEBUG: device_and_partition_paths=["/dev/sda","/dev/sda1","/dev/sda2","/dev/sdb","/dev/sdb1"] Also demonstrating that this continues to support named devices, including file system image files [1]. # truncate -s 256M /tmp/ext4.img # mkfs.ext4 /tmp/ext4.img # ./gpartedbin /dev/sda /tmp/ext4.img ... DEBUG: device_paths=["/dev/sda","/tmp/ext4.img"] DEBUG: device_and_partition_paths=["/dev/sda","/dev/sda1","/dev/sda2","/tmp/ext4.img"] [1] e8f0504b13d98e23e70021f70638184daab228ec Make sure that FS_Info cache is loaded for all named paths (#787181) Closes #131 - GParted hangs when non-named device is hung 2021-01-21 Mike Fleetwood Refactor load_proc_partitions_info_cache() a bit (#131) Put whole disk device name matching code into a helper function to make the /proc/partition parsing code easier to understand. Closes #131 - GParted hangs when non-named device is hung 2021-01-19 Mike Fleetwood Merge FS_Info load cache calls (#131) Now FS_Info::load_cache() and ::load_cache_for_paths() are nearly next to each other, merge them together to simplify the code a little. This makes the special case to ensure that file system images named on the command line were queried by blkid and loaded into the FS_Info cache [1] become the normal cache loading method. Already passing all discovered or named devices to load_cache_for_paths() is also a step on the way to doing it for all devices and partitions of interest. Just need to ensure that load_cache_for_paths() always loads the cache as load_cache() did, rather than only when it hadn't already been loaded. Otherwise GParted will only ever run blkid and load the cache once at startup and not on each refresh. [1] e8f0504b13d98e23e70021f70638184daab228ec Make sure that FS_Info cache is loaded for all named paths (#787181) Closes #131 - GParted hangs when non-named device is hung 2021-01-19 Mike Fleetwood Initialise partition content discovery caches a bit later (#131) PATCHSET OVERVIEW A user reported that GParted would hang at "scanning all devices...", when a fully working disk was named on the command line, but another device on the machine was hung. This can be replicated like this: (on Ubuntu 20.04 LTS for it's NBD support) 1. Export and import NBD: # truncate -s 1G /tmp/disk-1G.img # nbd-server -C /dev/null 9000 /tmp/disk-1G.img # nbd-client localhost 9000 /dev/nbd0 2. Hang the NBD server and therefore /dev/nbd0: # killall -STOP nbd-server 3. Run GParted: $ gparted /dev/sda Tracing GParted shows that execution of blkid never returns. # strace -f -tt -q -bexecve -eexecve /usr/sbin/gpartedbin 2>&1 1> /dev/null | fgrep -v ENOENT ... [pid 37823] 13:56:24.814139 execve("/usr/sbin/mkudffs", ["mkudffs", "--help"], 0x55e2a3f2d230 /* 20 vars */ [pid 37814] 13:56:24.829246 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37823, si_uid=0, si_status=1, si_utime=0, si_stime=0} --- [pid 37825] 13:56:25.376796 execve("/usr/sbin/blkid", ["blkid", "-v"], 0x55e2a3f2d230 /* 20 vars */ [pid 37824] 13:56:25.380824 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=37825, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- [pid 37826] 13:56:25.402512 execve("/usr/sbin/blkid", ["blkid"], 0x55e2a3f2d230 /* 20 vars */ Tracing of blkid shows that it hangs on either the open of or first read from /dev/nbd0. # strace blkid ... lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0 lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4560, ...}) = 0 lstat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 access("/dev/nbd0", F_OK) = 0 stat("/dev/nbd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x2b, 0), ...}) = 0 openat(AT_FDCWD, "/sys/dev/block/43:0", O_RDONLY|O_CLOEXEC) = 4 openat(4, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) close(4) = 0 openat(AT_FDCWD, "/dev/nbd0", O_RDONLY|O_CLOEXEC Clean up: 1. Resume NBD server: # killall -CONT nbd-server 2. Delete NBD setup: # nbd-client -d /dev/nbd0 # killall nbd-server # rm /tmp/disk-1G.img Going to fix this by making GParted specify the device and partition names that it is interested in to blkid, rather than letting blkid scan and report all block devices. Do this both when GParted determines the devices for itself and when they are named on the command line. THIS PATCH Move the loading and initialising of caches used during content discovery to after device and partition discovery and just before content discovery. Just makes the code ready for the next change. Closes #131 - GParted hangs when non-named device is hung 2021-02-06 Dušan Kazik Update Slovak translation 2021-01-25 Curtis Gedak Append -git to version for continuing development 2021-01-25 Curtis Gedak ========== gparted-1.2.0 ========== 2021-01-25 Curtis Gedak Update copyright years 2021-01-24 Rūdolfs Mazurs Update Latvian translation 2021-01-23 Fabio Tomat Update Friulian translation 2021-01-22 Philipp Kiemle Update German translation 2021-01-21 Marek Černocký Updated Czech translation 2021-01-20 Thibault Martin Update French translation 2021-01-19 Мирослав Николић Update Serbian translation 2021-01-19 Daniel Mustieles Updated Spanish translation 2021-01-18 Rafael Fontenelle Update Brazilian Portuguese translation 2021-01-18 Rafael Fontenelle Update Brazilian Portuguese translation 2021-01-18 Daniel Șerbănescu Update Romanian translation 2021-01-17 Piotr Drąg Update Polish translation 2021-01-16 Anders Jonsson Update Swedish translation 2021-01-16 Yuri Chornoivan Update Ukrainian translation 2021-01-11 Mike Fleetwood White space tidy-up of Utils::get_filesystem_software() Put colon directly after case value and list cases in enumeration order. 2021-01-13 Mike Fleetwood Add unit testing of GParted exFAT interface (!30) Install exfatprogs into the CentOS 7 GitLab CI image, enabling unit testing of GParted's use of exFAT programs. Exfatprogs is not yet available for Ubuntu 20.04 as used in the Ubuntu GitLab CI image, only for Ubuntu 20.10 so far. Closes !30 - Add exFAT support 2021-01-11 Mike Fleetwood Set the partition type for exFAT correctly (!30) Libparted only allows selection of the partition type indirectly by specifying the type of the file system it will contain [1] and so far doesn't know about the exFAT file system. Therefore when GParted is creating a new exFAT partition, it gets the GParted default of 83 (Linux file system) on MBR partition tables. Example operation details: Create Primary Partition #1 (exfat, 512.00 MiB) on /dev/sdb * create empty partition * clear old file system signatures in /dev/sdb1 * set partition type on /dev/sdb1 new partition type: ext2 * create new exfat file system fdisk report: # fdisk -l /dev/sdb Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors Disk model: VBOX HARDDISK 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: 0xa2aab629 Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 1050623 1048576 512M 83 Linux However the "exFAT file system specification" says: https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification "10.2 Partition Tables To ensure interoperability of exFAT volumes in a broad set of usage scenarios, implementations should use partition type 07h for MBR partitioned storage and partition GUID {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} for GPT partitioned storage. " Fix this. [1] ped_partition_new(..., const PedFileSystemType* fs_type, ...) https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5 ped_partition_set_system(..., const PedFileSystemType* fs_type) https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5 Closes !30 - Add exFAT support 2021-01-11 Mike Fleetwood Add exFAT support (!30) With exfatprogs (https://github.com/exfatprogs/exfatprogs) installed the following operations on exFAT file systems are supported: - Creation - Checking - Labelling As of the current exfatprogs 1.0.4 the following are not supported: - Reading usage - Resizing - Updating the UUID Closes !30 - Add exFAT support 2021-01-10 Mike Fleetwood Exclude snap /dev/loop file system image mounts (#129) On Ubuntu the gparted shell wrapper still attempts to mask lots of non-block device based file systems. Remove the --quiet option from the systemctl --runtime mask command to see: $ gparted Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-66.mount -> /dev/null. Created symlink /run/systemd/system/snap-core-10583.mount -> /dev/null. Created symlink /run/systemd/system/boot-efi.mount -> /dev/null. Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1514.mount -> /dev/null. Created symlink /run/systemd/system/snap-core-10577.mount -> /dev/null. Created symlink /run/systemd/system/snap-core18-1944.mount -> /dev/null. Created symlink /run/systemd/system/run-user-1000-doc.mount -> /dev/null. Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1506.mount -> /dev/null. Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-128.mount -> /dev/null. Created symlink /run/systemd/system/snap-snap\x2dstore-518.mount -> /dev/null. Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-145.mount -> /dev/null. Created symlink /run/systemd/system/snap-core18-1932.mount -> /dev/null. Created symlink /run/systemd/system/snap-snap\x2dstore-467.mount -> /dev/null. Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-60.mount -> /dev/null. Created symlink /run/systemd/system/-.mount -> /dev/null. GParted 1.0.0 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.3 The gparted shell wrapper is currently looking for non-masked Systemd mount units where the 'What' property starts "/dev/". However Ubuntu also uses snap packages which are mounted file images via loop devices: $ grep '^/dev/' /proc/mounts | sort /dev/fuse /run/user/1000/doc fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0 /dev/loop0 /snap/core/10583 squashfs ro,nodev,relatime 0 0 /dev/loop10 /snap/snap-store/518 squashfs ro,nodev,relatime 0 0 /dev/loop11 /snap/snap-store/467 squashfs ro,nodev,relatime 0 0 /dev/loop12 /snap/gtk-common-themes/1506 squashfs ro,nodev,relatime 0 0 /dev/loop1 /snap/core/10577 squashfs ro,nodev,relatime 0 0 /dev/loop3 /snap/core18/1944 squashfs ro,nodev,relatime 0 0 /dev/loop4 /snap/core18/1932 squashfs ro,nodev,relatime 0 0 /dev/loop5 /snap/gnome-3-34-1804/66 squashfs ro,nodev,relatime 0 0 /dev/loop6 /snap/gnome-3-28-1804/128 squashfs ro,nodev,relatime 0 0 /dev/loop7 /snap/gnome-3-34-1804/60 squashfs ro,nodev,relatime 0 0 /dev/loop8 /snap/gnome-3-28-1804/145 squashfs ro,nodev,relatime 0 0 /dev/loop9 /snap/gtk-common-themes/1514 squashfs ro,nodev,relatime 0 0 /dev/sda1 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0 /dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0 Fix by excluding: 1. Device name "/dev/fuse" because it's a character not a block device and the mount point is associated with snap, 2. Device names starting "/dev/loop" and where the mount point starts "/snap/" [1]. This is to allow for use of GParted with explicitly named loop devices. [1] The system /snap directory https://snapcraft.io/docs/system-snap-directory Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding anyway 2021-01-04 Mike Fleetwood Only mask Systemd mounts on block devices (#129) The gparted shell wrapper masks Systemd mount units to prevent it automounting file systems while GParted is running [1], excluding virtual file system which GParted isn't interested in [2]. The problem is that there are a lot of virtual file systems and they have changed between Fedora 19 and 33 so now the exclusion list is out of date. Run GParted on Fedora 33 and query the mount units while it is running: $ systemctl list-units -t mount --full --all UNIT LOAD ACTIVE SUB DESCRIPTION -.mount loaded active mounted Root Mount * boot.mount masked active mounted /boot dev-hugepages.mount loaded active mounted Huge Pages File System dev-mqueue.mount loaded active mounted POSIX Message Queue File System * home.mount masked active mounted /home * proc-fs-nfsd.mount masked inactive dead proc-fs-nfsd.mount proc-sys-fs-binfmt_misc.mount loaded inactive dead Arbitrary Executable File Formats File System run-user-1000-gvfs.mount loaded active mounted /run/user/1000/gvfs * run-user-1000.mount masked active mounted /run/user/1000 * run-user-42.mount masked active mounted /run/user/42 sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System sys-kernel-config.mount loaded active mounted Kernel Configuration File System sys-kernel-debug.mount loaded active mounted Kernel Debug File System * sys-kernel-tracing.mount masked active mounted /sys/kernel/tracing * sysroot.mount masked inactive dead sysroot.mount * tmp.mount masked active mounted /tmp * var-lib-machines.mount masked inactive dead var-lib-machines.mount * var-lib-nfs-rpc_pipefs.mount masked active mounted /var/lib/nfs/rpc_pipefs * var.mount masked inactive dead var.mount LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 19 loaded units listed. To show all installed unit files use 'systemctl list-unit-files'. So it masked these virtual file systems which didn't need to be masked: * proc-fs-nfsd.mount masked inactive dead proc-fs-nfsd.mount * run-user-1000.mount masked active mounted /run/user/1000 * run-user-42.mount masked active mounted /run/user/42 * sys-kernel-tracing.mount masked active mounted /sys/kernel/tracing * var-lib-machines.mount masked inactive dead var-lib-machines.mount * var-lib-nfs-rpc_pipefs.mount masked active mounted /var/lib/nfs/rpc_pipefs Lines from /proc/partitions for some of these virtual file systems: $ egrep '/run/user|/sys/kernel/tracing|/var/lib/nfs/rpc_pipefs' /proc/mounts tmpfs /run/user/42 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,nr_inodes=50664,mode=700,uid=42,gid=42,inode64 0 0 tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,nr_inodes=50664,mode=700,uid=1000,gid=1000,inode64 0 0 none /sys/kernel/tracing tracefs rw,seclabel,relatime 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0 And for contrast the lines from /proc/mounts for disk backed file systems: $ egrep '^/dev/' /proc/mounts /dev/sda1 /boot ext4 rw,seclabel,relatime 0 0 /dev/sda2 / btrfs rw,seclabel,relatime,space_cache,subvolid=258,subvol=/root 0 0 /dev/sda2 /home btrfs rw,seclabel,relatime,space_cache,subvolid=256,subvol=/home 0 0 Going back to first principles GParted cares that Systemd doesn't automount file systems on block devices. So instead only mask mount units which are on block devices. Where the 'What' property starts "/dev/". Systemd maintains hundreds of properties for each unit. $ systemctl show boot.mount | wc -l 221 The properties of interest for all mount units can be queries like this: $ systemctl show --all --property=What,Id,LoadState '*.mount' ... What=sunrpc Id=var-lib-nfs-rpc_pipefs.mount LoadState=masked What=/dev/sda1 Id=boot.mount LoadState=masked ... [1] 4c109df9b59e55699bd42023cf4007ee359793e9 Use systemctl runtime mask to prevent automounting (#701676) [2] 43de8e326a9f6f099e5274619f16039bdc20c1a4 Do not mask virtual file systems when using systemctl (#708378) Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding anyway 2021-01-04 Mike Fleetwood Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129) With Systemd 246 on Fedora 33, running GParted reports this error and no longer masks the system mount units: $ gparted Unit \xe2\x97\x8f.service does not exist, proceeding anyway. Unit \xe2\x97\x8f.service does not exist, proceeding anyway. GParted 1.1.0 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.3 $ systemctl list-units -t mount --full --all --no-legend -.mount loaded active mounted Root Mount boot.mount loaded active mounted /boot dev-hugepages.mount loaded active mounted Huge Pages File System dev-mqueue.mount loaded active mounted POSIX Message Queue File System home.mount loaded active mounted /home proc-fs-nfsd.mount loaded inactive dead NFSD configuration filesystem proc-sys-fs-binfmt_misc.mount loaded inactive dead Arbitrary Executable File Formats File System run-user-1000-gvfs.mount loaded active mounted /run/user/1000/gvfs run-user-1000.mount loaded active mounted /run/user/1000 run-user-42.mount loaded active mounted /run/user/42 sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System sys-kernel-config.mount loaded active mounted Kernel Configuration File System sys-kernel-debug.mount loaded active mounted Kernel Debug File System sys-kernel-tracing.mount loaded active mounted Kernel Trace File System * sysroot.mount not-found inactive dead sysroot.mount tmp.mount loaded active mounted Temporary Directory (/tmp) var-lib-machines.mount loaded inactive dead Virtual Machine and Container Storage (Compatibility) var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System * var.mount not-found inactive dead var.mount ^ [Unicode Black Circle character (U+25CF) replaced with star to avoid making this this commit message Unicode.] Currently the gparted shell wrapper lists the Systemd mount units and takes the first space separated column as the unit name. If the LOAD status of the unit is not "loaded" then Systemd prefixes the name with an optional Black Circle. Prior to Systemd 246 these extra 2 characters at the start of the line, including the optional Black Circle, were suppressed by the --no-legend option, but with Systemd 246 this no longer happens. As the mount unit names no longer start in the first character of the line no units are masked. Instead the Unicode Black Circle character, UTF-8 byte sequence E2 97 8F, is found at the start of highlighted lines which results in this error: Unit \xe2\x97\x8f.service does not exist, proceeding anyway. Fix by adding the --plain option to suppress the optional Black Circle in the systemctl output. Confirmed this option is available in the oldest supported distributions with Systemd. RedHat / CentOS 7 Systemd 219 systemctl has --plain option. Ubuntu 16.04 LTS Systemd 229 systemctl has --plain option. Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding anyway 2021-01-10 Jordi Mas Update Catalan translation 2021-01-01 Jordi Mas Update Catalan translation 2020-11-28 Аляксей Update Belarusian translation 2020-11-13 Curtis Gedak Set default partition alignment to cylinder for amiga partition table (#116) Closes #116 - Fails to create partitions on disks with Amiga partition tables using default settings 2020-11-02 Jordi Mas Update Catalan translation 2020-10-13 Dušan Kazik Update Slovak translation 2019-12-23 Mike Fleetwood Remove unneeded #include from TreeView_Detail.h std::vector<> is no longer used in TreeView_Detail.h since this commit replaced them: fae909897e92b55aed0624ec8ccf221806e23ef4 Use PartitionVector class throughout the code (#759726) 2020-09-17 Mike Fleetwood Fix CentOS 7 CI test job failures from empty /etc/machine-id (!62) Since August 2020, GitLab Continuous Integration test jobs have been failing on the CentOS 7 image like this from tests/test_SupportedFileSystems.log: process 6319: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text See the manual page for dbus-uuidgen to correct this issue. D-Bus not built with -rdynamic so unable to print a backtrace Running main() from test_SupportedFileSystems.cc DISPLAY=":99" /usr/bin/xvfb-run: line 181: 6319 Aborted (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1 Not sure why this has just started failing in the CentOS 7 CI image now, but the error is widely known [1][2][3][4]. Use systemd-machine-id-setup to generate a machine ID [5][6]; rather than dbus-uuidgen [7] as it's designed to integrate into VMs and does the right thing if a valid machine ID already exists. [1] Red Hat Bug 598200 - D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/var/lib/dbus/machine-id' https://bugzilla.redhat.com/show_bug.cgi?id=598200 [2] Free Desktop Bug 13194 - When machine-id not found, dbus should not abort https://bugs.freedesktop.org/show_bug.cgi?id=13194 [3] D-Bus library appears to be incorrectly set up https://unix.stackexchange.com/questions/117741/d-bus-library-appears-to-be-incorrectly-set-up [4] Generate uuid for container https://xpra.org/trac/wiki/Usage/Docker/CentOS [5] CentOS / RHEL 7 : How to Change the machine-id https://www.thegeekdiary.com/centos-rhel-7-how-to-change-the-machine-id/ [6] man systemd-machine-id-setup https://man7.org/linux/man-pages/man1/systemd-machine-id-setup.1.html [7] man dbus-uuidgen https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html Closes !62 - Fix CentOS 7 CI test job failures because of zero sized /etc/machine-id 2020-09-11 Fabio Tomat Update Friulian translation 2020-09-06 Aurimas Černius Updated Lithuanian translation 2020-08-30 Boyuan Yang <073plan@gmail.com> Update Chinese (China) translation 2020-07-12 Piotr Drąg Update Polish translation Fixes https://gitlab.gnome.org/Teams/Translation/pl/-/issues/8 2020-06-26 Baurzhan Muftakhidinov Update Kazakh translation 2020-05-31 Daniel Șerbănescu Update Romanian translation 2019-12-19 Mike Fleetwood Add missing includes into Devices module 2020-05-23 Mike Fleetwood Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60) These PipeCapture unit tests are also failing, preventing the ubuntu_test CI job passing: PipeCaptureTest.ReadEmbeddedNULCharacter PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character These tests are also failing locally in both Ubuntu 20.04 LTS and Fedora 32 VMs, but not in Ubuntu 18.04 LTS or Fedora 31 VMs. As this is not specifically a Ubuntu docker image update related issue, temporarily exclude these failing tests. Closes !60 - Fix GitLab CI job failures following Ubuntu docker image updates 2020-05-23 Mike Fleetwood Add C++ compiler into GitLab CI Ubuntu image (!60) Next the Ubuntu image CI job is failing without a C++ compiler like this: checking whether to enable maintainer-specific portions of Makefiles... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether the C++ compiler works... no configure: error: in `/builds/mfleetwo/gparted': configure: error: C++ compiler cannot create executables See `config.log' for more details ... ERROR: Job failed: exit code 1 The published "Ubuntu" docker image has been updated to Ubuntu 20.04 LTS and must no longer include the build tools by default, or not be a dependency of any of the other installed packages. Explicitly install build-essential to get the C++ compiler [1]. Also don't list make as build-essential includes it. [1] Installing the GNU C compiler and GNU C++ compiler https://help.ubuntu.com/community/InstallingCompilers Closes !60 - Fix GitLab CI job failures following Ubuntu docker image updates 2020-05-22 Mike Fleetwood Prevent tzdata install hang in GitLab CI Ubuntu image (!60) The Ubuntu based GitLab CI jobs have recently started being terminated after the default 1 hour timeout. Installing / updating packages in the image is updating the tzdata package which is prompting for input which it will never receive, hence the hang. The end of output from the job looks like this: Setting up tzdata (2020a-0ubuntu0.20.04) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline Configuring tzdata ------------------ Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zones in which they are located. 1. Africa 4. Australia 7. Atlantic 10. Pacific 13. Etc 2. America 5. Arctic 8. Europe 11. SystemV 3. Antarctica 6. Asia 9. Indian 12. US Geographic area: ... ERROR: Job failed: execution took longer than 1h0m0s seconds This is a well known issue [1][2][3]. Probably occurring now because of a new release of tzdata not included in the base Ubuntu image we are using. Fix by telling the underlying dpkg tools this installation is non-interactive. [1] Avoiding user interaction with tzdata when installing certbot in a docker container https://askubuntu.com/questions/909277/avoiding-user-interaction-with-tzdata-when-installing-certbot-in-a-docker-contai [2] How to install tzdata on a ubuntu docker image? https://serverfault.com/questions/949991/how-to-install-tzdata-on-a-ubuntu-docker-image [3] apt-get install tzdata noninteractive https://stackoverflow.com/questions/44331836/apt-get-install-tzdata-noninteractive Closes !60 - Fix GitLab CI job failures following Ubuntu docker image updates 2020-05-24 Yi-Jyun Pan Update Chinese (Taiwan) translation 2020-05-04 Dušan Kazik Update Slovak translation 2020-03-03 Mike Fleetwood Replace TRUE #define with C++ true literal Everywhere else in the code the lower case true C++ boolean literal is used. Change this one place where upper case TRUE #define was used to match. 2020-03-10 Mike Fleetwood Add /dev/disk/by-id/ symlink in CI for test_BlockSpecial This previous commit [1] excluded unit test BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches because GNOME GitLab Docker CI images don't have /dev/disk hierarchy and so no symbolic links to block devices. Create the /dev/disk/by-id directory and a symlink for this unit test to use in the new tests/makedev.sh script. [1] fe2fc33e67980f0b4a5bba958d257be54715f301 Exclude unit test which fails in Docker CI image (!4) 2020-03-11 Mike Fleetwood Exclude unit tests needing losetup in Docker CI image (!59) test_SupportedFileSystems is another unit test that has been failing since 23-Feb-2020 in GNOME GitLab Continuous Integration test jobs. Fragments from tests/test-suite.log from a failed test CI job: FAIL: test_SupportedFileSystems =============================== ... [ RUN ] My/SupportedFileSystemsTest.Create/lvm2pv test_SupportedFileSystems.cc:387: Failure Failed create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img' losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory create_loopdev(): Losetup failed with exit status 1 create_loopdev(): Failed to create required loop device Error: Could not stat device - No such file or directory. test_SupportedFileSystems.cc:446: Failure Value of: lp_device != NULL Actual: false Expected: true test_SupportedFileSystems.cc:490: Failure Value of: m_fs_object->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: lvm pvcreate -M 2 '' 00:00:00 (ERROR) WARNING: Failed to connect to lvmetad. Falling back to device scanning. Device not found. detach_loopdev(): Execute: losetup --detach '' losetup: /dev/: detach failed: Inappropriate ioctl for device detach_loopdev(): Losetup failed with exit status 1 detach_loopdev(): Failed to detach loop device. Test NOT affected [ FAILED ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20 (64 ms) ... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs test_SupportedFileSystems.cc:387: Failure Failed create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img' losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory create_loopdev(): Losetup failed with exit status 1 create_loopdev(): Failed to create required loop device Error: Could not stat device - No such file or directory. test_SupportedFileSystems.cc:446: Failure Value of: lp_device != NULL Actual: false Expected: true test_SupportedFileSystems.cc:503: Failure Value of: m_fs_object->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.btrfs -L '' '' 00:00:00 (ERROR) btrfs-progs v4.9.1 See http://btrfs.wiki.kernel.org for more information. ERROR: failed to check size for : No such file or directory detach_loopdev(): Execute: losetup --detach '' losetup: /dev/: detach failed: Inappropriate ioctl for device detach_loopdev(): Losetup failed with exit status 1 detach_loopdev(): Failed to detach loop device. Test NOT affected [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 (11 ms) All the test_SupportedFileSystems unit tests which need a loop device are failing when running losetup like this: losetup: : failed to setup loop device: No such file or directory losetup uses /dev/loop-control [1][2] which no longer exists in the Docker image. However even after creating /dev/loop-control in the image, losetup continues to fail. Also tried stracing losetup but that fails like this, presumably because it is not allowed inside the Docker image: $ strace losetup --find --show /tmp/disk.img strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted +++ exited with 1 +++ For now I have run out of ways to investigate and resolve this, so just exclude the 12 tests which required loop devices. All the tests still execute when run locally outside the restricted GNOME GitLab CI Docker setup. Closes !59 - Fix GNOME GitLab CI test job failures because of missing /dev entries 2020-03-08 Mike Fleetwood Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59) From 23-Feb-2020 onwards, GNOME GitLab Continuous Integration test jobs have been failing running unit tests which previously succeeded. With some extra debugging added into test_BlockSpecial to print 'bname' and 'bs' values in the failing tests, here are fragments from tests/test-suite.log for the the test_BlockSpecial failures in a test CI job: FAIL: test_BlockSpecial ======================= ... [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice bname="/dev/sr0" bs=BlockSpecial{"/dev/sr0",0,0} test_BlockSpecial.cc:218: Failure Value of: bs.m_major > 0 || bs.m_minor > 0 Actual: false Expected: true [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice (0 ms) ... [ RUN ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices bname1="/dev/sr0" bname2="/dev/sda" bs1=BlockSpecial{"/dev/sr0",0,0} bs2=BlockSpecial{"/dev/sda",0,0} test_BlockSpecial.cc:250: Failure Value of: bs1.m_major != bs2.m_major || bs1.m_minor != bs2.m_minor Actual: false Expected: true [ FAILED ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices (1 ms) Contents of /proc/partitions inside the Docker image when this test CI job failed: $ cat /proc/partitions major minor #blocks name 11 0 1048575 sr0 8 0 573367448 sda 8 1 573366407 sda1 And the listing of /dev/: $ ls -l /dev/ total 0 lrwxrwxrwx 1 root root 11 Mar 3 09:00 core -> /proc/kcore lrwxrwxrwx 1 root root 13 Mar 3 09:00 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Mar 3 09:00 full drwxrwxrwt 2 root root 40 Mar 3 09:00 mqueue crw-rw-rw- 1 root root 1, 3 Mar 3 09:00 null lrwxrwxrwx 1 root root 8 Mar 3 09:00 ptmx -> pts/ptmx drwxr-xr-x 2 root root 0 Mar 3 09:00 pts crw-rw-rw- 1 root root 1, 8 Mar 3 09:00 random drwxrwxrwt 2 root root 40 Mar 3 09:00 shm lrwxrwxrwx 1 root root 15 Mar 3 09:00 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Mar 3 09:00 tty crw-rw-rw- 1 root root 1, 9 Mar 3 09:00 urandom crw-rw-rw- 1 root root 1, 5 Mar 3 09:00 zero See how the test_BlockSpecial fixtures are getting major=0 and minor=0 for the block special devices they are testing with. This is happening because there aren't any entries in /dev for those disks and partitions listed in /proc/partitions. Assume that Docker in GNOME GitLab has changed and that unneeded and unwanted devices in /dev are no longer being created inside images. In the test CI jobs execute new script, tests/makedev.sh, to create just the first two block special devices mentioned in /proc/partitions needed by test_BlockSpecial. Closes !59 - Fix GNOME GitLab CI test job failures because of missing /dev entries 2020-01-03 Mike Fleetwood Delete old Fill txtview_device_info_buffer comment Seems to be referring to how Fill_Label_Device_Info() worked in the past, but from history before the beginning of the GIT repository. Remove out of date comment. 2020-02-29 Mike Fleetwood Reliably detect running gpartedbin using pidof (!54) Debian user reported a bug [1] that when they had PS_FORMAT environment variable set it prevented GParted running: # export PS_FORMAT='ruser,uid,pid,ppid,pri,ni,%cpu,%mem,vsz,rss,stat,tty,start,time,command' # gparted The process gpartedbin is already running. Only one gpartedbin process is permitted. # echo $? 1 Using ps column 'command' includes the command and all it's arguments, rather than just the command name as ps displays by default. Thus the shell wrapper finds the grep command it's using when searching for the gpartedbin executable. # ps -e | grep gpartedbin root 0 26114 14777 19 0 0.0 0.0 112712 940 S+ pts/0 10:42:02 00:00:00 grep --color=auto gpartedbin Fix by searching for running processes using pidof. pgrep does regular expression matching where as pidof checks program name is the same [2]. Therefore use of pidof is preferred over pgrep [3]. [1] Debian bug #864932 - gparted fails if PS_FORMAT options are specified https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864932 [2] Difference between pidof and pgrep? https://stackoverflow.com/questions/52151698/difference-between-pidof-and-pgrep [3] [PATCH] gparted.in: Use reliable way of detecting gpartedbin process existence https://git.alpinelinux.org/aports/tree/community/gparted/gparted.in-Use-reliable-way-of-detecting-gpartedbin-.patch Closes !54 - Fix gparted not launching when PS_FORMAT environment variable set 2020-02-16 Mike Fleetwood Rename local variables to mke2fs_*_ver To better reflect that they represent the version of mke2fs executable from the e2fsprogs package, even though the executable is called as mkfs.ext4. $ ls -il /sbin/mke2fs /sbin/mkfs.ext* 1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mke2fs 1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext2 1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext3 1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext4 $ mkfs.ext4 -V mke2fs 1.42.9 (28-Dec-2013) Using EXT2FS Library version 1.42.9 $ mke2fs -V mke2fs 1.42.9 (28-Dec-2013) Using EXT2FS Library version 1.42.9 2020-02-14 Mike Fleetwood Simplify sscanf("mke2fs ...") text match With removal of support for RHEL / CentOS 5 and it's e4fsprogs package [1][2] it is no longer necessary to accept: mke4fs 1.41.12 (17-May-2010) only: mke2fs 1.42.9 (28-Dec-2013) [1] 6c4ab5dc28a14f3bef2d1c1a24da219381d513f0 Remove checks for e4fsprogs commands (#794253) [2] de6e70d933286f3c65187470c9852fb6d8a60a7d Simplify ext2::get_filesystem_support() with regard ext4 support (#794253) 2020-02-16 Mike Fleetwood Raise minimum supported dosfstools to 3.0.18 (!57) This earlier commit [1] from 2013 recognised the new names for programs in dosfstools >= 3.0.18, specifically mkfs.fat and fsck.fat. Now that the oldest supported distributions use dosfstools >= 3.0.18 it is no longer necessary to support using the old names of mkdosfs and dosfsck, so remove that code. Oldest supported Dosfstools distributions Version Debian 8 3.0.27 RHEL / CentOS 7 3.0.20 SLES 12 3.0.26 Ubuntu 14.04 LTS 3.0.26 [1] 1ae03dee953f512c0c664369db2d5e5db80b4058 Recognise new dosfstools program names (#704629) Closes !57 - Raise minimum support dosfstools to 3.0.18 released 2013-06-06 2020-02-04 Mike Fleetwood Remove unused udevinfo from README Missed removing mention of udevinfo from README when this earlier commit removed it's use by GParted. 3f15a66291af1f2db142edfe2a9219da219a29d5 Drop use of long ago removed udevinfo 2020-02-03 Mike Fleetwood Wait for udev change on /dev/DISK when erasing signatures (#83) A user reported that formatting a whole disk device with a file system failed like this: Format /dev/sdd as ext4 (ERROR) + calibrate /dev/sdd (SUCCESS) path: /dev/sdd (device) start: 0 end: 15633407 size: 15633408 (7.45 GiB) + clear old file system signatures in /dev/sdd (SUCCESS) + write 512.00 KiB of zeros at byte offset 0 (SUCCESS) + write 4.00 KiB of zeros at byte offset 67108864 (SUCCESS) + write 512.00 KiB of zeros at byte offset 8003780608 (SUCCESS) + write 4.00 KiB of zeros at byte offset 8004239360 (SUCCESS) + write 8.00 KiB of zeros at byte offset 8004296704 (SUCCESS) + flush operating system cache of /dev/sdd (SUCCESS) + create new ext4 file system (ERROR) + mkfs.ext4 -F -O ^64bit -L '' '/dev/sdd' (ERROR) mke2fs 1.44.1 (24-Mar-2018) /dev/sdd is apparently in use by the system; will not make a filesystem here! Opening the whole disk block device exclusively causes mkfs.ext4 to report that error like this: # python >>> import os >>> f = os.open('/dev/sdb',os.O_RDONLY|os.O_EXCL) >>> ^Z [1]+ Stopped python # mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb' mke2fs 1.42.9 (28-Dec-2013) /dev/sdb is apparently in use by the system; will not make a filesystem here! # echo $? 1 I have not been able to reproduce this error, but with debugging and sleeping in GParted, stracing GParted and using 'udevadm monitor' to watch udev events the following sequence of events is seen: gparted |format(partition, operationdetail) gparted | erase_filesystem_signatures(partition, operationdetail) gparted | get_device(device_path="/dev/sdb", lp_device, flush=false) gparted | ped_device_get("/dev/sdb") libparted | open("/dev/sdb", O_RDONLY) = 11 libparted | close(11) gparted | ped_device_open(lp_device) libparted | open("/dev/sdb", O_RDWR) = 11 gparted | ped_device_sync(lp_device) libparted | ioctl(11, BLKFLSBUF) gparted | ped_device_close() libparted | close(11) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| UDEV change /devices/.../sdb (block) gparted | set_partition_type(partition, operationdetail) gparted | create_filesystem(partition, operationdetail) gparted | ext2::create(partition, operationdetail) gparted | FileSystem::execute_command("mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb') So it is assumed that the processing of the udev change rule after closing the block device in erase_filesystem_signatures() overlaps with the execution mkfs.ext4 and causes the seen error. Fix by waiting for those udev events to complete as was previously done by commits [1][2] [3]. Also note that this is specific to creating file systems on and formatting unpartitioned whole disk devices because set_partition_type() is a no-operation. Where as on a partitioned device set_partition_type() calls commit() which already waits for udev rules to complete [3]. [1] 50c8924a8e4d9cc96a2ea45f13291114402affee Wait for udev to recreate /dev/PTN entries when querying partition FSs (!46) [2] 4f6c312e3bc68cafb5e6035fd4a5b5bbbfcea992 Wait for udev change on /dev/DISK when querying whole device FS (!46) [3] 2f53876c0fc8bceddabe739c298e19e7939d9ad7 Wait for the kernel and udev to settle partitions for a second time (#790418) Closes #83 - /dev/sdd is apparently in use by the system; will not make a filesystem here! 2020-02-25 Daniele Forsi Fix formatting directive in it.po (!58) Fixes: (gpartedbin:78003): glibmm-WARNING **: 22:55:05.465: invalid substitution "%s" in fmt string "percorso: %1 (%s)" Closes !58 - Fix formatting directive in it.po (!58) 2020-02-26 Nathan Follens Update Dutch translation 2020-02-23 Daniel Korostil Update Ukrainian translation 2020-02-04 Daniel Mustieles Updated Spanish translation 2020-01-29 Dušan Kazik Update Slovak translation 2020-01-20 Curtis Gedak Append -git to version for continuing development Also fix minor whitespace mistake in NEWS 2020-01-20 Curtis Gedak ========== gparted-1.1.0 ========== 2020-01-20 Curtis Gedak Update copyright years 2020-01-19 A S Alam Update Punjabi translation 2020-01-15 Rūdolfs Mazurs Update Latvian translation 2020-01-14 Kukuh Syafaat Update Indonesian translation 2020-01-12 Bruce Cowan Update British English translation 2020-01-12 Wolfgang Stöggl Update German translation 2020-01-11 Claude Paroz Updated French translation 2020-01-11 Trần Ngọc Quân Updated Vietnamese translation Signed-off-by: Trần Ngọc Quân 2020-01-10 Sveinn í Felli Update Icelandic translation 2019-12-03 Mike Fleetwood Save all files on CI job failure for investigation Since patchset !49 "Add file system interface tests" was merged the GitLab Continuous Integration jobs have sometimes failed executing test_SupportedFilesystems. So on failure save all files from the docker image for 1 week for investigation. Documentation: * Introduction to job artifacts https://gitlab.gnome.org/help/user/project/pipelines/job_artifacts.md * GitLab CI/CD Pipeline Configuration Reference, artifacts https://gitlab.gnome.org/help/ci/yaml/README.md#artifacts 2019-12-02 Mike Fleetwood Rename TreeView_Detail::treeview_filesystems_Columns member to fsname (!52) Closes !52 - Rename members and variables currently named 'filesystem' 2019-12-02 Mike Fleetwood Rename DialogFeatures::treeview_filesystems_Columns member to fsname (!52) Name the structure member to 'fsname' used to store strings like "ext2" etc. This is equivalent to what was previously done in this commit: a9f08ddc7dd615b0ce4eb62098439514605fc998 Rename local variable to fsname in get_filesystem() (#741430) Closes !52 - Rename members and variables currently named 'filesystem' 2019-06-13 Mike Fleetwood Rename create_format_menu_add_item() parameter of type FSType (!52) Closes !52 - Rename members and variables currently named 'filesystem' 2019-06-13 Mike Fleetwood Rename set_device_partitions() local variable of type FSType (!52) Closes !52 - Rename members and variables currently named 'filesystem' 2019-06-13 Mike Fleetwood Rename Utils method parameters of type FSType (!52) Closes !52 - Rename members and variables currently named 'filesystem' 2019-06-13 Mike Fleetwood Also rename FS.filesystem member to fstype (!52) Closes !52 - Rename members and variables currently named 'filesystem' 2019-06-12 Mike Fleetwood Rename Partition.filesystem member to fstype (!52) Previously made this change: 175d27c55d44b87ec873a0b09847e8022011d51f Rename enum FILESYSTEM to FSType Now complete the renaming exercise of members and variables currently named 'filesystem'. Closes !52 - Rename members and variables currently named 'filesystem' 2019-11-25 Mike Fleetwood Stop requesting partition paths of free space and metadata In GParted_Core::set_device_partitions() the partition path is being queried from libparted. However this is done before the switch statement on the type of the partition, so is called for all libparted partition objects including PED_PARTITION_FREESPACE and PED_PARTITION_METADATA ones. As libparted numbers these partition objects as -1, it returns paths like "/dev/sda-1". Additionally when using GParted, with it's default DMRaid handling, on a dmraid started array this results in paths like "/dev/mapper/isw_ecccdhhiga_MyArray-1" being passed to is_dmraid_device() and make_path_dmraid_compatible(). Fortunately make_path_dmraid_compatible() does nothing and returns the same name. Call chain looks like: GParted_Core::set_device_partitions() get_partition_path(lp_partition) // where: // lp_partition->disk->dev->path = "/dev/mapper/isw_ecccdhhiga_MyArray" // lp_partition->type == PED_PARTITION_FREESPACE | // PED_PARTITION_METADATA // ->num == -1 ped_partition_get_path(lp_partition) return "/dev/mapper/isw_ecccdhhiga_MyArray-1" dmraid.is_dmraid_supported() dmraid.is_dmraid_device("/dev/mapper/isw_ecccdhhiga_MyArray-1") return true dmraid.make_path_dmraid_compatible("/dev/mapper/isw_ecccdhhiga_MyArray-1") return "/dev/mapper/isw_ecccdhhiga_MyArray-1" Fix by moving the get_partition_path() call inside the switch statement so that it is only called for PED_PARTITION_NORMAL, PED_PARTITION_LOGICAL and PED_PARTITION_EXTENDED partition types. Relevant commits: * 53c49349f71693873805e87856b4c56f2860e6d8 Simplify logic in set_device_partitions method * 81986c0990eef65593ef23397074cf61cdca415f Ensure partition path name is compatible with dmraid (#622217) 2019-11-24 Mike Fleetwood Make 4 internally used only DMRaid methods private 2019-11-20 Mike Fleetwood Recognise ATARAID members started by dmraid (#75) This is not strictly necessary as members are already recognised using blkid since this commit earlier in the sequence "Recognise ATARAID members (#75)". However it makes sure active members are recognised even if blkid is not available and matches how file system detection queries the SWRaid_Info module. Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-20 Mike Fleetwood Display array device as mount point of dmraid started ATARAID members (#75) This matches how the array device is displayed as the mount point for mdadm started ATARAID members by "Display array device as mount point of mdadm started ATARAID members (#75)" earlier in this patchset. Extend the DMRaid module member cache to save the array device name and use as needed to display as the mount point. Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-24 Mike Fleetwood Detect busy status of dmraid started ATARAID members (#75) Again this is to stop GParted allowing overwrite operations being performed on an ATARAID member while the array is actively using the member. This time for dmraid started arrays using the kernel DM (Device Mapper) driver. The DMRaid module already uses dmraid to report active array names: # dmraid -sa -c isw_ecccdhhiga_MyArray To find active members in this array, (1) use udev to lookup the kernel device name: # udevadm info --query=name /dev/mapper/isw_ecccdhhiga_MyArray dm-0 (2) list the member names exposed by the kernel DM driver through the /sys file system. # ls /sys/block/dm-0/slaves sdc sdd # ls -l /sys/block/dm-0/slaves lrwxrwxrwx 1 root root 0 Nov 24 09:52 sdc -> ../../../../pci0000:00/0000:00:0d.0/ata3/host2/target2:0:0/2:0:0:0/block/sdc lrwxrwxrwx 1 root root 0 Nov 24 09:52 sdc -> ../../../../pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdd Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-21 Mike Fleetwood Enable basic supported actions for ATARAID members (#75) When an ATARAID member is inactive allow basic supported actions of copy and move to be performed like with other recognised but only basic supported types. Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-19 Mike Fleetwood Prevent unmount of busy ATARAID members (#75) Since earlier commit "Display array device as mount point of mdadm started ATARAID members (#75)" GParted allows attempting to unmout a busy ATARAID member as if it was a file system. This is not a valid thing to do, so disallow it. Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-17 Mike Fleetwood Display array uuid of mdadm recognised ATARAID members (#75) Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-17 Mike Fleetwood Display array device as mount point of mdadm started ATARAID members (#75) This matches how other non-file systems are handled, by displaying the access reference in the mount point column. For LVM Physical Volumes the Volume Group name is displayed [1] and for an active Linux Software RAID array the array device is displayed [2]. [1] 8083f11d84dbd4f186271a3cdbf5170db259f8b8 Display LVM2 VGNAME as the PV's mount point (#160787) [2] f6c2f00df7858a7f4b97e699b9bcf1023bba850a Populate member mount point with SWRaid array device (#756829) Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-17 Mike Fleetwood Detect busy status of mdadm started ATARAID members (#75) This stops GParted allowing overwrite operations (such as create partition table or format with a whole device file system) being performed on an ATARAID member while the array is actively using the member. Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-17 Mike Fleetwood Display correct type of mdadm recognised ATARAID members (#75) The previous commit, made mdadm recognised IMSM and DDF type ATARAID members get displayed as "linux-raid" (Linux Software RAID array member). This was because of query method 1 in detect_filesystems(). Fix this now by exposing and using the fstype of the member from the SWRaid_Info cache. Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-17 Mike Fleetwood Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-11-02 Mike Fleetwood Recognise ATARAID members (#75) PATCHSET OVERVIEW A user had a Firmware / BIOS / ATARAID array of 2 devices configured as a RAID 0 (stripe) set. On top of that was a GPT with the OS partitions. GParted displays the following errors on initial load and subsequent refresh: Libparted Error (-) Invalid argument during seek for read on /dev/sda [ Retry ] [ Cancel ] [ Ignore ] Libparted Error (-) The backup GPT table is corrupt, but the primary appears OK, so that will be used. [ Ok ] [ Cancel ] This is an Intel Software RAID array which stores metadata at the end of each member device, and so the first 128 KiB stripe of the set is stored in the first 128 KiB of the first member device /dev/sda which includes the GPT for the whole RAID 0 device. Hence when libparted reads member device /dev/sda it finds a GPT describing a block device twice it's size and in results the above errors when trying to read the backup GPT. A more dangerous scenario occurs when using 2 devices configured in an Intel Software RAID 1 (mirrored) set with GPT on top. On refresh GParted display this error for both members, /dev/sda and /dev/sdb: Libparted Warning /!\ Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 9554 blocks) or continue with the current setting? [ Fix ] [ Ignore ] Selecting [Fix] gets libparted to re-write the backup GPT to the end of the member device, overwriting the ISW metadata! Do that twice and both copies of the metadata are gone! Worked example of this more dangerous mirrored set case. Initial setup: # dmraid -s *** Group superset isw_caffbiaegi --> Subset name : isw_caffbiaegi_MyMirror size : 16768000 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 # dmraid -r /dev/sda: isw, "isw_caffbiaegi", GROUP, ok, 16777214 sectors, data@ 0 /dev/sdb: isw, "isw_caffbiaegi", GROUP, ok, 16777214 sectors, data@ 0 # wipefs /dev/sda offset type --------------------------------------------- 0x200 gpt [partition table] 0x1fffffc00 isw_raid_member [raid] Run GParted and click [Fix] on /dev/sda. Now the first member has gone: # dmraid -s *** Group superset isw_caffbiaegi --> *Inconsistent* Subset name : isw_caffbiaegi_MyMirror size : 16768000 stride : 128 type : mirror status : inconsistent subsets: 0 devs : 1 spares : 0 # dmraid -r /dev/sdb: isw, "isw_caffbiaegi", GROUP, ok, 16777214 sectors, data@ 0 # wipefs /dev/sda offset type --------------------------------------------- 0x200 gpt [partition table] Click [Fix] on /dev/sdb. Now all members of the array are gone: # dmraid -s no raid disks # dmraid -r no raid disks # wipefs /dev/sdb offset type --------------------------------------------- 0x200 gpt [partition table] So GParted must not run libparted partition table scanning on the member devices in ATARAID arrays. Only on the array device itself. In terms of the UI GParted must show disks which are ATARAID members as whole disk devices with ATARAID member content and detect array busy status to avoid allowing active members from being overwritten while in use. THIS COMMIT Recognise ATARAID member devices and display in GParted as whole device "ataraid" file systems. Because they are recognised as whole device content ("ataraid" file systems) this alone stops GParted running the libparted partition table scanning and avoids the above errors. The list of dmraid supported formats is matched by the signatures recognised by blkid: $ dmraid -l asr : Adaptec HostRAID ASR (0,1,10) ddf1 : SNIA DDF1 (0,1,4,5,linear) hpt37x : Highpoint HPT37X (S,0,1,10,01) hpt45x : Highpoint HPT45X (S,0,1,10) isw : Intel Software RAID (0,1,5,01) jmicron : JMicron ATARAID (S,0,1) lsi : LSI Logic MegaRAID (0,1,10) nvidia : NVidia RAID (S,0,1,10,5) pdc : Promise FastTrack (S,0,1,10) sil : Silicon Image(tm) Medley(tm) (0,1,10) via : VIA Software RAID (S,0,1,10) dos : DOS partitions on SW RAIDs $ fgrep -h _raid_member util-linux/libblkid/src/superblocks/*.c .name = "adaptec_raid_member", .name = "ddf_raid_member", .name = "hpt45x_raid_member", .name = "hpt37x_raid_member", .name = "isw_raid_member", .name = "jmicron_raid_member", .name = "linux_raid_member", .name = "lsi_mega_raid_member", .name = "nvidia_raid_member", .name = "promise_fasttrack_raid_member", .name = "silicon_medley_raid_member", .name = "via_raid_member", As they are all types of Firmware / BIOS / ATARAID arrays, report all members as a single "ataraid" file system type. (Except for "linux_raid_member" in the above blkid source listing which is Linux Software RAID). Closes #75 - Errors with GPT on RAID 0 ATARAID array 2019-12-01 Andre Klapper Fix an incorrect translation in the Spanish user help See #80 2019-12-01 Andre Klapper Fix typo in Spanish translation of user help Fixes #80 2019-11-28 Daniel Mustieles Updated Spanish translation 2019-11-09 Mike Fleetwood Add missing includes into jfs.cc 2019-11-08 Mike Fleetwood Remove unallocated space comment from HACKING file (!50) The HACKING file should be hints for making changes to the code base and associated processes. A overview of how GParted handled unallocated space was not that. Also now the size of a JFS is accurately calculated using JFS as an example of a file system with intrinsic unallocated space is no longer valid. Therefore removed from the HACKING file. Instead add the original commit message as an extended comment to method calc_significant_unallocated_sectors(). Closes !50 - Calculate JFS size accurately 2019-11-08 Mike Fleetwood Calculate mounted JFS size accurately (!50) With the same minimum sized 16 MiB JFS used in the previous commit, now mounted, GParted once again reports 1.20 MiB of unallocated space. This is because the kernel JFS driver is also just reporting the size of the Aggregate Disk Map (dmap) as the size of the file system [1]. Fix by reading the on disk JFS superblock to calculate the size of the file system, but query the free space from the kernel using statvfs(). Need to query mounted JFS free space from the kernel because the on disk dmap is not updated immediately so doesn't reflect recently used or freed disk space. For example, start with the 16 MiB JFS empty and mounted. # echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree [2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1 # df -k /mnt/1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 15152 136 15016 1% /mnt/1 Write 10 MiB of data to it: # dd if=/dev/zero bs=1M count=10 of=/mnt/1/file_10M 10+0 records in 10+0 records out 1048760 bytes (10 MB, 10 MiB) copied, 0.0415676 s, 252 MB/s Query the file system free space from the kernel and by reading the on disk dmap figure: # df -k /mnt/1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 15152 10376 4776 69% /mnt/1 # echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree [2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1 # sync # echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree [2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1 # umount /mnt/1 # echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 | fgrep dn_nfree [2] dn_nfree: 0x000000004aa [10] dn_agwidth: 1 The kernel reports the updated usage straight away, but the on disk dmap record doesn't get updated even by sync, only after unmounting. This is the same fix as was previously done for EXT2/3/4 [2]. [1] Linux jfs_statfs() function https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/jfs/super.c?h=v3.10#n142 [2] 3828019030f981cc5b3411badc40704f5525fdb3 Read file system size for mounted ext2/3/4 from superblock (#683255) Closes !50 - Calculate JFS size accurately 2019-11-05 Mike Fleetwood Calculate unmounted JFS size accurately (!50) Create the smallest possible JFS (16 MiB) and GParted will report 1.2 MiB of unallocated space. This is because the size of the Aggregate Disk Map (dmap) was used as the size of the file system. However after reading the source code to mkfs.jfs, it separately accounts for the size of the Log (Journal) and the FSCK Working Space. The size of a JFS is the sum of these 3 components added together. Using the minimum 16 MiB JFS as an example: # jfs_debugfs /dev/sdb1 jfs_debugfs version 1.1.15, 04-Mar-2011 Aggregate Block Size: 4096 > superblock [1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00 [2] s_version: 1 [16] s_ait2.addr2: 0x00000018 [3] s_size: 0x0000000000007660 s_ait2.address: 24 [4] s_bsize: 4096 [17] s_logdev: 0x00000000 [5] s_l2bsize: 12 [18] s_logserial: 0x00000000 [6] s_l2bfactor: 3 [19] s_logpxd.len: 256 [7] s_pbsize: 512 [20] s_logpxd.addr1: 0x00 [8] s_l2pbsize: 9 [21] s_logpxd.addr2: 0x00000f00 [9] pad: Not Displayed s_logpxd.address: 3840 [10] s_agsize: 0x00002000 [22] s_fsckpxd.len: 52 [11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00 JFS_LINUX [24] s_fsckpxd.addr2: 0x00000ecc JFS_COMMIT JFS_GROUPCOMMIT s_fsckpxd.address: 3788 JFS_INLINELOG [25] s_time.tv_sec: 0x5dbbdfa0 [26] s_time.tv_nsec: 0x00000000 [27] s_fpack: 'small_jfs' [12] s_state: 0x00000000 FM_CLEAN [13] s_compress: 0 [14] s_ait2.len: 4 display_super: [m]odify or e[x]it: x > dmap Block allocation map control page at block 16 [1] dn_mapsize: 0x00000000ecc [9] dn_agheigth: 0 [2] dn_nfree: 0x00000000eaa [10] dn_agwidth: 1 [3] dn_l2nbperpage: 0 [11] dn_agstart: 341 [4] dn_numag: 1 [12] dn_agl2size: 13 [5] dn_maxlevel: 0 [13] dn_agfree: type 'f' [6] dn_maxag: 0 [14] dn_agsize: 8192 [7] dn_agpref: 0 [15] pad: Not Displayed [8] dn_aglevel: 0 display_dbmap: [m]odify, [f]ree count, [t]ree, e[x]it > x > quit Values of interest: s_size - Aggregate size in device (s_pbsize) blocks s_bsize - Aggregate block (aka file system allocation) size in bytes s_pbsize - Physical (device) block size in bytes s_logpxd.len - Log (Journal) size in Aggregate (s_bsize) blocks s_fsckpxd.len - FSCK Working Space in Aggregate (s_bsize) blocks dn_nfree - Number of free (s_bsize) blocks in Aggregate Calculation: file system size = s_size * s_pbsize + s_logpxd.len * s_bsize + s_fsckpxd.len * s_bsize = 30304 * 512 + 256 * 4096 + 52 * 4096 = 16777216 (Exactly 16 MiB. The size of the partition.) free space = dn_nfree * s_bsize = 3754 * 4096 = 15376384 Rewrite JFS usage querying code to use this updated calculation. [1] JFS Overview / How the Journaled File System cuts system restart times to the quick http://jfs.sourceforge.net/project/pub/jfs.pdf [2] JFS Layout / How the Journaled File systems handles the on-disk layout http://jfs.sourceforge.net/project/pub/jfslayout.pdf [3] mkfs.jfs source code http://jfs.sourceforge.net/project/pub/jfsutils-1.1.15.tar.gz mkfs/mkfs.c Selected lines from mkfs/mkfs.c create_aggregate(..., number_of_blocks, ..., logsize, ...) number_of_blocks -= fsck_wspace_length; aggr_superblock.s_size = number_of_blocks * (aggr_block_size / phys_block_size); aggr_superblock.s_bsize = aggr_block_size; aggr_superblock.s_pbsize = phys_block_size; PXDlength(&aggr_superblock.s_logpxd, logsize); PXDlength(&aggr_superblock.s_fsckpxd, fsck_wspace_length); main() number_of_bytes = bytes_on_device; number_of_blocks = number_of_bytes / agg_block_size; logsize = logsize_in_bytes / aggr_block_size; number_of_blocks -= logsize; create_aggregate(..., number_of_blocks, ..., logsize, ...); Closes !50 - Calculate JFS size accurately 2019-11-04 Mike Fleetwood Update name of the NILFS2 specific package Upstream NILFS project calls the package nilfs-utils [1][2]. Arch Linux / CentOS / Fedora / OpenSUSE use the upstream name. However Debian / Ubuntu name it nilfs-tools [3] instead. Document the needed software as: nilfs-utils / nilfs-tools Upstream name first separated by slash from alternative names distributions use. [1] NILFS Download page https://nilfs.sourceforge.io/en/download.html [2] NILFS Public Git Repositories https://nilfs.sourceforge.io/en/git_repos.html [3] Debian package: nilfs-tools https://packages.debian.org/sid/nilfs-tools 2019-10-13 Mike Fleetwood Add missing libuuid-devel build dependency for Fedora into README 2019-10-27 Mike Fleetwood Avoid crash reading JFS usage on Fedora 30 (!49)(#794947) Running JFS read usage test on Fedora 30 fails like this: $ ./test_SupportedFileSystems --gtest_filter='*ReadUsage/jfs' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs unknown file: Failure C++ exception with description "std::bad_alloc" thrown in the test body. [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 (41833 ms) However the same test passes on Fedora 29, Fedora 31 Beta, CentOS 7, Debian 10 and Ubuntu 18.04 LTS. Also running GParted on Fedora 30 crashes just the same when reading JFS usage: # gparted GParted 1.0.0 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.2 terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc /usr/bin/gparted: line 202: 19218 Aborted (core dumped) $BASE_CMD Running jfs_debugfs to query the file system usage the same way GParted does produces an infinite amount of repeating output: # echo dm | jfs_debugfs /dev/sdb1 So jfs_debugfs gets stuck in an infinite loop inside the dmap subcommand when it encounters EOF. GParted and the read JFS usage test read this output until memory is exhausted and crash. This is exactly what was happening in closed bug 794947. Even installed jfsutils from Fedora 29 on Fedora 30 and visa versa. jfs_debugfs still produced an infinite amount of output on Fedora 30 and worked correctly on Fedora 29. So it's not the build of jfsutils, but something in the OS that is making the difference! Anyway fix by providing the instruction to exit from the dmap subcommand, and quit from jfs_debugfs itself, like this: # echo -e 'dmap\nx\nquit' | jfs_debugfs /dev/sdb1 Bug 794947 - gparted hangs when sees JFS partition on discovering partitions Closes !49 - Add file system interface tests 2019-10-20 Mike Fleetwood Accept FS usage figures within significant unallocated threshold (!49) So far the read file system usage figures, read via the file system interface classes using file system specific tools, have been checked to the exact sector for: 0 <= used <= size 0 <= unused <= size unallocated = 0 used + unused = size However for JFS and NTFS this fails like this: # ./test_SupportedFileSystems --gtest_filter='*ReadUsage/*' | fgrep ' ms' [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs (335 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/exfat (0 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/ext2 (38 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/ext3 (131 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/ext4 (32 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/f2fs (47 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/fat16 (19 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/fat32 (48 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/hfs (0 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/hfsplus (0 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 (73 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/linuxswap (20 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/luks (0 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/lvm2pv (410 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/minix (0 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/nilfs2 (226 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs, where GetParam() = 23 (56 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/reiser4 (49 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/reiserfs (139 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/udf (34 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/xfs (67 ms) [----------] 21 tests from My/SupportedFileSystemsTest (1726 ms total) [==========] 21 tests from 1 test case ran. (1726 ms total) # ./test_SupportedFileSystems --gtest_filter='*ReadUsage/jfs:*ReadUsage/ntfs' Running main() from test_SupportedFileSystems.cc Note: Google Test filter = *ReadUsage/jfs:*ReadUsage/ntfs [==========] Running 2 tests from 1 test case. [----------] Global test environment set-up. [----------] 2 tests from My/SupportedFileSystemsTest [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs test_SupportedFileSystems.cc:465: Failure Expected equality of these values: m_partition.sectors_unallocated Which is: 2472 0 test_SupportedFileSystems.cc:517: Failure Expected equality of these values: m_partition.sectors_used + m_partition.sectors_unused Which is: 521816 m_partition.get_sector_length() Which is: 524288 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 (36 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs test_SupportedFileSystems.cc:465: Failure Expected equality of these values: m_partition.sectors_unallocated Which is: 8 0 test_SupportedFileSystems.cc:517: Failure Expected equality of these values: m_partition.sectors_used + m_partition.sectors_unused Which is: 524280 m_partition.get_sector_length() Which is: 524288 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs, where GetParam() = 23 (35 ms) [----------] 2 tests from My/SupportedFileSystemsTest (71 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test case ran. (72 ms total) [ PASSED ] 0 tests. [ FAILED ] 2 tests, listed below: [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs, where GetParam() = 23 2 FAILED TESTS So JFS is reporting 2472 unallocated sectors in a size of 524288 sectors and NTFS is reporting 8 unallocated sectors in the same size. This exact issue is already solved for GParted so that it doesn't show a small amount of unallocated space by commits [1][2] from Bug 499202 [3]. Fix the same way, use the accessors to the file system usage figures which don't show unallocated space when it is below the significant threshold. [1] b5c80f18a9ce27fda2b11e9b590d7f856209ac32 Enhance calculation of significant unallocated space (#499202) [2] 7ebedc4bb3b81e85fb4c628a2a05308ada147d68 Don't show intrinsic unallocated space (#499202) [3] Bug 499202 - gparted does not see the difference if partition size differs from filesystem size https://bugzilla.gnome.org/show_bug.cgi?id=499202 Closes !49 - Add file system interface tests 2019-10-14 Mike Fleetwood Skip Check MINIX file system interface test (!49) Checking a MINIX V3 file system fails like this: $ ./test_SupportedFileSystems --gtest_filter='*Check/minix' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndCheck/minix test_SupportedFileSystems.cc:554: Failure Value of: m_fs_object->check_repair(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.minix -3 '/home/centos/programming/c/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (SUCCESS) 87392 inodes 262144 blocks Firstdatazone=5507 (5507) Zonesize=1024 Maxsize=2147483647 fsck.minix '/home/centos/programming/c/gparted/tests/test_SupportedFileSystems.img' 00:00:00 (ERROR) fsck.minix from util-linux 2.23.2 bad magic number in super-block [ FAILED ] My/SupportedFileSystemsTest.CreateAndCheck/minix, where GetParam() = 21 (182 ms) fsck.minix doesn't support checking MINIX V3 file systems until this commit, first included in util-linux 2.27 released 2015-09-07. https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=86a9f3dad58addb50eca9daa9d233827a005dad7 fsck.minix: add minix v3 support CentOS 7 only includes util-linux 2.23.2 so is affected by this, however Ubuntu 18.04 LTS includes util-linux 2.31.1 so is not affected. Just always skip this test for now. Plan to re-enable later when the oldest supported distributions and GitLab CI images include the needed util-linux release. Closes !49 - Add file system interface tests 2019-09-03 Mike Fleetwood Write new UUID to JFS before testing reading UUID (!49) Testing reading the UUID from a newly created JFS was failing like this: $ ./test_SupportedFileSystems --gtest_filter='*ReadUUID/jfs' ... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/jfs test_SupportedFileSystems.cc:552: Failure Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/jfs, where GetParam() = 17 (57 ms) Mkfs.jfs creates a file system as version 1. It does have a UUID and blkid can report it, but jfs_tune doesn't report it. $ touch -s 256M test_jfs.img $ mkfs.jfs -q test_jfs.img mkfs.jfs version 1.1.15, 04-Mar-2011 Format completed successfully. 262144 kilobytes total disk space. $ blkid test_jfs.img test_jfs.img: UUID="6b0bb46a-a240-47b4-89ab-1fe759aa572d" TYPE="jfs" $ jfs_tune -l test_jfs.img | egrep 'version|UUID' jfs_tune version 1.1.15, 04-Mar-2011 JFS version: 1 $ hexdump -C test_jfs.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00008000 4a 46 53 31 01 00 00 00 58 f6 07 00 00 00 00 00 |JFS1....X.......| Version >---------------- ^^ ^^ ^^ ^^ ... 00008080 00 00 00 00 00 00 00 00 6b 0b b4 6a a2 40 47 b4 |........k..j.@G.| 00008090 89 ab 1f e7 59 aa 57 2d 00 00 00 00 00 00 00 00 |....Y.W-........| UUID >-------------------------------- ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ However writing a new UUID to the JFS also updates the version to 2 and allows jfs_tune to report the UUID. $ jfs_tune -U random test_jfs.img jfs_tune version 1.1.15, 04-Mar-2011 UUID updated successfully. $ blkid test_jfs.img test_jfs.img: UUID="6374ec58-3568-4ffb-bea9-ff76bf5c192f" TYPE="jfs" $ jfs_tune -l test_jfs.img | egrep 'version|UUID' jfs_tune version 1.1.15, 04-Mar-2011 JFS version: 2 File system UUID: 6374ec58-3568-4ffb-bea9-ff76bf5c192f External log UUID: 00000000-0000-0000-0000-000000000000 $ hexdump -C test_jfs.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00008000 4a 46 53 31 02 00 00 00 58 f6 07 00 00 00 00 00 |JFS1....X.......| Version >---------------- ^^ ^^ ^^ ^^ ... 00008080 00 00 00 00 00 00 00 00 63 74 ec 58 35 68 4f fb |........ct.X5hO.| 00008090 be a9 ff 76 bf 5c 19 2f 00 00 00 00 00 00 00 00 |...v.\./........| New UUID >---------------------------- ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ Therefore change the CreateAndReadUUID test for JFS to also write a new UUID so that it also updates the version to 2, thus allowing jfs_tune to report the UUID and the test pass. Note that GParted doesn't encounter this problem because it used blkid by default to report the UUID and only falls back to using the file system interface method which calls jfs_tune when blkid is not available. Closes !49 - Add file system interface tests 2019-08-05 Mike Fleetwood Accept reading shorter UUIDs from FAT16/32 file systems (!49) The tests were failing like this: $ ./test_SupportedFileSystems --gtest_filter='*CreateAndReadUUID/fat16' .... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16 test_SupportedFileSystems.cc:552: Failure Expected equality of these values: m_partition.uuid.size() Which is: 9 36U Which is: 36 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16, where GetParam() = 13 (45 ms) This is because the test was expecting a full 36 character UUID as used by Linux file systems. Also accept shorter 9 character "UUID"s as used by FAT16/32 file systems. Closes !49 - Add file system interface tests 2019-10-14 Mike Fleetwood Create loop devices for NILFS2 read and write FS interface tests (!49) For NILFS2 the read and write tests which use nilfs-tune all fail using an image file, even when run as root, however the other tests succeed. Selected output from the test program: # ./test_SupportedFileSystems --gtest_filter='*/nilfs2' | fgrep ' ms' [ OK ] My/SupportedFileSystemsTest.Create/nilfs2 (22 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/nilfs2, where GetParam() = 22 (31 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/nilfs2, where GetParam() = 22 (30 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/nilfs2, where GetParam() = 22 (30 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteLabel/nilfs2, where GetParam() = 22 (37 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteUUID/nilfs2, where GetParam() = 22 (39 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndCheck/nilfs2 (0 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndRemove/nilfs2 (0 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndGrow/nilfs2 (386 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndShrink/nilfs2 (345 ms) [----------] 10 tests from My/SupportedFileSystemsTest (920 ms total) [==========] 10 tests from 1 test case ran. (920 ms total) nilfs-tune fails like this when given an image file: # truncate -s 256M test.img # mkfs.nilfs2 test.img mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:test.img Device Size:268435456 File system initialization succeeded !! # nilfs-tune -l test.img nilfs-tune 2.2.7 nilfs-tune: test.img: cannot open NILFS # echo $? 1 However using nilfs-tune via a loop device works: # losetup --show --find /dev/loop0 /dev/loop0 # nilfs-tune -l /dev/loop0 nilfs-tune 2.2.7 Filesystem volume name: (none) Filesystem UUID: fc49912c-4d39-4672-8610-1e1185d0db5f Filesystem magic number: 0x3434 Filesystem revision #: 2.0 Filesystem features: (none) Filesystem state: valid Filesystem OS type: Linux Block size: 4096 ... So nilfs-tune only works with block devices. Fix by making these tests require a loop device and therefore make them root only. Now these tests are skipped as non-root user and pass as root. Closes !49 - Add file system interface tests 2019-10-10 Mike Fleetwood Create loop devices for online resized file system tests (!49) File systems BTRFS, JFS, NILFS2 and XFS can only be resized while mounted, but only root can mount file systems. Therefore these tests fail. Also BTRFS resize uses 'btrfs filesystem show' to discover the devid, which also fails as described in the previous commit message. Note that root can mount a file system image directly, but that it implicitly creates loop device: # truncate -s 256M test.img # mkfs.xfs test.img # mount test.img /mnt/1 # fgrep /mnt/1 /proc/mounts /dev/loop0 /mnt/1 xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 # losetup -a /dev/loop0: [64768]:35826659 (/root/test.img) Therefore make these tests root only and require an explicit loop device. Now these file system resize tests succeed as root and are skipped as non-root. Closes !49 - Add file system interface tests 2019-10-09 Mike Fleetwood Create loop devices for BTRFS read file system interface tests (!49) For BTRFS the read (and resize) tests fail when using an image file, however the create, write and check tests pass. Selected output from the test program: $ ./test_SupportedFileSystems --gtest_filter='*/btrfs' | fgrep ' ms' [ OK ] My/SupportedFileSystemsTest.Create/btrfs (43 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 (95 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs, where GetParam() = 7 (158 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/btrfs, where GetParam() = 7 (164 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndWriteLabel/btrfs (164 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndWriteUUID/btrfs (132 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndCheck/btrfs (129 ms) [ OK ] My/SupportedFileSystemsTest.CreateAndRemove/btrfs (0 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/btrfs, where GetParam() = 7 (155 ms) [ FAILED ] My/SupportedFileSystemsTest.CreateAndShrink/btrfs, where GetParam() = 7 (97 ms) [----------] 10 tests from My/SupportedFileSystemsTest (1137 ms total) [==========] 10 tests from 1 test case ran. (1137 ms total) The read operations fail because 'btrfs filesystem show' doesn't work on am image file: $ truncate -s 256M test.img $ mkfs.btrfs test.img btrfs-progs v4.9.1 See http://btrfs.wiki.kernel.org for more information. Label: (null) UUID: de1624ae-39bb-4796-aee4-7ee1fa24c06a Node side: 16384 Sector size: 4096 Filesystem size: 256.00MiB Block group profiles: Data: single Metadata: DUP System: DUP SSD detected: no Incompat features: extref, skinny-metadata Number of devices: 1 Devices: ID SIZE PATH 1 256.00MiB test.img $ btrfs filesystem show test.img ERROR: not a valid btrfs filesystem: /home/centos/programming/c/gparted/tests/test.img $ echo $1 1 Querying a BTRFS image file also fails as root: $ su Password: # btrfs filesystem show test.img ERROR: not a valid btrfs filesystem: /home/centos/programming/c/gparted/tests/test.img # echo $1 1 However querying the BTRFS via a loop device succeeds: # losetup --show --find test.img /dev/loop0 # btrfs filesystem show /dev/loop0 Label: none uuid: de1624ae-39bb-4796-aee4-7ee1fa24c06a Total devices 1 FS bytes used 112.00KiB devid 1 size 256.00MiB used 88.00MiB path /root/test.img There must be some kernel level BTRFS file system device discovery happening because now after creating a loop device for the image file, the BTRFS can be shown via the image file directly: # btrfs filesystem show test.img Label: none uuid: de1624ae-39bb-4796-aee4-7ee1fa24c06a Total devices 1 FS bytes used 112.00KiB devid 1 size 256.00MiB used 88.00MiB path /root/test.img Anyway for the BTRFS reading tests make them required a loop device and therefore root only. Now these tests are skipped as non-root user and pass as root. Addressing BTRFS resizing test failures will be handled in a following commit. Closes !49 - Add file system interface tests 2019-08-30 Mike Fleetwood Create loop devices for LVM2 PV file system interface tests (!49) Creating an LVM2 PV as a non-root user on an image file fails like this: $ truncate -s 256M test.img $ lvm pvcreate `pwd`/test.img WARNING: Running as a non-root user. Functionality may be unavailable. /run/lvm/lvmetad.socket: access failed: Permission denied WARNING: Failed to connect to lvmetad. Falling back to device scanning. /run/lock/lvm/P_orphans:aux: open failed: Permission denied Can't get lock for orphan PVs. $ echo $? 5 Trying the same as root also fails: # truncate -s 256M test.img # lvm pvcreate `pwd`/test.img Device /root/test.img not found. # echo $? 5 LVM seems strongly predicated on only using block devices [1]. LVM can use loop devices though, but loop devices can only be created by root. # truncate -s 256M test.img # losetup -f --show `pwd`/test.img /dev/loop0 # lvm pvcreate /dev/loop0 Physical volume "/dev/loop0" successfully created. # echo $? 0 Make the LVM2 PV tests require user root and use loop device over the test image. Tests for the other file system types still directly uses the image file. This makes the LVM2 PV tests pass when run as root, or successfully skipped when run as non-root. [1] lvmconfig --typeconfig default --withcomments --withspace | less From the "devices" section of the commented default configuration, LVM uses block devices found below /dev, devices provided by udev and/or found in sysfs. Closes !49 - Add file system interface tests 2019-10-16 Mike Fleetwood Prevent file system tests core dumping in GitLab CI Ubuntu image (!49) With the previous commit, execution of test_SupportedFileSystems is failing in the GitLab CI Ubuntu image. Fragment from file tests/test-suite.log: FAIL: test_SupportedFileSystems =============================== Terminate called after throwing an instance of 'Glib::ConvertError' Aborted (core dumped) FAIL test_SupportedFileSystems (exit status: 134) This core dump can be re-created locally by (1) removing modprobe from the PATH, and (2) executing the test program in the C locale. $ LC_ALL=C ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc terminate called after throwing an instance of 'Glib::ConvertError' Aborted $ echo $? 134 Backtrace from gdb: (gdb) backtrace #0 0x00007f4f93002337 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007f4f93003a28 in __GI_abort () at abort.c:90 #2 0x00007f4f93b2e7d5 in __gnu_cxx::__verbose_terminate_handler() () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x00007f4f93b2c746 in __cxxabiv1::__terminate(void (*)()) (handler=) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38 #4 0x00007f4f93b2c773 in std::terminate() () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48 #5 0x00007f4f93b2c993 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) (obj=0x260d4b0, tinfo=0x7f4f966c1930 , dest=0x7f4f96486fa0 ) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:87 #6 0x00007f4f96486e27 in Glib::ConvertError::throw_func(_GError*) (gobject=0x260bf90) at convert.cc:329 #7 0x00007f4f9649b5d7 in Glib::Error::throw_exception(_GError*) (gobject=0x260bf90) at error.cc:175 #8 0x00007f4f964a7155 in Glib::operator<<(std::ostream&, Glib::ustring const&) (os=warning: RTTI symbol not found for class 'std::ostream' ..., utf8_string=...) at ustring.cc:1430 #9 0x000000000044d66f in GParted::Utils::execute_command(Glib::ustring const&, char const*, Glib::ustring&, Glib::ustring&, bool) (command=..., input=input@entry=0x0, output=..., error=..., use_C_locale=use_C_locale@entry=true) at ../src/Utils.cc:688 #10 0x000000000044dae9 in GParted::Utils::kernel_supports_fs(Glib::ustring const&) (use_C_locale=true, error=..., output=..., command=...) at ../src/Utils.cc:659 #11 0x000000000044dae9 in GParted::Utils::kernel_supports_fs(Glib::ustring const&) (fs=...) at ../src/Utils.cc:480 #12 0x0000000000460008 in GParted::jfs::get_filesystem_support() (this=0x25e8e60) at ../src/jfs.cc:59 #13 0x00000000004464f9 in GParted::SupportedFileSystems::find_supported_filesystems() (this=0x25e8690) at ../src/SupportedFileSystems.cc:120 #14 0x0000000000412360 in GParted::SupportedFileSystemsTest::setup_supported_filesystems() () at test_SupportedFileSystems.cc:278 #15 0x00000000004151b0 in GParted::SupportedFileSystemsTest::get_supported_fstypes() () at test_SupportedFileSystems.cc:256 #16 0x00000000004152c0 in GParted::gtest_MySupportedFileSystemsTest_EvalGenerator_() () at test_SupportedFileSystems.cc:495 #17 0x000000000041c7d6 in testing::internal::ParameterizedTestCaseInfo::RegisterTests() (this=0x2528ac0) at ../lib/gtest/include/gtest/internal/gtest-param-util.h:549 #18 0x0000000000479fb5 in testing::internal::UnitTestImpl::RegisterParameterizedTests() (this=0x25288d0) at ./include/gtest/internal/gtest-param-util.h:709 #19 0x0000000000479fb5 in testing::internal::UnitTestImpl::RegisterParameterizedTests() (this=this@entry=0x2528800) at ./src/gtest.cc:2658 #20 0x000000000048a001 in testing::internal::UnitTestImpl::PostFlagParsingInit() (this=0x2528800) at ./src/gtest.cc:4980 #21 0x000000000049e399 in testing::internal::InitGoogleTestImpl(int*, char**) (argc=argc@entry=0x7ffe9d208a3c, argv=argv@entry=0x7ffe9d208b38) at ./src/gtest.cc:5934 #22 0x000000000048d285 in testing::InitGoogleTest(int*, char**) (argc=argc@entry=0x7ffe9d208a3c, argv=argv@entry=0x7ffe9d208b38) at ./src/gtest.cc:5952 #23 0x0000000000410404 in main(int, char**) (argc=1, argv=0x7ffe9d208b38) at test_SupportedFileSystems.cc:557 The test program runs when executed in my locale and produces these messages: $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc Failed to execute child process “modprobe” (No such file or directory) Failed to execute child process “modprobe” (No such file or directory) [==========] Running 210 tests from 1 test case. ... So the test program is aborting when trying to print the failed to execute child process message, but only in the C locale. This doesn't affect the CentOS GitLab CI image because that installs the kmod package with modprobe by default, however the Ubuntu image doesn't have the kmod package. Fix this by explicitly installing the kmod package into both the CentOS and Ubuntu GitLab CI images. Closes !49 - Add file system interface tests 2019-08-05 Mike Fleetwood Extend tests to all fully supported file systems (!49) Extend testing to all fully supported file systems, those with an implemented FileSystem derived class. Note that in main() GParted threading needs to now be initialised before InitGoogleTest() because it calls INSTANTIATE_TEST_CASE_P() which in turn calls get_supported_fstypes() which eventually constructs all the individual file system interface objects and discovers available support, some of which use execute_command(). Example call chain: InitGoogleTest() INSTANTIATE_TEST_CASE_P() get_supported_fstypes() setup_supported_filesystems() {SupportedFileSystems}->find_supported_filesystems() {btrfs}->get_filesystem_support() Utils::execute_command() In the CentOS 7 GitLab CI image the EPEL (Extra Packages for Enterprise Linux) repository is added to provide f2fs-tools and ntfsprogs. 23 of 210 tests fail on CentOS 7 and 22 on Ubuntu 18.04 LTS. The following commits will resolve these test failures. $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc [==========] Running 210 tests from 1 test case. [----------] Global test environment set-up. [----------] 210 tests from My/SupportedFileSystemsTest ... [----------] 210 tests from My/SupportedFileSystemsTest (11066 ms total) [----------] Global test environment tear-down [==========] 210 tests from 1 test case ran. (11067 ms total) [ PASSED ] 187 tests. [ FAILED ] 23 tests, listed below: [ FAILED ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs, where GetParam() = 23 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16, where GetParam() = 13 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat32, where GetParam() = 14 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/jfs, where GetParam() = 17 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteLabel/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteUUID/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndCheck/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndCheck/minix, where GetParam() = 21 [ FAILED ] My/SupportedFileSystemsTest.CreateAndRemove/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/xfs, where GetParam() = 27 [ FAILED ] My/SupportedFileSystemsTest.CreateAndShrink/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndShrink/lvm2pv, where GetParam() = 20 23 FAILED TESTS Closes !49 - Add file system interface tests 2019-08-04 Mike Fleetwood Print file system types in parameterised test names (!49) Until now the parameterised test values are printed as part of the test names as just 0, 1, etc. like this: $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc [==========] Running 20 tests from 1 test case. [----------] Global test environment set-up. [----------] 20 tests from My/SupportedFileSystemsTest [ RUN ] My/SupportedFileSystemsTest.Create/0 [ OK ] My/SupportedFileSystemsTest.Create/0 (48 ms) [ RUN ] My/SupportedFileSystemsTest.Create/1 [ OK ] My/SupportedFileSystemsTest.Create/1 (11 ms) Provide the file system types as the names for the parameterised test values [1]. Now the test names are printed like this: $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc [==========] Running 20 tests from 1 test case. [----------] Global test environment set-up. [----------] 20 tests from My/SupportedFileSystemsTest [ RUN ] My/SupportedFileSystemsTest.Create/ext2 [ OK ] My/SupportedFileSystemsTest.Create/ext2 (51 ms) [ RUN ] My/SupportedFileSystemsTest.Create/linuxswap [ OK ] My/SupportedFileSystemsTest.Create/linuxswap (11 ms) Also use these Google Test name friendly ASCII alphanumeric only names everywhere the file system type needs to be reported in this test program. [1] Specifying Names for Value-Parameterized Test Parameters https://github.com/google/googletest/blob/v1.8.x/googletest/docs/advanced.md#specifying-names-for-value-parameterized-test-parameters Closes !49 - Add file system interface tests 2019-08-02 Mike Fleetwood Add testing of linux-swap using Value-Parameterised Google Tests (!49) Use Google Test Value-Parameterised to call every test for both ext2 and linux-swap. https://github.com/google/googletest/blob/v1.8.x/googletest/docs/advanced.md#value-parameterized-tests Running the test now looks like this: $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc [==========] Running 20 tests from 1 test case. [----------] Global test environment set-up. [----------] 20 tests from My/SupportedFileSystemsTest [ RUN ] My/SupportedFileSystemsTest.Create/0 [ OK ] My/SupportedFileSystemsTest.Create/0 (97 ms) [ RUN ] My/SupportedFileSystemsTest.Create/1 [ OK ] My/SupportedFileSystemsTest.Create/1 (15 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/0 [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/0 (106 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/1 [ OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/1 (14 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadLabel/0 [ OK ] My/SupportedFileSystemsTest.CreateAndReadLabel/0 (95 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadLabel/1 [ OK ] My/SupportedFileSystemsTest.CreateAndReadLabel/1 (23 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/0 [ OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/0 (99 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/1 [ OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/1 (22 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteLabel/0 [ OK ] My/SupportedFileSystemsTest.CreateAndWriteLabel/0 (102 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteLabel/1 [ OK ] My/SupportedFileSystemsTest.CreateAndWriteLabel/1 (22 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteUUID/0 [ OK ] My/SupportedFileSystemsTest.CreateAndWriteUUID/0 (101 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndWriteUUID/1 [ OK ] My/SupportedFileSystemsTest.CreateAndWriteUUID/1 (21 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndCheck/0 [ OK ] My/SupportedFileSystemsTest.CreateAndCheck/0 (153 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndCheck/1 test_SupportedFileSystems.cc:424: Skip test. check not supported or support not found [ OK ] My/SupportedFileSystemsTest.CreateAndCheck/1 (0 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndRemove/0 test_SupportedFileSystems.cc:437: Skip test. remove not supported or support not found [ OK ] My/SupportedFileSystemsTest.CreateAndRemove/0 (0 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndRemove/1 test_SupportedFileSystems.cc:437: Skip test. remove not supported or support not found [ OK ] My/SupportedFileSystemsTest.CreateAndRemove/1 (0 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndGrow/0 [ OK ] My/SupportedFileSystemsTest.CreateAndGrow/0 (266 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndGrow/1 [ OK ] My/SupportedFileSystemsTest.CreateAndGrow/1 (32 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndShrink/0 [ OK ] My/SupportedFileSystemsTest.CreateAndShrink/0 (111 ms) [ RUN ] My/SupportedFileSystemsTest.CreateAndShrink/1 [ OK ] My/SupportedFileSystemsTest.CreateAndShrink/1 (28 ms) [----------] 20 tests from My/SupportedFileSystemsTest (1311 ms total) [----------] Global test environment tear-down [==========] 20 tests from 1 test case ran. (1342 ms total) [ PASSED ] 20 tests. Closes !49 - Add file system interface tests 2019-09-18 Mike Fleetwood Switch to testing ext2 interface via SupportedFilesystems class (!49) Replace directly using ext2 derived FileSystem interface class with using the SupportedFileSystems class. This is a step in getting ready for testing all the GParted file system interface classes in one go. Closes !49 - Add file system interface tests 2019-07-16 Mike Fleetwood Split FILESYSTEMS and FILESYSTEM_MAP into separate module (!49) GParted_Core::FILESYSTEMS and ::FILESYSTEM_MAP and the methods that query and manipulate them are self-contained. Therefore move them into a separate SupportedFileSystems module. Also having a single class maintaining all FileSystem interface objects will make testing all the file system types much easier as there will be no need to duplicate this functionality in the test. Closes !49 - Add file system interface tests 2019-07-27 Mike Fleetwood Add offline ext2 resizing tests (!49) Closes !49 - Add file system interface tests 2019-07-26 Mike Fleetwood Add simple ext2 write tests: label, UUID, check and remove (!49) Closes !49 - Add file system interface tests 2019-08-27 Mike Fleetwood Reload Partition object after FS creation in read tests (!49) Here are the errors reported in the deliberately broken CreateAndReadLabel test from the previous commit message: [ RUN ] ext2Test.CreateAndReadLabel test_ext2.cc:311: Failure Value of: m_partition.get_messages().empty() Actual: false Expected: true Partition messages: e2label: No such file or directory while trying to open /does_not_exist/test_ext2.img Couldn't find valid filesystem superblock. [ FAILED ] ext2Test.CreateAndReadLabel (77 ms) Even though the test was deliberately broken by setting the wrong path for the file system image and the e2label command failed, apparently testing for the expected label still passed. What happened was that the desired "TEST_LABEL" has to be in the Partition object and then the file system was created. Then reading the file system label failed, however "TEST_LABEL" was already set in the Partition object so it matched. Reading the label is unique among the read actions of usage, label and UUID as the others don't need to be set before the file system is created. GParted doesn't encounter this issue because when refreshing devices it creates new blank Partition objects and then performs the read actions to populate them. Fix by resetting the Partition object back to only containing basic information before all the reading file system information tests, even though it is only needed in the read label case. This also better reflects how GParted works. Now with the same deliberate brokenness the test also reports the label does not match it's expected value: $ ./test_ext2 --gtest_filter='ext2Test.CreateAndReadLabel' Running main() from test_ext2.cc Note: Google Test filter = ext2Test.CreateAndReadLabel [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from ext2Test [ RUN ] ext2Test.CreateAndReadLabel test_ext2.cc:322: Failure Expected equality of these values: fs_label Which is: "TEST_LABEL" m_partition.get_filesystem_label().c_str() Which is: "" test_ext2.cc:272: Failure Value of: m_partition.get_messages().empty() Actual: false Expected: true Partition messages: e2label: No such file or directory while trying to open /does_not_exist/test_ext2.img Couldn't find valid filesystem superblock. [ FAILED ] ext2Test.CreateAndReadLabel (70 ms) [----------] 1 test from ext2Test (70 ms total) [----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (75 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ext2Test.CreateAndReadLabel 1 FAILED TEST Closes !49 - Add file system interface tests 2019-07-26 Mike Fleetwood Add ext2 reading tests: usage, label and UUID (!49) The file system reading methods report errors into Partition messages because they are used as part of the GParted refresh, rather than reporting errors into OperationDetails used when applying operations. Therefore test for no messages for success and print the messages on failure. For example, temporarily breaking the read label test code by setting the wrong file system image name produces this: $ ./test_ext2 --gtest_filter='ext2Test.CreateAndReadLabel' Running main() from test_ext2.cc Note: Google Test filter = ext2Test.CreateAndReadLabel [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from ext2Test [ RUN ] ext2Test.CreateAndReadLabel test_ext2.cc:311: Failure Value of: m_partition.get_messages().empty() Actual: false Expected: true Partition messages: e2label: No such file or directory while trying to open /does_not_exist/test_ext2.img Couldn't find valid filesystem superblock. [ FAILED ] ext2Test.CreateAndReadLabel (77 ms) [----------] 1 test from ext2Test (77 ms total) [----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (85 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ext2Test.CreateAndReadLabel 1 FAILED TEST $ echo $? 1 Closes !49 - Add file system interface tests 2019-10-25 Mike Fleetwood Strip XML markup from the printed operation details (!49) As seen in the first commit message, operation detail text is XML encoded. This makes it harder to read, especially commands which often have single quotes encoded as '. For example: mkfs.ext2 -F -L '' '/home/centos/programming/c/gparted/tests/test_ext2.img' Strip this encoding when printing the operation details. Now the same example looks like: mkfs.ext2 -F -L '' '/home/centos/programming/c/gparted/tests/test_ext2.img' Closes !49 - Add file system interface tests 2019-09-24 Mike Fleetwood Run test program under xvfb-run to satisfy need for an X11 display (!49) Running test_ext2 in GitLab Continuous Integration environment fails like this: (test_ext2:6338): Gtk-WARNING **: 09:06:17.576: cannot open display: Running main() from test_ext2.cc Obviously the GitLab CI environment doesn't have an X11 display, but unfortunately this test case code requires one. Utils::execute_command() calls Gtk::Main::run() so requires a Gtk::Main object constructing and therefore an X11 display, even though this program never displays anything graphical. The call chain is: main() test_ext2.cc Gtk::Main::Main() gtkmm/gtk/src/main.ccg Gtk::Main::init() [1] gtk_init() gtk/gtk/gtkmain.c [2] which exits with a non-zero exit status when the DISPLAY environment variable is unset. Looked at deriving from Gtk::Main class and writing a replacement init() method which calls gtk_init_check() instead of gtk_init() but Gtk::Main::instance_ is a private member so not accessible in a derived class. Tried using Glib::MainLoop instead of Gtk::Main, but that doesn't initialise everything that Gtk::Main(), so the program crashes. Therefore use xvfb-run [3][4] to run this test program against a virtual X11 display when a real display isn't available. Coded execution of xvfb-run into this test program so that it can simply be executed on the command line like the other test programs, without having to remember to run "xvfb-run ./test_ext2 ...". [1] Gtk::Main::init() https://gitlab.gnome.org/GNOME/gtkmm/blob/3.10.1/gtk/src/main.ccg#L287 [2] gtk_init() https://gitlab.gnome.org/GNOME/gtk/blob/3.10.9/gtk/gtkmain.c#L1000 [3] how to run gtk app on linux without an x server https://superuser.com/questions/624918/how-to-run-gtk-app-on-linux-without-an-x-server [4] Using GTK without DISPLAY https://stackoverflow.com/questions/11694278/using-gtk-without-display Closes !49 - Add file system interface tests 2019-07-17 Mike Fleetwood Add initial create ext2 only FileSystem interface class test (!49) This is the first step of adding testing of the derived FileSystem interface classes which call the file system specific executables. Rather than mocking command execution and returned output the tests run the real commands, effectively making this integration testing. Test case setup determines the file system supported actions using get_filesystem_support() and individual tests are skipped if a feature is not supported, just as GParted does for it's actions. Each test creates it's own sparse image file and a fresh file system, performs a test on one FileSystem interface call and deletes the image file. This makes each test independent and allows them to run as a non-root user, provided the file system command itself doesn't require root. Errors reported for a failed interface call will include the GParted OperationDetails, which in turn includes the file system specific command used and stdout and stderr from it's execution. For example, temporarily breaking the test code to create a 10 KiB image file instead of 256 MiB one produces this: $ ./test_ext2 Running main() from test_ext2.cc [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from ext2Test [ RUN ] ext2Test.Create test_ext2.cc:199: Failure Value of: s_ext2_obj->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.ext2 -F -L '' '/home/centos/programming/c/gparted/tests/test_ext2.img' 00:00:00 (ERROR) mke2fs 1.42.9 (28-Dec-2013) /home/centos/programming/c/gparted/tests/test_ext2.img: Not enough space to build proposed filesystem while setting up superblock [ FAILED ] ext2Test.Create (25 ms) [----------] 1 test from ext2Test (25 ms total) [----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (30 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ext2Test.Create 1 FAILED TEST $ echo $? 1 Also as Utils:: and FileSystem::execute_command() are needed, this requires linking with GParted_Core for GParted_Core::mainthread and therefore with most of the non-UI classes in gpartedbin. Closes !49 - Add file system interface tests 2019-06-27 Mike Fleetwood Rename enumeration to MENU_LABEL_FILESYSTEM To match the renaming performed as part of Bug 741424 "Add support for GPT partition names". In particular this is most closely similar to: d480800600be714a0e706b51a147d329d8280e52 Rename enum to OPERATION_LABEL_FILESYSTEM (#741424) 2019-09-29 Mike Fleetwood Print OS details in the GitLab CI (!48) Just a simple debugging aid to have the OS details printed in the GitLab CI output. Closes !48 - Remain with CentOS 7 for GitLab CI 2019-09-29 Mike Fleetwood Remain with CentOS 7 for GitLab CI (!48) When GParted GitLab Continuous Integration was setup, CentOS 7 image was used for a slow moving distribution and Ubuntu as a different, faster moving distribution. CentOS 8 has recently been released [1]. To avoid automatically switching to it when an official CentOS 8 docker image is made available [2], explicitly specify the CentOS 7 image. [1] Release for CentOS Linux 8 and CentOS Streams (2019-09-24) https://lists.centos.org/pipermail/centos-announce/2019-September/023449.html [2] Docker Official Images, The official build of CentOS https://hub.docker.com/_/centos/ Closes !48 - Remain with CentOS 7 for GitLab CI 2019-10-02 Marek Černocký Updated Czech help translation 2019-10-02 Marek Černocký Updated Czech translation 2019-09-19 Jordi Mas Update Catalan translation 2019-08-22 Anders Jonsson Update Swedish translation 2019-08-13 Jordi Mas Update Catalan translation 2019-08-13 Asier Sarasua Garmendia Update Basque translation 2019-08-11 Daniel Șerbănescu Update Romanian translation 2019-07-22 Mathias L. Baumann Fix invalid substitution in de.po (!47) Fixes the error: (gpartedbin:995): glibmm-WARNING **: 09:11:54.522: invalid substitution "%2" in fmt string "%2 Operationen stehen momentan aus." Closes !47 - Fix invalid substitution in de.po 2019-06-29 Mike Fleetwood Erase correct key in unit test PasswordRAMStoreTest.TooLongPassword Was attempting to erase the wrong key "key-long" for the test. It should be erasing "key-too-long". Fix this. Given that that line in the test was to erase a non-existent key and confirm failure; the test passed before with the wrong non-existent key, and still passes with the right non-existent key. Clearly a cut and paste error as a result of copying the previous LongPassword test when initially added in: c6657aab9efe8cefece2017bee4bef9ece607e73 Add unit tests for PasswordRAMStore module (#795617) 2019-07-06 Mike Fleetwood Drop use of long ago removed udevsettle Separate udevsettle command was merged into udevadm back in udev 117 (released 2007-11-13) by: https://github.com/systemd/systemd/commit/225cb03bd851adc6d269b13bdf2b1bfded2b96b9 udevadm: merge all udev tools into a single binary The oldest supported distributions have these much newer versions of udev: Distro EOL udevadm -V Debian 8 2020-Apr 215 (combined systemd and udev) RHEL / CentOS 7 2024-Jun 219 (combined systemd and udev) Ubuntu 16.04 LTS 2021-Apr 229 (combined systemd and udev) 2019-07-12 Mike Fleetwood Order internally detected signatures by increasing offset (!46)(#16) Along with the previous patch "Avoid reading the same sector multiple times in a row (!46)(#16)" internal detection of file system signatures now reads the minimum number of sectors in increasing order. As the code still considers the sector size, it now also reads less sectors from devices with larger sectors to get all the signatures. So on a 512 byte sector device it maximally seeks to and reads from these byte offsets: 0, 512, 1024, 65536 and on a 4096 byte sector device, only from these byte offsets: 0, 65536 Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel Closes #16 - "invalid argument for seek()" error on very small (<=40KiB) drives 2019-07-12 Mike Fleetwood Avoid reading the same sector multiple times in a row (!46)(#16) GParted internal file system detection is reading the same sector multiple times in a row. Add an optimisation to only read a sector if it is different to the previously read sector. Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel Closes #16 - "invalid argument for seek()" error on very small (<=40KiB) drives 2019-07-11 Mike Fleetwood Just pass sector size to detect_filesystem_internal() (!46)(#16) After the previous commit the lp_device structure pointer parameter is only used to provide sector_size. Just pass that instead. Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel Closes #16 - "invalid argument for seek()" error on very small (<=40KiB) drives 2019-07-11 Mike Fleetwood Switch to POSIX open() in detect_filesystem_internal() (!46)(#16) For every partitioned device that GParted scans it triggers a set of udev change events from it's internal file system signature detection function. This is the sequence of events: gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"] gparted | ped_device_get("/dev/sdb") libparted | open("/dev/sdb", O_RDONLY) = 8 libparted | close(8) gparted | useable_device(lp_device) lp_device->path="/dev/sdb" gparted | open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 8 gparted | read(8, ...) gparted | close(8) gparted | set_device_from_disk(device, device_path="/dev/sdb") gparted | get_device(device_path="/dev/sdb", ..., flush=true) gparted | ped_device_get() gparted | flush_device(lp_device) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_sync() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | settle_device() gparted | Utils::execute_command("udevadm settle --timeout=1") gparted | detect_filesystem(lp_device, NULL, ...) lp_device->path="/dev/sdb" gparted | detect_filesystem_internal(lp_device, NULL) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | get_disk(lp_device, lp_disk, strict=false) gparted | ped_disk_new(lp_device) lp_device->path="/dev/sdb" libparted | open("/dev/sdb", O_RDWR) = 8 libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | settle_device() gparted | Utils::execute_command("udevadm settle --timeout=1") gparted | set_device_partitions() gparted | detect_filesystem() gparted | set_partition_label_and_uuid(partition) partition.get_path()="/dev/sdb1" gparted | read_label() gparted | ext2::read_label() gparted | Utils::execute_command("e2label /dev/sdb1") Note that the udev block device change events triggered in detect_filesystem_internal() occur before the waited for ones in the second commit "Wait for udev to recreate /dev/PTN entries when querying partition FSs (!46)" in get_disk() so these were already waited for. The call chain is: set_devices_thread() set_device_from_disk() detect_filesystem() detect_filesystem_internal() ped_device_open() ped_device_read() ped_device_close() This occurs because file system detection is performed on whole disk devices, but the device contains a partition table, so blkid won't report any content GParted accepts as a file system, so it tries it's own internal detection. Fix this by changing detect_filesystem_internal() to use POSIX open(), read() and close() so the file can be opened read-only and udev change events aren't triggered. Note that when using detect_filesystem_internal() on a partition this also changes the device it reads from. Before it used libparted which always reads from the whole disk device, now it reads from the partition device. This doesn't matter because GParted ensures the data is consistent between them [2] and blkid reads from each partition device which GParted already uses. As the new code avoids using the libparted API, and just skips to the next signature on lseek() and read() errors, it therefore won't generate libparted exceptions such as this when scanning very small drives: Invalid argument during seek for read on /dev/PTN [1] f8faee637787329c07771e495c9b26abc9ac1603 Avoid whole disk FAT being detected as MSDOS partition table (#743181) [2] 3bea067596e3e2d6513cda2a66df1b3e4fa432fb Flush devices when scanning to prevent reading stale signatures (#723842) Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel Closes #16 - "invalid argument for seek()" error on very small (<=40KiB) drives 2019-07-10 Mike Fleetwood Pass unmodified parameter to useable_device() as const (!46) GParted_Core::useable_device() doesn't change the pointed to PedDevice structure. Pass it as const so the compiler enforces this. Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel 2019-07-10 Mike Fleetwood Switch to POSIX open() in useable_device() (!46) For every device that GParted scans, it determines if it can be used by attempting to read the first sector. This is the sequence of events, as reported in the previous two commit messages: gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"] ... gparted | useable_device(lp_device) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_read() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL change /devices/.../sdb (block) ... udev(async)| UDEV change /devices/.../sdb (block) Note that these udev block device change events occur before the ones waited for in the first commit "Wait for udev change on /dev/DISK when querying whole device FS (!46)" so these were already waited for. So because libparted only opens devices read-write this triggers a set of udev change events for the whole block device, and if the device is partitioned, also remove and re-add events for all the partitions. Switch to using POSIX open(), read() and close() calls so read-only access can be specified to avoid the unnecessary udev change events. Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel 2019-07-13 Mike Fleetwood Wait for udev to recreate /dev/PTN entries when querying partition FSs (!46) After the previous fix, on my CentOS 7 VM, GParted is now often reporting a warning that the /dev/PTN entry is missing when reading the label of the file system in the first partition. This happens regardless of the file system type. Example error for EXT4: e2label: No such file or directory while trying to open /dev/sdb1 Couldn't find valid file system superblock. Example error for XFS: /dev/sdb1: No such file or directory fatal error -- couldn't initialize XFS library As with the case in the previous commit, GParted gets the label via blkid instead. Again with debugging and sleeping in GParted, stracing the GParted thread GParted_Core::set_devices_thread() and using 'udevadm monitor' to watch udev events the following sequence of events is observed: gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"] gparted | ped_device_get("/dev/sdb") libparted | open("/dev/sdb", O_RDONLY) = 8 libparted | close(8) gparted | useable_device(lp_device) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_read() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | set_device_from_disk(device, device_path="/dev/sdb") gparted | get_device(device_path="/dev/sdb", ..., flush=true) gparted | ped_device_get() gparted | flush_device(lp_device) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_sync() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | settle_device() gparted | Utils::execute_command("udevadm settle --timeout=1") gparted | detect_filesystem(lp_device, NULL, ...) lp_device->path="/dev/sdb" gparted | detect_filesystem_internal(lp_device, NULL) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_read() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | get_disk(lp_device, lp_disk, strict=false) gparted | ped_disk_new(lp_device) lp_device->path="/dev/sdb" libparted | open("/dev/sdb", O_RDWR) = 8 libparted | close(8) udev(async)| KERNEL remove /devices/.../sdb/sdb1 (block) udev(async)| KERNEL remove /devices/.../sdb/sdb2 (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL add /devices/.../sdb/sdb1 (block) udev(async)| KERNEL add /devices/.../sdb/sdb2 (block) udev(async)| UDEV remove /devices/.../sdb/sdb1 (block) udev(async)| UDEV remove /devices/.../sdb/sdb2 (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV add /devices/.../sdb/sdb1 (block) udev(async)| UDEV add /devices/.../sdb/sdb2 (block) gparted | set_device_partitions() gparted | detect_filesystem() gparted | set_partition_label_and_uuid(partition) partition.get_path()="/dev/sdb1" gparted | read_label() gparted | ext2::read_label() gparted | Utils::execute_command("e2label /dev/sdb1") So in this case for a partitioned drive, libparted ped_disk_new() is opening and closing the device read-write and triggering the udev remove and add partition block special entries exactly when the label is trying to be read from the first partition, causing the device missing error. The call chain is: set_devices_thread() set_device_from_disk() get_disk() ped_disk_new() Looking at the source for ped_disk_new() [1] it is calling ped_device_open() and ped_device_close(), hence why it is opening the device read-write and triggering the udev events. Looking back at commit "Wait for udev to recreate /dev/PTN entries when calibrating (#762941)" [2] and re-testing it, the udev events were also caused by ped_disk_new() with this call chain: apply_operation_to_disk() calibrate_partition() get_disk() ped_disk_new() Fix this probe case and keep the fix for the previous calibrate case by moving the waiting for udev events from calibrate_partition() into get_disk(), right after ped_disk_new(). The maximum wait time is shortened to the shorter 1 second probing timeout to avoid the longer 10 second apply timeout in this probing case. The calibrate case commit message said "The longest I have seen udev take to do this is 0.80 seconds in a VM". [1] parted/libparted/disk.c:ped_disk_new() http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/disk.c?id=v3.2#n169 [2] fd9013d5f6971e9282f019903d6e148e367718bf Wait for udev to recreate /dev/PTN entries when calibrating (#762941) Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel 2019-07-09 Mike Fleetwood Wait for udev change on /dev/DISK when querying whole device FS (!46) GParted nearly always shows this warning against a whole disk device FAT32 file system on my development VMs: plain floppy: device "/dev/sdb" busy (Resource temporarily unavailable): Cannot initialize '::' mlabel: Cannot initialize drive However GParted does get the label via blkid instead. Occasionally everything works correctly and there is no warning. Never found a similar error for any other file system on a whole disk device. The timing never seems to clash. Remember that when a writable file descriptor of a disk device is closed, udev events are triggered which update the kernel and /dev entries for any partition changes. (This is in addition to coding which has always existed in the partitioning tools, including fdisk and parted, to inform the kernel, but not create /dev entries, of partition changes). With debugging and sleeping in GParted, stracing the GParted thread GParted_Core::set_devices_thread() and using 'udevadm monitor' to watch udev events the following sequence of events is observed: gparted |set_devices_thread(pdevices) pdevices->["/dev/sdb"] gparted | ped_device_get("/dev/sdb") libparted | open("/dev/sdb", O_RDONLY) = 8 libparted | close(8) gparted | useable_device(lp_device) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_read() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV change /devices/.../sdb (block) gparted | set_device_from_disk(device, device_path="/dev/sdb") gparted | get_device(device_path="/dev/sdb", ..., flush=true) gparted | ped_device_get() gparted | flush_device(lp_device) lp_device->path="/dev/sdb" gparted | ped_device_open() libparted | open("/dev/sdb", O_RDWR) = 8 gparted | ped_device_sync() gparted | ped_device_close() libparted | close(8) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| KERNEL change /devices/.../sdb (block) udev(async)| UDEV change /devices/.../sdb (block) udev(async)| UDEV change /devices/.../sdb (block) gparted | set_device_one_partition() gparted | set_partition_label_and_uuid() gparted | read_label() gparted | fat16::read_label() gparted | Utils::execute_command("mlabel -s :: -i /dev/sdb") This sequence of events only shows which close()s by libparted trigger udev events. It does not show that processing those events are asynchronous and overlap with GParted executing mlabel, causing the device busy error. As libparted's ped_device_open() doesn't offer a way to specify that a device will only be used for reading, it always opens it read-write [1][2]. Hence this sequence in GParted_Core::flush_device(): ped_device_open() ped_device_sync() ped_device_close() always triggers udev change events on the whole disk device. Fix by waiting for those udev events to complete. [1] libparted documentation, PedDevice, ped_device_open() https://www.gnu.org/software/parted/api/group__PedDevice.html#ga7c87bd06e76553c8ff3262b5e6ca256 [2] parted/libparted/arch/linux.c:linux_open() http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c?id=v3.2#n1628 Closes !46 - Whole device FAT32 file system reports device busy warning from mlabel 2019-07-18 Rafael Fontenelle Update Brazilian Portuguese translation 2019-04-01 Mike Fleetwood Drop use of long ago removed udevinfo The last distribution to include the separate 'udevinfo' command was RHEL / CentOS 5 with udev 095. All supported distributions have much newer versions of udev and instead have the 'udevadm' command. 2019-06-18 Mike Fleetwood Switch to faster minfo and mdir to read FAT16/32 usage (#569921) A user reported that GParted was slow to refresh on FAT32 file systems: "can take very long, up to several minutes; can be reproduced by running dosfsck manually". This is because the file system was large and almost full, and GParted performs a file system check just to to report the file system usage. Created a 4 GiB FAT32 file system and almost filled it with 4 KiB files, just over 970,000 files. # df -k /mnt/2 Filesystem 1K-blocks Used Available Used% Mounted on /dev/sdb2 4186108 39155384 270724 94% /mnt/2 # df -i /mnt/2 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb2 0 0 0 - /mnt/2 # find /mnt/2 -type f -print | wc -l 971059 # find /mnt/2 -type d -print | wc -l 1949 Testing performance of the current fsck.fat: # time fsck.fat -n -v /dev/sdb2 | \ > egrep 'bytes per logical sector|bytes per cluster|sectors total|clusters$' 512 bytes per logical sector 4096 bytes per cluster 8388608 sectors total /dev/sdb2: 973008 files, 978846/1046527 clusters real 0m11.552s user 0m2.183s sys 0m7.547s Free sectors in the file system according to fsck.fat: (1046527 - 978846) * 4096 / 512 = 541448 sectors Repeating this test while also using 'blktrace /dev/sdb2' and Ctrl-C around the test in a separate terminal, reports these numbers of I/Os being performed: Read requests Read bytes 15,563 165 MiB Prior to this commit [1] from 0.0.9, GParted used libparted's ped_file_system_get_resize_constraint() to report the minimum size to which a FAT* file system can be resized. Use this test program [2] to performance test this method: # time ./fscons /dev/sdb2 dev=/dev/sdb2 sector_size=512 min_size=7909522 max_size=8388608 real 0m2.673s user 0m0.070s sys 0m1.834s Free sectors in the file system according to libparted ped_file_system_get_resize_constraint(): 8388608 - 7909522 = 479086 sectors blktrace reports these numbers of I/Os being performed: Read requests Read bytes 7,821 71 MiB So using libparted resize constraint is a bit faster but is still reading too much data and is really too slow. Also when testing GParted using this libparted method against a corrupted FAT32 file system, on every refresh, one popup dialog is displayed for each error libparted detects with the file system, each of which needs acknowledgement. Example popup: Libparted Error \DIRNAME\FILENAME.EXT is 107724k, but is has 1920 clusters (122880k). [ Cancel ][ Ignore ] There could be a huge number of such errors in a corrupted file system. Not really suitable for use by GParted. Test the performance of mtools' minfo command to report the file system figures: # time minfo -i /dev/sdb2 :: | \ > egrep 'sector size:|cluster size:|small size:|big size:|free clusters=' sector size: 512 bytes cluster size: 8 sectors small size: 0 sectors big size: 8388608 sectors free clusters=67681 real 0m0.013s user 0m0.004s sys 0m0.019s Free sectors in the file system according to minfo: 67681 * 8 = 541448 sectors blktrace reports these numbers of I/Os being performed by minfo: Read requests Read bytes 1 16 KiB This matches with minfo just reading information from the BPB (BIOS Parameter Block) [3] from sector 0 and the FS Information Sector [4] usually in sector 1. Note that the free cluster figure reported by minfo comes from the FS Information Sector because it only reports it for FAT32 file systems, not for FAT16 file systems. Scanning the File Allocation Table (FAT) [5] to count free clusters is exactly what mdir, without the '-f' (fast) flag, does. Test the performance of mdir: # export MTOOLS_SKIP_CHECK=1 # time mdir -i /dev/sdb2 ::/ | fgrep 'bytes free' 277 221 376 bytes free real 0m0.023s user 0m0.011s sys 0m0.023s Free sectors in the file system according to mdir: 277221376 / 512 = 541448 sectors blktrace reports these number of I/Os being performed by mdir: Read requests Read bytes 5 448 KiB So minfo and mdir together provide the needed information and are 2 to 3 orders of magnitude faster because they only read the needed BPB and FAT data from the drive. Use these together to read the file system usage. [1] 61cd0ce77879e4af84280ddcf77959ae55885ba4 lots of stuff and cleanups, including fixing getting used/unused space of hfs/hfs+/fat16/fat32 [2] fscons.c /* FILE: fscons.c * SYNOPSIS: Report libparted's FS resize limits. * BUILD: gcc -o fscons fscons.c -lparted -lparted-fs-resize */ int main(int argc, const char *argv[]) { PedDevice* dev = NULL; PedDisk* tab = NULL; PedPartition* ptn = NULL; PedFileSystem* fs = NULL; PedConstraint* cons = NULL; if (argc != 2) { fprintf(stderr, "Usage: fscons BLOCKDEV\n"); exit(1); } dev = ped_device_get(argv[1]); if (dev == NULL) { fprintf(stderr, "ped_device_get(\"%s\") failed\n", argv[1]); exit(1); } printf("dev=%s\n", dev->path); printf("sector_size=%ld\n", dev->sector_size); tab = ped_disk_new(dev); if (tab == NULL) { fprintf(stderr, "ped_disk_new(dev) failed\n"); exit(1); } ptn = ped_disk_get_partition_by_sector(tab, 0); if (ptn == NULL) { fprintf(stderr, "ped_disk_get_partition(tab, 0) failed\n"); exit(1); } fs = ped_file_system_open(&ptn->geom); if (fs == NULL) { fprintf(stderr, "ped_file_system_open(&ptn->geom) failed\n"); exit(1); } cons = ped_file_system_get_resize_constraint(fs); if (cons == NULL) { fprintf(stderr, "ped_file_system_get_resize_constraint(fs) failed\n"); exit(1); } printf("min_size=%ld\n", cons->min_size); printf("max_size=%ld\n", cons->max_size); ped_constraint_destroy(cons); ped_file_system_close(fs); ped_disk_destroy(tab); ped_device_destroy(dev); return 0; } [3] Design of the FAT file system, BIOS Parameter Block https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#BIOS_Parameter_Block [4] Design of the FAT file system, FS Information Sector https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FS_Information_Sector [5] Design of the FAT file system, File Allocation Table https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#File_Allocation_Table Bug 569921 - dosfsck -n delays device scan 2019-06-22 Goran Vidović Update Croatian translation 2019-06-19 Balázs Úr Update Hungarian translation 2019-06-19 Daniel Mustieles Updated Spanish translation 2019-06-16 Piotr Drąg Update Polish translation 2019-06-11 Curtis Gedak Add missing window title to Help Contents dialog (!45) When GParted is configured with `--disable-doc` the help documentation is neither built, nor installed. With this configuration the Help -> Contents menu displays a message dialog indicating the "Documentation is not available". On GNOME 3 no title is shown; however, on some other graphic toolkits / window managers an unspecified title is shown. For example on GParted Live with Fluxbox the following is displayed: Unnamed ------- Documentation is not available This build of gparted is configured without documentation. Documentation is available at the project web site. https://gparted.org OK To address the unspecified title on non-GNOME 3 graphic toolkits, add a title that works with and without GNOME 3. Closes !45 - Add missing window title to Help Contents dialog 2019-05-10 Mike Fleetwood Add missing Device.h include into GParted_Core and Win_GParted The files GParted_Core.h, GParted_Core.cc and Win_GParted.cc all use the Device type but don't include Device.h for it's definition. Include it. 2019-05-21 Mike Fleetwood Replace partition boundary trimming with bug error messages (#48) All the dialogs which compose new or modified partition boundaries create those partitions within the boundaries of the device. Therefore trimming the partition boundaries to device boundaries never happens. So replace this trimming with bug error reports. Also add bug prefixes to the other error messages in GParted_Core::valid_partition() too. Closes #48 - Error when moving locked LUKS-encrypted partition 2019-05-22 Mike Fleetwood White space layout update in snap_to_mebibyte/cylinder() (#48) The previous commit moved the code from GParted_Core to Dialog_Base_Partition class without making a single formatting change to ensure the code was guaranteed to work the same within that larger commit. Now reformat the code to current layout standards. Making it a separate commit simplifies the effort for both changes and improves bisectability. Additionally to be sure there were no code changes, Dialog_Base_Partition.cc was compiled to assembler code with and without this change applied and the resultant assembler code compared. There were no differences in the generated assembler code. Start with the make generated g++ command for compiling Dialog_Base_Partition.o; (1) remove the '-g' flag as inserted debugging directives do differ; and (2) replace '-c -o Dialog_Base_Partition.o' with '-S -o Dialog_Base_Partition.s' to produce assembler output instead of object code. Closes #48 - Error when moving locked LUKS-encrypted partition 2019-05-19 Mike Fleetwood Snap partition boundaries before dialogs update FS usage (#48) Move snap_to_*() method calls from the point when all operations are added to the list, to earlier when Resize/Move, Paste (into new) and Create New dialogs are composing the new partition objects. In particular for the Resize/Move operation, to just before updating the file system usage. This change finally resolves this bug. Because of the dialog call chains into Dialog_Base_Partition, snap_to_alignment() must be added into: * Dialog_Base_Partition::prepare_new_partition() for the Resize/Move and Paste (into new) dialogs; and * Dialog_Partition_New::Get_New_Partition() for the Create New dialog. Closes #48 - Error when moving locked LUKS-encrypted partition 2019-05-10 Mike Fleetwood Pass the current device down to Dialog_Base_Partition class (#48) The current device has to be passed to the dialog constructors and then on to the Dialog_Base_Constructor. Note that the Dialog_Partition_New constructor is already passed the current device, however it still needs to pass it on to Dialog_Base_Constructor. This is ready so that snap_to_*() methods can access the current device when they are called from within these dialogs. * Pass Parameter to Base Class Constructor while creating Derived class Object https://stackoverflow.com/questions/16585856/pass-parameter-to-base-class-constructor-while-creating-derived-class-object Closes #48 - Error when moving locked LUKS-encrypted partition 2019-05-10 Mike Fleetwood Update file system usage last in prepare_new_partition() (#48) Move setting of the new_partition object file system usage to after everything else, specifically after free_space_before and strict_start. This is because snap_to_*() use free_space_before and strict_start and snap_to_alignment() is going to be called before the file system usage is updated to avoid the error in this bug report. Closes #48 - Error when moving locked LUKS-encrypted partition 2019-05-09 Mike Fleetwood Remove unused error reporting from snap_to_*() (#48) None of the snap_to_*() methods report any errors so remove the unused error parameter and return value. Closes #48 - Error when moving locked LUKS-encrypted partition 2019-05-08 Mike Fleetwood Separate partition alignment from validation (#48) PATCHSET OVERVIEW A user had 2 adjacent partitions which were aligned to multiples of 33553920 bytes (32 MiB - 512 bytes), not MiB or cylinders. As far as GParted is concerned this is not aligned. The second partition contained closed LUKS encrypted data. Recreate this setup with: # truncate -s 200G /tmp/disk.img # losetup -f --show /tmp/disk.img /dev/loop0 # sfdisk -u S /dev/loop0 << EOF 65535 2162655 83 2228190 78904140 83 EOF # partprobe /dev/loop0 # echo -n badpassword | cryptsetup luksFormat /dev/loop0p2 - When trying to move the second LUKS encrypted partition to the right by any amount, with the default MiB alignment, GParted displays this error dialog and fails to even queue the operation: Could not add this operation to the list A partition with used sectors (78907392) greater than its length (78905344) is not valid [ OK ] Overview of the steps involved: 1. The Resize/Move dialog composed a new partition to start a whole multiple of MiB after the end of the previous non-aligned partition. The new partition also had it's size increased to a whole multiple of MiB, to 78907392 sectors (38529 MiB) which was 1.59 MiB larger than before. Neither the start or end of the new partition are aligned at this point. 2. Win_GParted::activate_resize() applied the change back to the closed LUKS partition object, additionally making the used sectors equal to the partition size. (To match the fact that when opened the LUKS mapping it will automatically fill the new larger partition size). 3. GParted_Core::snap_to_mebibyte() then aligned the partition start and end to whole MiB boundaries, reducing the partition size in the process to 78905344 (38528 MiB). 4. GParted_Core::snap_to_alignment() reported the error saying that it couldn't add the operation to the list because it was invalid to have the file system used sectors larger than the partition size. Fix this by having the snap to alignment adjustments applied before the dialogs update any associated file system usage. Specifically the Resize/Move, Paste (into new) and Create New dialogs as these are the only ones which either create or modify partition boundaries. Validation done by snap_to_alignment() will continue to occur at the current point when the operation is added to the list. THIS COMMIT snap_to_alignment() is doing two different jobs, it is (1) optionally adjusting the new partition boundaries for MiB or Cylinder alignment; and (2) checking that the partition boundaries and file system usage are valid. Split those into two different functions (1) snap_to_alignment() and (2) valid_partition(). For now valid_partition() still calls snap_to_alignment() so there is no functional change with this commit. Closes #48 - Error when moving locked LUKS-encrypted partition 2019-06-09 Daniel Șerbănescu Update Romanian translation 2019-06-06 Wolfgang Stöggl Update German translation 2019-06-03 Balázs Úr Update Hungarian translation 2019-05-22 Félix Piédallu Fix test (dentry->d_name is invalidated by closedir...) (!41) We have to copy the dentry->d_name before calling closedir(). If not, the string points to nothing and the test fails (It does not fail all the time, but only by chance). Confirmed using valgrind. Selected output from running the unit test under valgrind: $ valgrind --track-origins=yes ./test_blockSpecial ==25110== Memcheck, a memory error detector ... ==25110== Command: ./test_BlockSpecial ==25110== Running main() from src/gtest_main.cc [==========] Running 26 tests from 1 test case. [----------] Global test environment set-up. [----------] 26 tests from BlockSpecialTest ... [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches ==25110== Invalid read of size 1 ==25110== at 0x4C2C9B2: strlen (vg_replace_strmem.c:458) ==25110== by 0x40E7C4: length (char_traits.h:259) ==25110== by 0x40E7C4: append (basic_string.h:1009) ==25110== by 0x40E7C4: operator+, std::allocator > (basic_string.h:2468) ==25110== by 0x40E7C4: get_link_name (test_BlockSpecial.cc:156) ==25110== by 0x40E7C4: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247) ... =25110== Address 0x1231ea93 is 115 bytes inside a block of size 32,816 free'd ==25110== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==25110== by 0x9F773AC: closedir (in /usr/lib64/libc-2.17.so) ==25110== by 0x40E7AC: get_link_name (test_BlockSpecial.cc:153) ==25110== by 0x40E7AC: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247) ... ==25110== Block was alloc'd at ==25110== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==25110== by 0x9F77280: __alloc_dir (in /usr/lib64/libc-2.17.so) ==25110== by 0x40E746: get_link_name (test_BlockSpecial.cc:134) ==25110== by 0x40E746: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247) ... ==25110== Invalid read of size 1 ==25110== at 0x4C2E220: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022) ==25110== by 0x953A997: std::string::append(char const*, unsigned long) (in /usr/lib64/libstdc++.so.6.0.19) ==25110== by 0x40E7D2: append (basic_string.h:1009) ==25110== by 0x40E7D2: operator+, std::allocator > (basic_string.h:2468) ==25110== by 0x40E7D2: get_link_name (test_BlockSpecial.cc:156) ==25110== by 0x40E7D2: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247) ... ==25110== Address 0x1231ea93 is 115 bytes inside a block of size 32,816 free'd ==25110== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==25110== by 0x9F773AC: closedir (in /usr/lib64/libc-2.17.so) ==25110== by 0x40E7AC: get_link_name (test_BlockSpecial.cc:153) ==25110== by 0x40E7AC: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247) ... ==25110== Block was alloc'd at ==25110== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==25110== by 0x9F77280: __alloc_dir (in /usr/lib64/libc-2.17.so) ==25110== by 0x40E746: get_link_name (test_BlockSpecial.cc:134) ==25110== by 0x40E746: GParted::BlockSpecialTest_NamedBlockSpecialObjectBySymlinkMatches_Test::TestBody() (test_BlockSpecial.cc:247) ... [ OK ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (50 ms) Selected lines from test_BlockSpecial.cc: 132 static std::string get_link_name() 133 { 134 DIR * dir = opendir( "/dev/disk/by-id" ); ... 141 bool found = false; 142 struct dirent * dentry; 143 // Silence GCC [-Wparentheses] warning with double parentheses 144 while ( ( dentry = readdir( dir ) ) ) 145 { 146 if ( strcmp( dentry->d_name, "." ) != 0 && 147 strcmp( dentry->d_name, ". " ) != 0 ) 148 { 149 found = true; 150 break; 151 } 152 } 153 closedir( dir ); 154 155 if ( found ) 156 return std::string( "/dev/disk/by-id/" ) + dentry->d_name; So the memory referred to by dentry was allocated on line 134, freed on 153 and accessed after freed on 156. Closes !41 - Fix test (dentry->d_name is invalidated by closedir...) 2019-05-29 Curtis Gedak Fix link typo in French translation of GParted help manual 2019-05-29 Curtis Gedak Append -git to version for continuing development 2019-05-29 Curtis Gedak ========== gparted-1.0.0 ========== 2019-05-29 Curtis Gedak Update copyright years 2019-05-28 Claude Paroz Update French translation 2019-05-24 Mike Fleetwood Fix reading NTFS usage after resize (#57) After an NTFS file system has been resized the command GParted currently uses to read the file system usage fails like this: # ntfsinfo --mft /dev/sdb1 Volume is scheduled for check. Please boot into Windows TWICE, or use the 'force' option. NOTE: If you had not scheduled check and last time accessed this volume using ntfsmount and shutdown system properly, then init scripts in your distribution are broken. Please report to your distribution developers (NOT to us!) that init scripts kill ntfsmount or mount.ntfs-fuse during shutdown instead of proper umount. Failed to open '/dev/sdb1'. Fix by added the '--force' flag as described in the error message. Closes #57 - NTFS Resize results in Partition Information Warning on Refresh 2019-05-24 Mike Fleetwood Report errors correctly on failure to read NTFS usage (#57) GParted uses ntfsinfo to read the NTFS file system usage. However when ntfsinfo fails with a non-zero exit status GParted reports stdout twice, rather than stdout and stderr. Correct this. Closes #57 - NTFS Resize results in Partition Information Warning on Refresh 2019-05-26 Anders Jonsson Update Swedish translation 2019-05-26 Anders Jonsson Update Swedish translation 2019-05-25 Trần Ngọc Quân Updated Vietnamese translation Signed-off-by: Trần Ngọc Quân 2019-05-22 Jiri Grönroos Update Finnish translation 2019-05-22 Claude Paroz Update French translation 2019-05-22 Rafael Fontenelle Update Brazilian Portuguese translation 2019-05-22 Sveinn í Felli Update Icelandic translation 2019-05-03 Luca Bacci Set the xalign property for Gtk::Labels (!40) With the same case as from the previous commit, the very long "Mounted on ..." text is now wrapped, but the text may not be left justified. Slowly adjust the dialog width and see how the text wrapping is updated to fit the size adjustment but the text is centred rather than left justified. This is because setting the halign property to Gtk::ALIGN_START does not guarantee left alignment of text for wrapped or ellipsized Gtk::Labels. Use the xalign property instead. To set the xalign property there is a method in the GtkMisc (Gtk::Misc) base class: gtk_misc_set_alignment (Gtk::Misc::set_alignment) However, GtkMisc (Gtk::Misc) was deprecated in Gtk 3.14 (Gtkmm 3.14) and in Gtk 3.16 (gtkmm 3.16) set_alignment() was replaced with the introduction of two new methods: gtk_label_set_xalign (Gtk::Label::set_xalign) gtk_label_set_yalign (Gtk::Label::set_yalign) Add a check for Gtkmm method Gtk::Label::set_xalign() in configure.ac and use it when available. References: [1] Gtk3 Reference Documentation - gtk_misc_set_alignment() https://developer.gnome.org/gtk3/stable/GtkMisc.html#gtk-misc-set-alignment "gtk_misc_set_alignment has been deprecated since version 3.14 and should not be used in newly-written code. Use GtkWidget's alignment ("halign" and "valign") and margin properties or GtkLabel's "xalign" and "yalign" properties." [2] Gtkmm 3.16 Gtk::Misc Class Reference, set_alignment() method https://developer.gnome.org/gtkmm/3.16/classGtk_1_1Misc.html#a52b2675874cf46a3097938756b9fe9e8 [3] GNOME BugZilla - EmptyBoxes: instructions_label's alignment is off https://bugzilla.gnome.org/show_bug.cgi?id=735841 [4] Gtk commit from 2014-09-16: GtkLabel: add x/yalign properties https://gitlab.gnome.org/GNOME/gtk/commit/d39424fc [5] Gtk3 Reference Documentation - gtk_label_set_xalign() https://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-xalign [6] Gtkmm 3.16 Gtk::Label Class Reference, set_xalign() method https://developer.gnome.org/gtkmm/3.16/classGtk_1_1Label.html#acee7d4e87d7cc14080a7b8ded5f84e5e Closes !40 - Limit wrapping labels 2019-05-01 Luca Bacci Set a default max_width_chars for wrapping Gtk::Labels (!40) Opening the Partition Information dialog for a file system mounted on a very long mount point, or on openSUSE which mounts the OS from 10 btrfs subvolumes from the same partition, will cause the dialog to be very wide as the "Mounted on ..." text is not wrapped. Back in Gtk2, when width_chars / max_width_chars were not set, wrapping labels had a default width beyond which text wrapped onto a new line [1]. For Gtk3 this default width was first reworked a bit [2], and then was removed for the very early Gtk3 3.0.10 release [3]. It is recommended that applications explicitly set default values, otherwise wrapping labels never wrap when requesting their natural allocation. References: [1] Gtk 2.24.32 source code - gtk/gtklabel.c:2975 https://gitlab.gnome.org/GNOME/gtk/blob/2.24.32/gtk/gtklabel.c#L2975 "This long string gives a good enough length for any line to have." [2] Gtk commit from 2010-04-21: https://gitlab.gnome.org/GNOME/gtk/commit/680d7762baabb71aa77aeec793e3c70a2013d3b8 Make sure not to base the minimum size on "max-width-chars", only the natural size. "This string is just about long enough." [3] Gtk commit from 2011-04-17: https://gitlab.gnome.org/GNOME/gtk/commit/c8ce1106c11361f8b47dd4e9a08db571c7d66d82 label: Don't try to guess a label's size People should use window default sizes or label width-chars/max-width-chars to find the ideal layout for a label instead of relying on magic. Closes !40 - Limit wrapping labels 2019-05-01 Luca Bacci Request natural width in Gtk::ScrolledWindows for Gtk >= 3.22 (!39) Before Gtk 3.22 GtkScrolledWindow propagated natural size to its Children and so on to descendants. In Gtk 3.22 this was changed to always request the minimum size. This was done because it is believed to be a safer default (gives a better behaviour) in case of dynamic content inside the scrolled window, that is, content that may change allocated size. [1][2][3] When the scrolled window content is not dynamic the natural size is preferable because it gives a better looking layout and without any downside. In the case of GParted content which is not dynamic, so request the scrolled windows to allocate children at natural sizes for Gtk >= 3.22. The benefits of natural size allocation are evident in presence of wrapping labels (for example inside the "Partition Info" dialog), that with the minimum size request likely end up taking a very small width. References: [1] Gtk commit from 2016-08-31: GtkScrolledWindow: Make propagation of natural child sizes optional https://gitlab.gnome.org/GNOME/gtk/commit/0984d1622d022bf67207f985f7842b6299818e20 "Making propagation of child natural sizes mandatory (or default, even) was evidently a mistake as this causes dynamic content in a scrolled window to resize it's parent when the scrolled window is competing for space with an adjacent widget." [2] Gtk 3.22 Reference Documentation - gtk_scrolled_window_set_propagate_natural_width https://developer.gnome.org/gtk3/3.22/GtkScrolledWindow.html#gtk-scrolled-window-set-propagate-natural-width [3] Gtkmm 3.24 Gtk::ScrolledWindow Class Reference, set_propagate_natural_width() method https://developer.gnome.org/gtkmm/3.24/classGtk_1_1ScrolledWindow.html#a2d4cb945688ecb8739efd70b18742779 [4] Gtkmm 3.21.6 NEWS https://gitlab.gnome.org/GNOME/gtkmm/blob/3.21.6/NEWS "ScrolledWindow: Added get/set_propagate_natural_height/width() and the properties." Closes !39 - Always request natural size inside Gtk::ScrolledWindow 2019-05-10 Rafael Fontenelle Update Brazilian Portuguese translation 2019-05-01 Yuras Shumovich Update Belarusian translation 2019-04-30 Seong-ho Cho Update Korean translation 2018-05-09 Mike Fleetwood Replace deprecated get_vbox() with get_content_area() (!25) get_vbox() was deprecated in gtkmm 3.1.6 [1][2]. Switch to the get_content_area() replacement. Note that GParted already requires gtkmm >= 3.4 as set in configure.ac. [1] Gtkmm 3.1.6 NEWS https://gitlab.gnome.org/GNOME/gtkmm/blob/3.1.6/NEWS "Dialog: Deprecate get_vbox(), replacing with get_content_area(), to match the C function name." [2] Gtkmm commit from 2011-06-13: Dialog: Deprecate get_vbox(), replacing with get_content_area(). https://git.gnome.org/browse/gtkmm/commit/?id=5ccc289fa8e9b046c07f5ea234f5ced8c6356fc1 Closes !25 - Modern Gtk3 - part 1 2019-03-13 Luca Bacci Use Gtk::Grid for Dialog_Partition_Info (!25) Gtk::Table was deprecated in Gtk 3.4.0. Replace with Gtk::Grid. This commit makes the change for Dialog_Partition_Info. Closes !25 - Modern Gtk3 - part 1 2019-03-07 Luca Bacci Use Gtk::Grid for Win_GParted pt2 (!25) Gtk::Table was deprecated in Gtk 3.4.0. Replace with Gtk::Grid. This commit makes the change for Win_GParted / pt2. Closes !25 - Modern Gtk3 - part 1 2019-03-06 Luca Bacci Use Gtk::Grid for Win_GParted pt1 (!25) Gtk::Table was deprecated in Gtk 3.4.0. Replace with Gtk::Grid. This commit makes the change for Win_GParted / pt1. Closes !25 - Modern Gtk3 - part 1 2019-03-06 Luca Bacci Use Gtk::Grid for Dialog_Base_Partition (!25) Gtk::Table was deprecated in Gtk 3.4.0. Replace with Gtk::Grid. This commit makes the change for Dialog_Base_Partition. Closes !25 - Modern Gtk3 - part 1 2019-03-06 Luca Bacci Use Gtk::Grid for Dialog_Partition_New (!25) Gtk::Table was deprecated in Gtk 3.4.0 [1]. Replace with Gtk::Grid. Note that the meaning of the attachment parameters changed between Gtk::Table::attach() [2] from left, right, top, bottom and Gtk::Grid::attach() [3] to left, top, width, height. This commit makes the change for Dialog_Base_Partition. [1] Gtkmm 3.4 NEWS file (actually first included in gtkmm 3.3.2 unstable) https://gitlab.gnome.org/GNOME/gtkmm/blob/3.4.0/NEWS#L162 * Deprecate Gtk::Table in favour of Gtk::Grid. [2] Gtkmm 3.4 Gtk::Table Class Reference, attach() method https://developer.gnome.org/gtkmm/3.4/classGtk_1_1Table.html#a28b6926e68337a51ba29f2b4dd69f087 Deprecated: 3.4: Use Gtk::Grid::attach() with Gtk:Grid. Note that the attach argument differ between those two function. [3] Gtkmm 3.4 Gtk::Grid Class Reference, attach() method https://developer.gnome.org/gtkmm/3.4/classGtk_1_1Grid.html#a9c425e95660daff60a77fc0cafc18115 Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Separator (!25) Gtk::HSeparator was deprecated in Gtkmm 3.2. Replace with plain Gtk::Separator. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Paned (!25) Gtk::HPaned and Gtk::VPaned were deprecated in Gtkmm 3.2. Replace with plain Gtk::Paned. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_Progress (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_Progress.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_Rescue_Data (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_Rescue_Data.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for DialogPasswordEntry (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for DialogPasswordEntry.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_Partition_Name (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_Partition_Name.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_FileSystem_Label (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_FileSystem_Label.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for DialogFeatures (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for DialogFeatures.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_DiskLabel (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_DiskLabel.cc. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_Partition_Info (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_Partition_Info.{h,cc}. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Dialog_Base_Partition (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for Dialog_Base_Partition.{h,cc}. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for HBoxOperations (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2. Replace with plain Gtk::Box. This commit makes the change for HBoxOperations.{h,cc}. Closes !25 - Modern Gtk3 - part 1 2019-02-27 Luca Bacci Use Gtk::Box for Win_GParted (!25) Gtk::HBox and Gtk::VBox were deprecated in Gtkmm 3.2 [1]. Replace with plain Gtk::Box. This commit makes the change for Win_GParted.{h,cc}. [1] Gtkmm 3.2.0 NEWS file (actually first included in gtkmm 3.1.6 unstable) https://gitlab.gnome.org/GNOME/gtkmm/blob/3.2.0/NEWS#L91 Gtk: * All H* or V* specialized classes have been deprecated, to match the deprecations in the GTK+ C API. You should now set the orientation instead. This includes HBox, VBox, HButtonBox, VButtonBox, HPaned, VPaned, HScale, VScale, HSeparator, VSeparator, HScrollbar and VScrollbar. Closes !25 - Modern Gtk3 - part 1 2019-02-20 Luca Bacci Use Gdk::RGBA (!25) The Gdk::RGBA data type was introduced to replace Gdk::Color in Gtkmm 3.0 [1], with Gdk::Color being deprecated in Gtkmm 3.10 [2]. With this commit we make the change to Gdk::RGBA data type which is the modern replacement to Gdk::Color. Gdk::RGBA can be used almost as a drop in replacement because it keeps most of the Gdk::Color interface. Also, this commit removes the C Gtk call introduced during the port-to-gtk3 patchset by commit: 53793527668a344fe54ceb61a1afdc39c24c5c45 repare-for-gtk3: Prepare for removal of Gtk::Widget::modify_fg() (#7) [1] Gtkmm 3.0.1 NEWS file https://gitlab.gnome.org/GNOME/gtkmm/blob/3.0.1/NEWS#L48 * RGBA replaces Color, though Color still exists because it is used by TextView. We hope to deprecated Color completely in gtkmm 3.2. [2] Gtkmm 3.10.0 NEWS file https://gitlab.gnome.org/GNOME/gtkmm/blob/3.10.0/NEWS#L127 Gdk: * Deprecate Color. Closes !25 - Modern Gtk3 - part 1 2019-04-20 Mike Fleetwood Update includes in DialogFeatures.h and .cc Mostly add, but also remove, #includes so both DialogFeatures.h and .cc include exactly the header files each needs to get the definitions they use. Header file #include guards are there to specifically enable this. 2019-04-19 Mike Fleetwood Rename method to DialogFeatures::load_one_filesystem() To better reflect that it is loading the supported actions for one file system into the treeview, just like it's parent load_filesystems() is initiating the loading for all the file systems. 2019-04-19 Mike Fleetwood Fix available Partition menu options not being updated on rescan (!38) Select a partition and look at the available actions in the Partition menu. Then add or remove some commands which that particular file system uses and rescan to detect those changes. Open the Partition menu again. It doesn't reflect the changes of supported actions seen in the File System Support dialog. Select a different partition and then select the original partition again. Now the available actions in the Partition menu reflect the changes of supported actions. Have been testing by adding and removing /sbin/e2label to add and remove EXT2/3/4 file system labelling support just because that feature has existed for a very long time and EXT2/3/4 are displayed near the top of the File System Support dialog. Tested this minor issue existed as far back as GParted 0.3.7. Fix by simply also refreshing the valid operations to update the Partition menu after updating the found file system specific commands. Closes !38 - Fixes for minor issues with File System Support rescanning 2019-04-17 Mike Fleetwood Fix File System Support dialog not showing changes after rescan (!38) Open the File System Support dialog, either add or remove some file system specific commands used by GParted and press the [Rescan For Supported Actions] button. The supported actions don't change. However after just closing and reopening the dialog, the supported actions do reflect the added or removed file system specific commands. Bisected to this commit: 4d6d46466478f656ce2ebb3c6b5a88cf0657667f Display "other" in the File System Support dialog (!13) The problem is that commit made a subset copy of the GParted_Core::FILESYSTEMS vector, obtained from get_filesystems(), so when the rescan ran and the FILESYSTEMS vector was updated with new supported actions, the dialog still displayed the original subset copy, so didn't reflect the changed supported actions. Fix by passing a reference to the GParted_Core::FILESYSTEMS vector, obtained from get_filesystems(), and perform the necessary filtering inside the dialog, like before the above faulty commit. Additionally finding and adding "other" file system to the end of the list. Closes !38 - Fixes for minor issues with File System Support rescanning 2019-04-15 Mike Fleetwood Stop checking for 'ntfslabel --new-serial' support The oldest supported distributions have these versions of ntfs-3g / ntfsprogs. Distro EOL ntfs-3g / ntfsprogs - Debian 8 2020-Jun 2014.2.16AR.2 - RHEL / CentOS 7 2024-Jun 2017.3.23 - Ubuntu 14.04 LTS 2019-Apr 2013.1.13AR.1 The oldest version of ntfs-3g / ntfsprogs on Ubuntu 14.04 LTS includes support for the --new-serial option. $ ntfslabel -V ntfslabel v2013.1.13AR.1 (libntfs-3g) - Display, or set, the label for an NTFS Volume. $ ntfslabel --help | grep -- --new-serial --new-serial Set a new serial number Therefore it is no longer necessary to check for this option as it is always available. The worst case scenario is that some how an old version of ntfslabel is used which doesn't support this option. In such a case GParted goes from not supporting changing the UUID to claiming support, but presumably it would fail with an error reporting unknown option when applied. Arguably better from an end user support point of view. 2019-04-14 Mike Fleetwood Consolidate common if have ntfsresize command conditions 2019-04-14 Mike Fleetwood Switch to faster ntfsinfo to read NTFS usage (#47) A user reported GParted was slow to refresh and timing ntfsresize to query his file systems found that it was taking 4.7 seconds and 9.2 seconds for sizes 31.7 GiB and 49 GiB NTFS file systems respectively. Almost 14 seconds just to read the usage. Created a 4 GiB NTFS and filled it with as many 4 KiB files as possible, just over 800,000 files. # df -k /mnt/2 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb2 4194300 4193860 440 100% /mnt/2 # df -i /mnt/2 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb2 819640 808591 11049 99% /mnt/2 Testing perform of ntfsresize: # time ntfsresize --info --force --no-progress-bar /dev/sdb2 | \ > egrep 'Current volume size|resize at|Cluster size' Cluster size : 4096 bytes Current volume size: 4294963712 bytes (4295 MB) You might resize at 4294516736 bytes (freeing 450560 bytes). real 0m5.231s user 0m2.072s sys 0m3.014s Computation of figures: Clusters per volume = 4294963712 / 4096 = 1048575.125 Free clusters = (4294963712 - 4294516736) / 4096 = 109.125 Testing performance of ntfscluster, as used before this commit [1] from GParted 0.3 in 2006: # time ntfscluster --force /dev/sdb2 | \ > egrep 'bytes per cluster|bytes per volume|clusters per volume|clusters of free space' ... bytes per cluster : 4096 bytes per volume : 4294963200 clusters per volume : 131071 clusters of free space : 110 real 0m4.243s user 0m1.629s sys 0m2.587s Note that the clusters per volume figure reported by ntfscluster is wrong. 4294963200 / 4096 = 1048575, not 131071. Testing performance using ntfsinfo: # time ntfsinfo --mft /dev/sdb2 | \ egrep 'Cluster Size|Volume Size in Clusters|Free Clusters' Cluster Size: 4096 Volume Size in Clusters: 1048575 Free Clusters: 110 (0.0%) real 0m0.022s user 0m0.012s sys 0m0.018s Repeating the above tests while also using 'btrace /dev/sdb2' and Ctrl-C around each test via a separate terminal, reports these numbers of I/Os being performed: Command Read requests Read bytes - ntfsresize 2,695 1116 MiB - ntfscluster 2,685 1116 MiB - ntfsinfo 13 2208 KiB No wonder that ntfsresize and ntfscluster take a long time, they read just over 1 GiB of data from the 4 GiB file system, where as ntfsinfo only reads just over 2 MiB. Switch to using ntfsinfo to report file system usage. [1] 9d956594d6acf0d983ae9105df2f3772194a5404 replaced ntfscluster with ntfsresize (see #350789) Closes #47 - GParted is slow refreshing NTFS file systems 2019-04-17 Daniel Mustieles Updated Spanish translation 2019-04-17 Daniel Mustieles Update Spanish translation 2019-04-13 Mike Fleetwood Prefer enum to string comparison in set_partition_type() 2019-04-13 Mike Fleetwood Stop trying unneeded alternative libparted linux-swap names With that same commit in parted 1.9 [1], libparted only recognised these linux-swap names via deprecated aliases: linux-swap(old) linux-swap(new) but does accept this name as a current alias: linux-swap for: linux-swap(v1) Demonstration: # parted -v parted (GNU parted) 2.1 ... # parted /dev/sdc mkfs yes 1 "linux-swap(new)" unit s print ... [0] filesys.c:148 (ped_file_system_type_get(): File system alias linux-swap(new) is deprecated ... Number Start End Size Type File system Flags 1 2048s 2099199s 2097152s primary linux-swap(v1) # parted /dev/sdc mkfs yes 1 "linux-swap" unit s print ... Number Start End Size Type File system Flags 1 2048s 2099199s 2097152s primary linux-swap(v1) Again as GParted now requires libparted 2.2 or later: 1) Stop using alternative "linux-swap(new)" name as that is deprecated by libparted. 2) Also stop using alternative "linux-swap(v1)" name as that code is never used because libparted recognised the GParted "linux-swap" name as a current alias. [1] http://git.savannah.gnu.org/cgit/parted.git/commit/?id=cfafa4394998a11f871a0f8d172b13314f9062c2 Rationalise linux-swap fs names, and add a "linux-swap" alias 2019-04-13 Mike Fleetwood Stop recognising retired libparted linux-swap names With this commit in parted 1.8.3 [1], libparted changed from reporting the name of Linux swap as: linux-swap to reporting either: linux-swap(old) linux-swap(new) Later with this commit in parted 1.9 [2], libparted stopped reporting those names and reported these instead: linux-swap(v0) linux-swap(v1) Demonstration: # mkswap /dev/sdc1 Setting up swapspace version 1, size = 1048572 KiB no label, UUID=a2010834-003d-4bf2-9e94-58383fe20a26 # blkid /dev/sdc1 /dev/sdc1: UUID="a2010834-003d-4bf2-9e94-58383fe20a26" TYPE="swap" # parted -v parted (GNU parted) 2.1 ... # parted /dev/sdc unit s print ... Number Start End Size Type File system Flags 1 2048s 2099199s 2097152s primary linux-swap(v1) As GParted now requires libparted 2.2 or later [3], remove recognition for those no longer libparted reported linux-swap names. Note that the "swap" name is reported by blkid. [1] http://git.savannah.gnu.org/cgit/parted.git/commit/?id=98a53fd115ca012edf226525b8d4be628454f99e Enable support for swsusp partitions, and the ability to differentiate between old and new versions of linux-swap partitions. Changed the swap_init signature and removed extra ped_geometry_read from _swap*_open. [2] http://git.savannah.gnu.org/cgit/parted.git/commit/?id=cfafa4394998a11f871a0f8d172b13314f9062c2 Rationalise linux-swap fs names, and add a "linux-swap" alias [3] 8df975c7d1b5d69897f286bfc5574c51cf58c9d5 Increase minimum required libparted to 2.2 (!22) 2019-04-13 Mike Fleetwood Set partition type when formatting to cleared (!36) Formatting a partition to cleared over the top of LVM2 PV leaves the "lvm" flag set on the partition; where as formatting with an actual file system over the top of an LVM2 PV clears the "lvm" flag. This is true for both MSDOS and GPT partitioned drives. Fix by setting the partition type when formatting to cleared too. Closes !36 - Set partition type when clearing partition contents 2019-04-15 Stas Solovey Update Russian translation 2019-04-14 Piotr Drąg Update Polish translation 2019-04-04 Mike Fleetwood Remove unnecessary #include from GParted_Core.cc 2019-04-10 Mike Fleetwood Rename Dialog_Progress member variable to m_curr_op Having a member variable named 't' which is used to share state in a Dialog_Progress object between on_signal_show() and on_cancel() methods is horrible. Rename to something more meaningful. Also initialise m_curr_op in the constructor's initialisation list, rather than later when first used in on_signal_show(). Not strictly required, but avoids this POD (Plain Old Data) member variable being undefined in the Dialog_Progress object between construction and when on_signal_show() previously assigned to it for the first time and started using it. * C++ FAQ / Should my constructors use "initialization lists" or "assignment"? https://isocpp.org/wiki/faq/ctors#init-lists 2019-04-10 Mike Fleetwood Rename for loop counter variables to normative 'i' in Dialog_Progress Several for loops created counter variable t, hiding member variable of the same name. Rename those loop counter variables to the normative name 'i'. * Why do most of us use 'i' as a loop counter variable? https://softwareengineering.stackexchange.com/questions/86904/why-do-most-of-us-use-i-as-a-loop-counter-variable 2019-04-07 Mike Fleetwood Use CSS to turn off table borders once in saved details HTML 2019-04-07 Mike Fleetwood Rename method to Dialog_Progress::write_operation_details() And update comment about replacing '\n' to reflect what the code actually does. 2019-04-05 Mike Fleetwood Additionally write partition information to saved details (#639176) Bug 639176 - Save partition layout to gparted_details.htm 2019-04-05 Mike Fleetwood Write starting device overview information to saved details (#639176) Writes the starting device overview information of all known devices to the top of the saved details HTML. This is so that hopefully we don't need to additionally ask users for their disk layouts via 'fdisk -l', 'parted print' and 'lsblk' when the saved details file is provided. Also moves the equals separators "==================" from below to above each operation so the each section is separated. Bug 639176 - Save partition layout to gparted_details.htm 2019-03-27 Luca Bacci Ensure icon sizes (#39) Some icon themes only provide large icons for stock items. This can cause problems like overly large icons appearing in the GParted UI. Found on Kubuntu 16.04 LTS with default breeze icon theme. Be compatible with these icon themes by forcing scaling of stock icons to the requested size. Icons are used either by Gtk::Image widgets, or Gtk::CellRendererPixbuf objects for comboboxes/treeviews. For Gtk::Image widgets we add Utils::mk_image() that constructs Gtk::Image widgets and then sets the pixel-size property. For Gtk::CellRendererPixbuf we add Utils::mk_pixbuf() that first loads a Gdk::Pixbuf and then scales if needed. Closes #39 - After GTK3 port icons are too big on KDE 2019-03-31 Mike Fleetwood Update distro specific package installation instructions - Back in Fedora 22 the distribution switched from using yum to dnf for package installation, while CentOS / RHEL continues to use yum. Separate out package instructions. - Update package dependencies for what is required on current versions of the documented distributions. 2019-03-31 Mike Fleetwood Also write "Root privileges are required ..." message to stderr (!34) To further help in diagnosing root authorisation issues by reporting the error message to the terminal too. Also set a failure exit status when terminating with this error. Example: $ ./gpartedbin GParted 0.33.0-git configuration --enable-online-resize libparted 3.2 Root privileges are required for running GParted $ echo $? 1 Closes !34 - Display more version and configuration information 2019-03-31 Mike Fleetwood Print new info before "Root privileges are required ..." dialog (!34) So that the new version and configuration information is displayed even if the gpartedbin executable is run as a non-root user. To help with diagnosing root authorisation issues with the gparted shell wrapper script. Closes !34 - Display more version and configuration information 2019-03-30 Mike Fleetwood Remove now unused Dialog_Progress::signal_get_libparted_version (!34) ... and related GParted_Core::get_libparted_version() method. Closes !34 - Display more version and configuration information 2019-03-30 Mike Fleetwood Report the same information into saved operation details (!34) For consistency save the 3 same lines of information into the saved operation details. None of the new 3 lines are subject to translation. As this information is really for our benefit when supporting users leaving them as English is OK. Also "GParted" and "Libparted", as previously used, are proper nouns so they were never changed as part of any language translation. See with: egrep -r '"(GParted|Libparted)"' po/ Closes !34 - Display more version and configuration information 2019-03-30 Mike Fleetwood Display more version and configuration info to stdout when starting (!34) So that we might get more information from users when helping them. Starting GParted from the command line now looks like this: # ./gpartedbin GParted 0.33.0-git configuration --enable-online-resize libparted 3.2 Closes !34 - Display more version and configuration information 2019-03-09 Mike Fleetwood Rename local variable to meaningful benchmark_copysize 2019-03-29 Mike Fleetwood Stop trying to access device '/dev/mapper/No RAID disks' (#786031) Running GParted on AltLinux with dmraid installed but with no configured RAID arrays produces this error: # gparted ... Could not stat device /dev/mapper/No RAID disks - No such file or directory. Most distributions use dmraid 1.0.0.rc16 which reports no raid disks like this: # dmraid -sa -c no raid disks # echo $? 1 However AltLinux had the slightly older version, dmraid 1.0.0.rc14, which reported no raid disks like this: # dmraid -sa -c No RAID disks # echo $? 0 So because dmraid 1.0.0.rc14 reported success, exit status 0, and the "No RAID disks" message was not in lower case, that text was considered a disk device in a DMRaid array. Fix by checking for "no raid disks" in any case. Bug 786031 - Could not stat device /dev/mapper/No RAID disks - No such file or directory 2019-03-28 Mike Fleetwood Pass constant parameter by reference to load_operations() (#788814) It is common C++ practice to pass a constant object by reference to avoid constructing a duplicate object for pass by value [1]. [1] How to pass objects to functions in C++? https://stackoverflow.com/questions/2139224/how-to-pass-objects-to-functions-in-c/2139254#2139254 Bug 788814 - gparted-0.30.0/include/HBoxOperations.h:37]: performance problem 2019-03-26 Luca Bacci Always show menu images (!32) There is a GtkSetting [1] that controls whether images in menus are shown or not. On some distributions / desktops it is enabled by default and on others it is disabled by default. To force show images in menus set the 'always-show-image' property to true in Gtk::ImageMenuItems [2]. References: [1] Gtk3 Reference Documentation - Settings/gtk-menu-images https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-menu-images [2] Gtk3 Reference Documentation - GtkImageMenuItem https://developer.gnome.org/gtk3/stable/GtkImageMenuItem.html#gtk-image-menu-item-set-always-show-image Closes !32 - Always show menu images 2019-03-25 Mike Fleetwood Drop compose subdir (#46) It's no longer used so drop it. Closes #46 - Drop compose subdir 2019-03-25 Mike Fleetwood Replace String::ucompose() with Glibmm equivalent (#46) Glibmm has implemented a ustring::compose() set of methods [1] since Glibmm 2.16, circa 2008. So replace String::ucompose(). Note that GParted already requires glibmm >= 2.32 as set in configure.ac. This commit just replaces all the method calls. Edit created by: sed -i 's|String::ucompose *|Glib::ustring::compose|' src/*.cc [1] Glibmm Reference Manual, Glib::ustring Class, compose() method https://developer.gnome.org/glibmm/2.32/classGlib_1_1ustring.html#a64ff7ac3d9e9899c2910f1d831f8d500 Closes #46 - Drop compose subdir 2019-03-23 Mike Fleetwood Recognise contribution by Antoine Viallon 2019-03-17 Mike Fleetwood Raise the maximum F2FS label size to 127 characters (!29) Fix to make mkfs.f2fs properly handle labels longer than 16 characters was included in f2fs-tools 1.2.0 [1]. The oldest supported distributions now include this release: Distro EOL f2fs-tools - Debian 8 2020-Jun 1.4.0 - RHEL / CentOS 7 2024-Jun 1.4.1 - SLES 12 2027-Oct Unknown - Ubuntu 14.04 LTS 2019-Apr 1.2.0 Note that on Ubuntu 14.04 LTS blkid from util-linux 2.20.1 is too old to recognise F2FS file systems, as 2.23 is required for F2FS support [2]. mkfs.f2fs claims the maximum label length is less than 512 characters, but actually accepts 512 characters. # label=`head -c 1024 < /dev/zero | tr '\0' 'A'` # mkfs.f2fs -l `echo -n "$label" | cut -c1-513` /dev/sdb10 F2FS-tools: mkfs.f2fs Ver: 1.4.0 (2014-09-18) Error: Volume Label should be less than 512 characters Usage: mkfs.f2fs [options] device [sectors] [options]: -a heap-based allocation [default:1] -d debug level [default:0] -e [extension list] e.g. "mp3,gif,mov" -l label -o overprovision ratio [default:5] -s # of segments per section [default:1] -z # of sections per zone [default:1] -t 0: nodiscard, 1: discard [default:1] sectors: number of sectors. [default: determined by device size] # echo $? 1 # mkfs.f2fs -l `echo -n "$label" | cut -c1-512` /dev/sdb10 F2FS-tools: mkfs.f2fs Ver: 1.4.0 (2014-09-18) Info: Label = AAAAAAAAAAAA...[trimmed from 512 "A"s]...AAAAAAAAAAAA Info: sector size = 512 Info: total sectors = 1048576 (in 512bytes) Info: zone aligned segment0 blkaddr: 256 Info: Discarding device Info: This device doesn't support TRIM Info: format successful # echo $? 0 # blkid -V blkid from util-linux 2.25.2 (libblkid 2.25.0, 24-Oct-2014) # blkid /dev/sdb /dev/sdb10: LABEL="AAAAAAAAAAAA...[only 127 "A"s]...AAAAAAAAAAAA" UUID="f47f3fdc-dd91-4616-bb6d-0d643a884265" TYPE="f2fs" PARTUUID="3bb4bef8-9494-4e82-8dda-5d8edd9c60d9" As blkid only reports the first 127 characters and is the only command used for reading the label of an F2FS file system, use this as the new increased limit. [1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?id=9799d6364dc93e1fd259d812d4a50ed984a6456b mkfs: handle labels longer than 16 characters [2] https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.23/v2.23-ReleaseNotes "add Flash-Friendly File System (f2fs) support [Alejandro Martinez Ruiz]" Closes !29 - Enhance F2FS support 2019-03-19 Mike Fleetwood Drop fsck.f2fs -y option not available before f2fs-tools 1.10.0 (!29) On CentOS 7 with f2fs-tools 1.4.1, checking an F2FS file system fails like this: # fsck.f2fs -f -y -a /dev/sdb3 Info: Force to fix corruption fsck.f2fs: invalid option -- 'y' Error: Unknown option ? Usage: fsck.f2fs [options] device [options]: -a check/fix potential corruption, reported by f2fs -d debug level default:0] -f check/fix entire partition -t show directory tree [-d -1] # echo $? 1 Turns out that the '-y' option was not available until f2fs-tools 1.10.0 and is identical to the existing '-f' option anyway [1], which GParted already uses. Just remove the '-y' option passed to fsck.f2fs. [1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?id=55ee9e7202f84168f868d863da8ed1c4995a0e6d fsck.f2fs: add -y for generic fsck Closes !29 - Enhance F2FS support 2019-03-19 Mike Fleetwood Handle missing FS size information before f2fs-tools 1.5.0 (!29) Before this commit [1] first included in f2fs-tools 1.5.0, dump.f2fs didn't report the total space used by the file system. This causes F2FS file system usage not be reported on older distributions, including RHEL/CentOS 7 and Debian 8. On CentOS 7: # rpm -q f2fs-tools f2fs-tools-1.4.1-2.el7.nux.x86_64 # dump.f2fs -d 1 /dev/sdb3 | egrep 'sector size =|total.*sectors =' Info: sector size = 512 Info: total sectors = 2097152 (in 512 bytes) On Fedora 28: # rpm -q f2fs-tools f2f2-tools-1.10.0-1.fc28.x86_64 # dump.f2fs -d 1 /dev/sdb2 | egrep -a 'sector size =|total.*sectors =' Info: sector size = 512 Info: total sectors = 3145728 (1536 MB) Info: total FS sectors = 2621440 (1280 MB) "total sectors" reports the size of the partition. "total FS sectors" reports the size of the file system. Cope with the file system size being missing. Pass -1 as the file system size to partition.set_sector_usage() in this case. Note that this means GParted won't be able to detect and report unallocated space within the partition when using f2fs-tools < 1.5.0. [1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?id=fea6162a6db9af527648262d9fbb0335a0cc5460 fsck.f2fs: show total sectors consumed by filesystem Closes !29 - Enhance F2FS support 2019-03-19 Mike Fleetwood Make F2FS usage parsing handle NULs in dump.f2fs output (!29) On Fedora 28 with f2fs-tools 1.10.0, dump.f2fs is producing NUL characters in it's output and this completely breaks the parsing code in f2fs::set_used_sectors(). Glib::Regex, as used by Utils::regexp_label(), just doesn't match any text after the first NUL character from the output. # dump.f2fs -d 1 /dev/sdb1 Info: Debug level = 1 Info: [/dev/sdb1] Disk Model: VBOX HARDDISK 1.0 ^@^@^@^@^@^@^@^... Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 2097152 (1024 MB) ... Grep thinks the output is binary too: # dump.f2fs -d 1 /dev/sdb1 | \ > egrep 'valid_block_count|user_block_count|log_blocksize|sector size =|total FS sectors =' Binary file (standard input) matches # dump.f2fs -d 1 /dev/sdb1 | \ > egrep --text 'valid_block_count|user_block_count|log_blocksize|sector size =|total FS sectors =' Info: sector size = 512 log_blocksize [0x c : 12] Info: total FS sectors = 2097152 (1024 MB) user_block_count [0x 36400 : 222208] valid_block_count [0x 2 : 2] Re-write set_used_sectors() using string find() and sscanf() to be similar to how a number of the other set_used_sectors() are written for other file systems. Closes !29 - Enhance F2FS support 2019-03-15 Antoine Viallon Enhance F2FS support (!29) - Adds reading of file system usage - Adds resize (grow) support - Adds verify support Closes !29 - Enhance F2FS support 2019-02-18 Mike Fleetwood Go back to symbolic label widget alignment constants Now that GParted requires Gtk3 there is no need to use floating point numbers for compatibility with Gtk <= 2.22. Replace with symbolic alignment constants. Relevant commit history: * 6efa6234012b5fa112af4db08e0b89238d53981a Add optional yalign argument to Utils::mk_label() method * be2689ad25c104e3cb97e7d5d1f7627dbb137b19 Stop using deprecated widget alignment enumerators (#652044) 2019-03-23 Mike Fleetwood Pass message parameters by reference to 2 Partition methods (#788813) Note that this almost certainly has no performance benefit what so ever because the methods are implicitly defined as inline [1][2] and the compiler will have simply inlined the method bodies thus avoiding having to construct copies of the passed parameters. Do this anyway as constant objects are typically passed by reference [3]. Also C++'s std::vector::push_back() [4] takes a const reference parameter so update the kind of equivalent push_back_message() to take a const reference parameter too. [1] C++ reference / inline specifier https://en.cppreference.com/w/cpp/language/inline A function defined entirely inside a class/struct/union definition, whether it's a member function or a non-member friend function, is implicitly an inline function. [2] When should I write the keyword 'inline' for a function/method? https://stackoverflow.com/questions/1759300/when-should-i-write-the-keyword-inline-for-a-function-method/1759575#1759575 [3] How to pass objects to functions in C++? https://stackoverflow.com/questions/2139224/how-to-pass-objects-to-functions-in-c/2139254#2139254 [4] C++ reference / std::vector::push https://en.cppreference.com/w/cpp/container/vector/push_back void push_back(const T& value); Bug 788813 - gparted-0.30.0/include/Partition.h:137]: performance problem 2019-03-12 Mike Fleetwood Stop checking for 'btrfs filesystem label' support (!26) btrfs-progs 3.12 includes 'btrfs filesystem label /dev/PTN NEWLABEL' functionality so stop checking for this before enabling setting the label. $ btrfs version Btrfs v3.12 $ btrfs filesystem label --help usage: btrfs filesystem label [|] [] Get or change the label of a filesystem With one argument, get the label of filesystem on . If is passed, set the filesystem label on . $ echo $? 0 Worst case scenario is that some how an old version of the btrfs command is used which doesn't support the labelling functionality. Then this commit would change GParted from disallowing labelling of a btrfs, to allowing it, but presumably it would fail with an error from the btrfs command reporting so. Arguably better from a support point of view. Closes !26 - Remove support for btrfs-progs < 3.12 2019-03-11 Mike Fleetwood Replace use of deprecated btrfsck (!26) In btrfs-progs 3.12, btrfsck is a hard link to the multi-tool btrfs executable. When run as 'btrfsck' it just implements 'btrfs check' [1][2][3][4]. In btrfs-progs 3.14.2 the btrfsck man page is re-added as a symlink to the btrfs-check man page and reports that btrfsck is deprecated [5]. Therefore replace use of 'btrfsck' with 'btrfs check'. [1] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=fac45410e9a783c187ae83d993d3bf3350d05149 Btrfs-progs: Rename btrfsck.c -> cmds-check.c [2] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=5956f752c66d5259bbb17a2dd47ee8c8cc0e5f4f Btrfs-progs: add btrfsck functionality to btrfs [3] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=d5d2046ae3b216af22a8a37c940f2412ba519b6e Btrfs-progs: add btrfsck name detection to btrfs [4] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=e31f6172aa1d6ec5d562f56086819a0f4bc8a914 btrfs-progs: build btrsfck to keep compatibility [5] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=fddeecb7d424d5bb1a93a19a5e537057a4a7f597 btrfs-progs: doc: link btrfsck to btrfs-check Closes !26 - Remove support for btrfs-progs < 3.12 2019-03-11 Mike Fleetwood Stop using removed btrfsctl (!26) That commit [1] also removed btrfsctl from btrfs-progs 3.12 so also stop using it as a fallback. [1] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=f243fcd1b2aa55ffadfbcc032c66dedbee56e79e Removing btrfsctl, btrfs-vol, btrfs-show Closes !26 - Remove support for btrfs-progs < 3.12 2019-03-11 Mike Fleetwood Finish removal of btrfs-show (!26) Remove use of btrfs-show from everywhere else in the btrfs module. Closes !26 - Remove support for btrfs-progs < 3.12 2019-03-11 Mike Fleetwood Stop using removed btrfs-show to read the label (!26) This commit [1] from btrfs-progs 3.12 removed the previously deprecated programs btrfsctl and btrfs-show. As btrfs-progs 3.12 is now the minimum requirement, remove support for those removed programs. This commit is just removing the use of btrfs-show as a fallback to read the label. Note that 'btrfs-show /dev/PTN' didn't distinguish between a label of "none" and no label. Hence the logic in btrfs::read_label() to do with matching the label "none", or matching the label with or without single quotes. Unfortunately as identified in this commit [2] 'btrfs filesystem show /dev/PTN' is subject to the same issue, but only when the file system is mounted and only for btrfs-progs 3.12. This was fixed by this commit [3] from btrfs-progs 3.14. [1] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=f243fcd1b2aa55ffadfbcc032c66dedbee56e79e Removing btrfsctl, btrfs-vol, btrfs-show [2] eca732fb0cefe35db76a7ac96145e2004e8eed08 Update parsing of btrfs filesystem show for the label (#733601) [3] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=a156b967ed9bd606afa8dc402451abcf07226c17 btrfs-progs: make filesystem show by label work Closes !26 - Remove support for btrfs-progs < 3.12 2019-03-11 Mike Fleetwood Remove old workaround for btrfs resizing on Linux < 3.2 (!26) PATCHSET OVERVIEW The oldest supported distributions have these versions of the Linux kernel and btrfs-progs: Distro EOL kernel btrfs-progs - RHEL / CentOS 7 2024-Jun 3.10.0 4.9.1 - Ubuntu 14.04 LTS 2019-Apr 4.4.0 3.12 - Debian 8 2020-Jun 3.16.0 3.17 - SLES 12 2027-Oct 3.12.28 3.16 Making the oldest supported packages be kernel 3.10 and btrfs-progs 3.12 allows the btrfs support code to be simplified by removing backward compatibility. THIS CHANGE Remove old workaround for ignoring the error when resizing a btrfs to the same size on Linux kernel < 3.2. Also now that only exit status 0 is considered successful from btrfs resize, the EXEC_CHECK_STATUS flag to execute_command() can be used, rather than having to separately call set_status() afterwards. Relevant commit history: * 11d044dba0c07a5c51843beec6ff38f0c55303d8 Don't ignore any errors resizing btrfs on Linux >= 3.2 (#669389) * a580abbc30e88cb1895af342d43dcbb98183a9d5 Use newer btrfs multi-tool control command first Closes !26 - Remove support for btrfs-progs < 3.12 2019-03-14 Mike Fleetwood Set title of Resize/Move dialog for an extended partition (#44) The title has never been set in this case, and defaulted to the name of the executable 'gpartedbin'. Fix this. Closes #44 - Title not set in Resize/Move dialog for extended partitions 2019-03-03 Trần Ngọc Quân Updated Vietnamese translation Signed-off-by: Trần Ngọc Quân 2019-02-28 Mike Fleetwood Initialise local POD 'launched' variable in show_help() 'launched' local POD (Plain Old Data) variable was left uninitialised, but was set in both the try and catch clauses. Best practice is to initialise when defined, so do that instead. Cosmetic change. 2019-02-28 Mike Fleetwood Rename Win_GParted method to show_help() It is not creating a dialog (a pop-up window managed by GParted code itself). It is launching independent yelp program to display the help, so remove the "_dialog" from the name to avoid any possible confusion. 2019-02-27 Mike Fleetwood Restore specific error message on failure to launch yelp Originally, if the yelp command was not installed, attempting to display help produced an error dialog with this message: Failed to execute child process "yelp" (No such file or directory) However since this commit during the Gtk 3 port [1] the error message became this less useful one: Operation not supported Two attempts are made to display the GParted Manual, first using gtk_show_uri() and second by executing the yelp command directly. Prior to the aforementioned commit [1] both methods returned the failure reason using the same 'error' variable. Hence reported the message "Failed to execute child process "yelp" ..." from the second attempt. However that commit had to re-code the second method as part of the Gtk 3 port and use a different error returning mechanism, thus the use of different variable 'e'. But the dialog was left reporting the message from the original 'error' variable, thus reporting "Operation not supported" message from the first attempt using gtk_show_uri(). Fix by again displaying the message from the second failure into the error dialog. Also make it very clear there are two error returning variables by naming them 'error1' and 'error2_msg'. [1] 2953778a4c0e61d8fe49c7a6d707add8a9eb0634 port-to-gtk3: Use Gdk::AppLaunchContext to launch yelp (#7) 2019-02-25 Mike Fleetwood Remove deprecated PKG_NAME from autogen.sh Use of PKG_NAME is deprecated in GNOME 3 and produced this warning: $ ./autogen.sh /usr/bin/gnome-autogen.sh /usr/bin/yelp-build ***Warning*** PKG_NAME is deprecated, you may remove it from autogen.sh ... Now that GParted is a GNOME 3 application with GNOME 3 yelp-tools managed documentation this is redundant and can be removed. Previous further analysis: GNOME Bugzilla, Bug 743318, comment 18 https://bugzilla.gnome.org/show_bug.cgi?id=743318#c18 " PKG_NAME is still used in GNOME 2.28's gnome-autogen.sh in error messages. (GNOME 3's gnome-autogen.sh queries it from configure.ac instead of requiring it to be set). " Also confirmed that it makes no difference by running ./autogen.sh with and without PKG_NAME being set. The produced GParted build trees were the same. Therefore the release and executable can't be affected. 2019-02-24 Mike Fleetwood Drop now unnecessary editing of xmllint command line in CI tests (!24) GNOME 3's yelp doesn't use scrollkeeper or the OMF catalog, so the constructed Makefile doesn't use xmllint to validate the scrollkeeper DTD file. Therefore remove attempted sed edit of that line which no longer exists in the Makefile. Note that help/Makefile.am's @YELP_HELP_RULES@ automake macro expansion comes from /usr/share/aclocal/yelp.m4 [1]. Commit which previously needed to add the sed edit: cbb25a2511ec9e355b4dbba288689bbc00b7af65 Stop xmllint scrollkeeper-omf.dtd fetch failure breaking CI tests (#9) [1] Yelp > Yelp Tools > yelp.m4 http://yelp.io/tools/yelp.m4.html Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2019-02-24 Mike Fleetwood Launch help from GParted using the new GNOME 3 help: prefix (!24) Update GParted to specify the GParted Manual using the new GNOME 3 way with the 'help:' prefix to avoid yelp reporting this error: Document Not Found The URI 'ghelp:gparted' does not point to a valid page. Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2019-02-24 Mike Fleetwood Allow GNOME 3 yelp to display the GParted Manual (!24) Now with GNOME 3 style help installed, running 'yelp help:gparted' results in this error being displayed in yelp: Page Not Found The requested page was not found in the document 'help:gparted'. Where as running 'yelp help:gparted/gparted' correctly displays the GParted Manual. Fix by renaming the article tag to the default 'index' that yelp is expecting when using the new GNOME 3 'help:' prefix. Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2019-02-23 Mike Fleetwood Add use of new GNOME 3 yelp-tools documentation infrastructure (!24) Second part is to use yelp-tools to build and install the documentation. Have to rename the help Manual from help/C/gparted.xml to help/C/index.docbook in accordance with this note from the GNOME Goal: Port to New Documentation Infrastructure [1]: IMPORTANT: If this is for a DocBook document, the top-level DocBook file MUST be renamed to index.docbook. Do a "git mv" and include index.docbook in HELP_FILES. Commits from gucharmap [4] and totem [5], projects which have DocBook documentation, making this same change are also useful references. [1] GNOME Goal: Port To New Documentation Infrastructure https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure [2] Yelp > Yelp Tools > yelp.m4 http://yelp.io/tools/yelp.m4.html [3] GNOME application developement overview / User help / Set up your build system https://developer.gnome.org/platform-overview/stable/dev-help-build.html.en [4] gucharmap commit "Port to new documentation infrastructure" https://gitlab.gnome.org/GNOME/gucharmap/commit/3e1526c0568f0b395fce68f9d9e09431dfcaef35 [5] totem commit "Use new documentation infrastructure" https://gitlab.gnome.org/GNOME/totem/commit/59a6bd6064fe7dd047f7b61642aba73e0ba72acf Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2019-02-21 Mike Fleetwood Remove use of GNOME 2 gnome-doc-utils documentation infrastructure (!24) Details of old GNOME 2 gnome-doc-utils: Migrating your documentation to gnome-doc-utils https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo First part is to stop using gnome-doc-utils to build and install the documentation. Also since updating the OMF catalog was only needed for GNOME 2 yelp, use of scrollkeeper is completely removed too. Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2013-07-31 Jeremy Bicha Fix FDL help link for gnome-desktop 3.5+ (!24) I generated this by running: find ./ -type f -exec sed -i 's/ghelp:fdl/help:fdl/g' {} \; By updating the translations at the same time, it should be easier on the translators as there's no reason to invalidate these strings. https://bugzilla.gnome.org/show_bug.cgi?id=704634#c8 [Mike Fleetwood: Explain the underlying cause and distro versions.] This gnome-desktop commit, first included in version 3.5.5, switched the package from using gnome-doc-utils to yelp-tools so changed the installed location of the GNU FDL license file from /usr/share/gnome/help/fdl/C/fdl.xml to /usr/share/help/C/fdl/index.docbook, thus changing the yelp URI from 'ghelp:fdl' to 'help:fdl': https://gitlab.gnome.org/GNOME/gnome-desktop/commit/8b7e059e2c01ec67d8aaf33133e695efae2173f8 Port to new documentation infrastructure The oldest supported distributions with Gtk/GNOME 3 all have at least 3.10, therefore use this fix unconditionally. Distribution EOL Gtk/GNOME 3 RHEL / CentOS 7 2024-Jun 3.22 Ubuntu 14.04 LTS 2019-Apr 3.10 Ubuntu 16.04 LTS 2021-Apr 3.18 Debian 8 2023-Apr 3.14 SLES 12 2027-Oct 3.10 Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2019-02-15 Mike Fleetwood Remove redundant file help/C/Makefile.am (!24) The file has been redundant since it was first added [1]. It was never listed in configure.ac (or configure.in) in AC_CONFIG_FILES. Therefore autoconf has never produced help/C/Makefile.in and ./configure has never produced help/C/Makefile. Therefore it isn't used during the build and install of GParted. Remove it. [1] 46ca7c74dca80b4b6ec8f6596832510cdc7f714b Added code hooks to prepare for GParted Manual Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure 2019-02-28 Kukuh Syafaat Update Indonesian translation 2019-02-26 Nathan Follens Update Dutch translation 2019-02-15 Mike Fleetwood Remove left behind configuration summary lines (!22) These lines in the final configuration report from ./configure were left behind [1] when determination of the underlying definitions were remove. So they no longer report 'yes' or 'no' like the other lines in the file configuration report. Need partition table re-read workaround? : Supports large sector sizes (> 512 bytes)? : Remove them now. [1] 8df975c7d1b5d69897f286bfc5574c51cf58c9d5 Increase minimum required libparted to 2.2 (!22) Closes !22 - Increase minimums to libparted 2.2 and glibmm 2.32 2019-02-01 Mike Fleetwood Remove left behind commented #includes from fat16.cc According to the GIT history the lines were added by this commit: 8d808c0b62a8387ba1703a0493746add5785fff5 gparted-0.3.6 - code recreation from Source Forge Looking at the SVN history this commit actually fleshed out the implementations of fat16::get_label() and fat32::get_label() and added the commented #includes: https://sourceforge.net/p/gparted/svn/118 Added read label support for fat16 and fat32 using mtools mlabel command 2008-02-12 Then this SVN commit moved the mtools temporary file handling code into Utils.cc, leaving behind the commented #includes: https://sourceforge.net/p/gparted/svn/124 Added MTools temporary file handling functions 2008-02-19 Finally this commit removed fat32.cc by merging the code with fat16.cc: 519af1a7c08667c53e602012e2a49cbf5301f40c Combine duplicate code for fat16/32 So remove the left behind commented #includes from fat16.cc. 2019-02-09 Mike Fleetwood Enable online resizing of extended partitions (!23) A forum user had a case where they wanted to grow their in use root, ext4 file system. GParted supports this, but the partition was a logical partition inside an extended partition and GParted doesn't support resizing an extended partition while any contained logical partitions are busy. Example layout: Partition File System Mount Point /dev/sdb1 ntfs /dev/sdb2 [busy] /dev/sdb5 [busy] ext4 / unallocated unallocated So just allow extended partitions to be resized online when online partition resizing is available via libparted. NOTE: The block device that the Linux kernel provides for an extended partition just maps to the first 1 KiB of the extended partition where the Extended Boot Record is stored, and does not include any of the contained logical partitions. Therefore no application can care that the extended partition is resized while a logical partition is in use because it can't use the extended partition block device to access any data. The on disk layout looks like this: # fdisk -l /dev/sdb Disk /dev/sdb: 8589 MB, 8589934592 bytes, 16777216 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 Disk label type: dos Disk identifier: 0x0007650e Device Boot Start End Blocks Id System /dev/sdb1 2048 1050623 524288 7 HPFS/NTFS/exFAT /dev/sdb2 1050624 2101247 525312 5 Extended /dev/sdb5 1052672 2101247 524288 83 Linux # parted /dev/sdb unit s print free Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 16777216s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 63s 2047s 1985s Free Space 1 2048s 1050623s 1048576s primary ntfs 2 1050624s 2101247s 1050624s extended 5 1052672s 2101247s 1048576s logical ext4 2101248s 16777215s 14675968s Free Space The kernel's partition sizes from /sys/block/sdb/sdb${N}/{start,size} shows extended partition 2 has a size of only 2 sectors: # for N in 1 2 5 > do > echo -e "/dev/sdb${N}\tstart=`cat /sys/block/sdb/sdb${N}/start`\tsize=`cat /sys/block/sdb/sdb${N}/size`" > done /dev/sdb1 start=2048 size=1048576 /dev/sdb2 start=1050624 size=2 /dev/sdb5 start=1052672 size=1048576 The EBR read from the whole of extended partition 2 block device: # hexdump -C /dev/sdb2 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 86 |................| 000001c0 06 41 83 cb 09 82 00 08 00 00 00 00 10 00 00 00 |.A..............| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 Closes !23 - Enable online resizing of extended partitions 2019-02-11 Mike Fleetwood Recognise contribution by Luca Bacci 2019-01-22 Luca Bacci Prevent the legend text making the features dialog too wide (#7) With the Gtk3 port the File System Support dialog has become too wide because the legend text is no longer wrapped. Set the max-width-chars property to specify the natural size of the widget in terms of characters [1]. It is converted to pixels using the average character width in the current font. Also use PACK_EXPAND_WIDGET when adding the label to the box so that if the dialog is resized extra space is used to increase the size of this child widget [2]. [1] GNOME HowDoI / Labels https://wiki.gnome.org/HowDoI/Labels [2] Gtkmm 3.0 Enums and Flags, enum Gtk::PackOptions "PACK_EXPAND_WIDGET Space is expanded, with extra space filled by increasing the child widget size." https://developer.gnome.org/gtkmm/3.0/group__gtkmmEnums.html#ga83727a1b6fed51566dfd5c8e58890dba Closes #7 - Port to Gtk3 2019-01-22 Luca Bacci Enable display of progress bar text when applying operations (#7) In Gtk2 progress bars show optional text superimposed over the bar. In Gtk3 the text is not displayed by default, so set the show-text property to re-enable this [1]. Also note that since Gtk 3.14.0 the optional text is not superimposed over the progress bar, but instead displayed just above it [2][3][4]. References: [1] Gtkmm 3.0 Gtk::ProgressBar Class Reference, set_show_text() "Sets whether the progressbar will show text superimposed over the bar." https://developer.gnome.org/gtkmm/3.0/classGtk_1_1ProgressBar.html#a0bfa6042f5d4b3509967abc2d8af57fe [2] Commit - Update the design for progress bars https://gitlab.gnome.org/GNOME/gtk/commit/74405cc964e405ea00cfac22856a62fea5ec648e [3] Bug 748784 - GtkProgressBar text cannot be superimposed on the progress bar https://bugzilla.gnome.org/show_bug.cgi?id=748784 [4] Gtkmm 3.18 Gtk:ProgressBar Class Reference, set_show_text() "Set whether the progress bar will show text next to the bar." https://developer.gnome.org/gtkmm/3.18/classGtk_1_1ProgressBar.html#a0bfa6042f5d4b3509967abc2d8af57fe Closes #7 - Port to Gtk3 2019-01-22 Luca Bacci Ensure SpinButtons have space to display 7 digits (#7) In Gtk2 the up and down buttons in a SpinButton were smaller leaving space for 7 digits before scrolling the entry. In Gtk3 the up and down buttons are much larger leaving only space for 4 digits. This occurs in the SpinButtons in the Dialog_Base_Partition class as displayed in the New Partition, Paste and Resize/Move dialogs. Set width-chars property of all Gtk::SpinButtons to ensure 7 digits can be displayed before scrolling the entry. Closes #7 - Port to Gtk3 2019-01-22 Luca Bacci Change Gtk::ProgressBar appearance by providing custom CSS (#7) In Gtk3 the progress bar height is fixed and defined by the CSS theme in use. Changing the widget allocation size does nothing, it is always rendered the same way. In many themes, including Adwaita, the progressbar is very, very thin. Provide custom CSS to specify a height of 8 pixels. The CSS source string has to be differentiated for Gtk pre and post 3.20, because Gtk 3.20 introduced some breaking changes in the way CSS is handled. References: [1] Migrating from GTK+ 2.x to GTK+ 3 - Parsing of custom resources https://developer.gnome.org/gtk3/stable/gtk-migrating-GtkStyleContext-parsing.html [2] Gtk3 Reference Documentation - Changes in GTK+ 3.20 https://developer.gnome.org/gtk3/stable/ch32s10.html [3] Gnome/HowDoI - Custom Style https://wiki.gnome.org/HowDoI/CustomStyle Closes #7 - Port to Gtk3 2018-08-28 Luca Bacci Change packing of pulsebar in statusbar (#7) The pulsebar looks very small and needs to be widened. The pulsebar is packed inside the statusbar so that it displays activity text on the left side and the pulsebar on the right side. Ideally we want the space to be evenly divided for the textual messages and for the pulsebar activity indicator. For this we just have to set the 'homogeneous' property to TRUE for the statusbar (note that GtkStatusBar inherits from GtkBox). Also vertically align the pulsebar to the center of the statusbar. This is achieved setting the 'valign' property to Gtk::ALIGN_CENTER for the pulsebar widget. Closes #7 - Port to Gtk3 2018-08-30 Luca Bacci Work around Gtk3 Gtk-CRITICAL messages when closing some dialogs (#7) There is a bug affecting Gtk+ 3.22.8 to 3.22.30 in which destroying a GtkComboBox when it is not hidden results in this message: Gtk-CRITICAL **: gtk_widget_is_drawable: assertion 'GTK_IS_WIDGET (widget)' failed This happens in GParted when some dialogs are closed, for example the Create New Partition and Create Partition Table dialogs. To work around the issue we call Gtk::Dialog::hide() in the destructors of our dialog classes. The issue was fixed in Gtk 3.24.0. * Gtk 3.22.8 was released in February 2017. * Gtk 3.24.0 was released in September 2018. References: [1] Gtk Issue - GtkComboBox::private::popup_window can be NULL https://gitlab.gnome.org/GNOME/gtk/issues/125 [2] Gtk commit - combobox: popdown() the menu during unmap() https://gitlab.gnome.org/GNOME/gtk/commit/7401794de6b084fea469af297b7c144724b8492c [3] Gtk commit - Check for NULL priv->popup_window in gtk_combo_box_popdown() https://gitlab.gnome.org/GNOME/gtk/commit/aa5d926c843aca2af576c38cf25ebdb4d3da2c26 Closes #7 - Port to Gtk3 2018-11-21 Luca Bacci Work around Gtkmm3 issue where menu accelerators are not shown (#7) There is a bug in Gtkmm3 when setting accelerator keys on a Gtk::MenuItem, the accelerator keys work but are not displayed when the menu is drawn. This happens for Gtk::MenuItems, including derived objects, that are constructed with a non-default constructor. All non-default constructors of Gtk::MenuItem, and subclasses, work by creating themselves a Gtk::AccelLabel and packing it inside the menu item. But in Gtk3 GtkMenuItem are created with a GtkAccelLabel already packed in as a child and that accel label should be used instead. To workaround the issue we only use the default constructor for Gtk::MenuItem and subclasses. This is easy to do because we only have to change the wrappers in MenuHelpers.cc. This bug affects Gtkmm version 3.0.0 to 3.22.2 and was fixed in Gtkmm 3.22.3. * Gtkmm 3.0.0 was released in April 2011 * Gtkmm 3.22.3 was released in November 2018 References: [1] Bug Report on the Gtkmm mailing list https://mail.gnome.org/archives/gtkmm-list/2018-February/msg00006.html [2] Commit - Gtk::MenuItem: Fix add_accel_label() https://gitlab.gnome.org/GNOME/gtkmm/commit/e5c8c2df67d0d7ec255055984e8f07d0f0fa0862 Closes #7 - Port to Gtk3 2018-08-13 Luca Bacci Simplify code using Gtk::Container::get_children() (#7) GParted uses Gtk::Container::get_children(). In Gtkmm2 Gtk::Container::get_children() returns a Glibmm intermediate container [1]. Gtkmm3 dropped the use of Glibmm intermediate containers in favour of STL containers [2][3]. Now that Gtk::Container::get_children() directly returns a std::vector<> simplify the code. References: [1] Gtkmm 2.24 Gtk::Container Class Reference "Glib::ListHandle Gtk::Container::get_children()" https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Container.html#acd2f9b9ac16ba96178d3f5169b07f4d0 [2] Gtkmm 3.0 Gtk::Container Class Reference "std::vector Gtk::Container::get_children()" https://developer.gnome.org/gtkmm/3.0/classGtk_1_1Container.html#a3a2111e255cb5b72bd91a3be087cff27 [1] Programming with gtkmm3 / Changes in gtkmm3 "11. We now use std::vector in several methods instead of the intermediate *Handle types to make the API clearer." https://developer.gnome.org/gtkmm-tutorial/3.0/changes-gtkmm3.html.en Closes #7 - Port to Gtk3 2018-09-05 Luca Bacci port-to-gtk3: Block Gtk::TreeSelection changed handler on tree model clear (#7) Now GParted compiles with Gtkmm3, but we get a failed assertion doing the following: * Select a device with more than 1 partition * Select a partition * Activate 'Refresh Devices' (or do any operation that causes it, like mount/unmount etc.) This is the failed assertion: ** ERROR:Win_GParted.cc:1152:void GParted::Win_GParted::set_valid_operations(): assertion failed: (valid_display_partition_ptr( selected_partition_ptr )) Aborted (core dumped) Where is the problem? Win_GParted::Refresh_Visual() calls TreeView_Detail::load_partitions() to clear and refill the treeview. The problem is in GParted::TreeView_Detail::load_partitions() at TreeView_Detail.cc:91: treestore_detail->clear(); This activates TreeView_Detail::on_selection_changed() which in turn activates Win_GParted::on_partition_selected() passing an old, stale pointer as an argument. This triggers the failed assertion. Why does this happen with Gtk3 and not with Gtk2? First a bit of background of GtkTreeView: What happens to the selection in a GtkTreeView when the selected row is removed? With Gtk2 the selection simply becomes empty, so nothing is selected afterwards. With Gtk3 this was changed [1] and selection moves to an adjacent row. gtk_tree_store_clear() removes rows one by one. While removing rows the selection changed signal is emitted. With Gtk2 it is emitted only one time, to indicate that selection has become empty. With Gtk3 it is instead emitted several times, each time indicating that selection has moved to the adjacent row. The handler TreeView_Detail::on_selection_changed() only takes action when the selection is not empty. So with Gtk3 it really takes action and activates Win_GParted::on_partition_selected() with a pointer to old data. What's the purpose of TreeView_Detail::on_selection_changed()? Its task is to update the selection in the drawing area above the TreeViewDetail, the DrawingAreaVisualDisk, so that the selected partition stays in sync on the two widgets. Fix by blocking the signal handler during the treeview clear. Reference: [1] Commit - treeview: Handle the case where the cursor row gets deleted https://gitlab.gnome.org/GNOME/gtk/commit/1a2932ba2915c34171581a85afba39311e9c3ac6 Closes #7 - Port to Gtk3 2018-08-09 Luca Bacci port-to-gtk3: Use Gdk::AppLaunchContext to launch yelp (#7) gdk_spawn_command_line_on_screen() is not present in Gtk3. The documentation from Gtkmm 2.24 states [1]: gdk_spawn_command_line_on_screen has been deprecated since version 2.24 and should not be used in newly-written code. This function is being removed in 3.0. Use either g_spawn_command_line_sync(), g_spawn_command_line_async() or GdkAppLaunchContext instead. g_spawn_command_line_sync() and g_spawn_command_line_async() are screen / display agnostic, as such we would loose functionality. There is a workaround, which involves setting the DISPLAY environment variable [2], but it's a weak solution (and I don't know if it works on backends other than X11). GdkAppLaunchContext is an implementation of GIO's GAppLaunchContext that handles launching an application in a graphical context [3]. Therefore use GdkAppLaunchContext and GIO's GAppInfo. GdkAppLaunchContext was introduced in Gtk2 version 2.14. The C++ wrapper Gdk::AppLaunchContext was introduced only in Gtkmm3 version 3.4 [4]. Bump the minimum required version of Gtkmm to 3.4.0 for this requirement. GAppInfo was introduced in GLib version 2.16. The C++ wrapper Gio::AppInfo was introduced in Giomm version 2.16. Note that the minimum required version for glibmm is already 2.32. [1] GDK 2 Reference Manual, GdkScreen, gdk_spawn_on_screen() https://developer.gnome.org/gdk2/2.24/GdkScreen.html#gdk-spawn-on-screen [2] Migrating from GTK+ 2.x to GTK+ 3 - "Use GIO for launching applications" https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.7 [3] GDK 3 Reference Manual - "Application launching" https://developer.gnome.org/gdk3/stable/gdk3-Application-launching.html [4] Gtkmm 3.4 Gdk::AppLaunchContext Class Reference, Detailed Description https://developer.gnome.org/gtkmm/3.4/classGdk_1_1AppLaunchContext.html#details Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Use Gtk::CellLayout::get_cells() (#7) GParted uses Gtk::TreeViewColumn::get_cell_renderers(). This is not present in Gtkmm3. Now Gtk::TreeViewColumn inherits from Gtk::CellLayout and we have to use Gtk::CellLayout::get_cells() instead. GtkCellLayout was introduced in Gtk2 version 2.18 as the common interface for containers of cell renderers. The C++ wrapper Gtk::CellLayout was introduced in Gtkmm2 version 2.18, but Gtk::TreeViewColumn was never made to inherit from Gtk::CellLayout to avoid breaking the API / ABI. That change was made for Gtkmm3. This is an excerpt from gtkmm/treeviewcolumn.h header in Gtkmm2: // TODO: Should be deprecated, but we cannot derive from CellLayout // without breaking API and ABI. /** Returns a list of all the cell renderers in the column, * in no particular order. * * @return A list of Gtk::CellRenderers. */ Glib::ListHandle get_cell_renderers(); Replace Gtk::TreeViewColumn::get_cell_renderers() with base class method Gtk::CellLayout::get_cells(). Reference: [1] Commit - "Deprecate get_cell_renderers implementations" https://gitlab.gnome.org/GNOME/gtk/commit/6abc52a29d2b15c255ada7d199b703a95f8c565b Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Use draw signal in the partition resizer (#7) In Gtk2 widgets draw themselves in response to the expose event signal. In Gtk3 widgets draw themselves in response to the GtkWidget::draw signal, and the signal handler gets a Cairo context as an argument. Convert Gtk::DrawingArea rendering code to respond to the GtkWidget::draw signal. This commit is specific to the drawing area in the Create new Partition dialog and the Resize/Move dialog. Reference: [1] Migrating from GTK+ 2.x to GTK+ 3 - "The GtkWidget::draw signal": https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11 Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Use draw signal in the partition visualizer (#7) In Gtk2 widgets draw themselves in response to the expose event signal. In Gtk3 widgets draw themselves in response to the GtkWidget::draw signal, and the signal handler gets a Cairo context as an argument. Convert Gtk::DrawingArea rendering code to respond to the GtkWidget::draw signal. This commit is specific to the drawing area contained in the main application window (also called the DrawingAreaVisualDisk). Reference: [1] Migrating from GTK+ 2.x to GTK+ 3 - "The GtkWidget::draw signal": https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11 Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Use draw signal in the partition info dialog (#7) In Gtk2 widgets draw themselves in response to the expose event signal. In Gtk3 widgets draw themselves in response to the GtkWidget::draw signal, and the signal handler gets a Cairo context as an argument. Convert Gtk::DrawingArea rendering code to respond to the GtkWidget::draw signal. This commit is specific to the drawing area in the Partition Info dialog. Reference: [1] Migrating from GTK+ 2.x to GTK+ 3 - "The GtkWidget::draw signal": https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11 Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Use Gtk::Widget::render_icon_pixbuf() (#7) In Gtk3/C, gtk_widget_render_icon() was deprecated in Gtk 3.0 [1]. In Gtkmm3/C++, Gtk::Widget::render_icon() was abruptly removed from Gtkmm 3.0 and replaced with Gtk::Widget::render_icon_pixbuf() [2]. Gtk::Widget::render_icon() [3] had an optional 3rd parameter which GParted never used. Replace with Gtk::Widget::render_icon_pixbuf() [4]. References: [1] GTK+ 3 Reference Manual, GtkWidget https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-render-icon "gtk_widget_render_icon has been deprecated since version 3.0 and should not be used in newly-written code." [2] Gtkmm 3.0.0 NEWS file "... Removed render_icon(), adding render_icon_pixbuf()." https://gitlab.gnome.org/GNOME/gtkmm/blob/3.0.0/NEWS#L187 [3] Gtkmm 2.24 Gtk::Widget Class Reference, render_icon() https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Widget.html#a91efd1b5aed7c184506ddd5721710584 [4] Gtkmm 3.0 Gtk::Widget Class Reference, render_icon_pixbuf() https://developer.gnome.org/gtkmm/3.0/classGtk_1_1Widget.html#a28bbbd0c1717e58343df56f7f422b106 Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Use Gdk::Cursor via Glib::RefPtr<> (#7) Starting from Gtkmm3 Gdk::Cursor objects cannot be constructed directly, but instead you have to get a smart pointer to an instance by calling the static member function Gdk::Cursor::create(). Gdk::Cursor::create() returns a Glib::RefPtr object. Gtkmm3 always uses Glib::RefPtr in its interface and never plain Gdk::Cursor. Reference: [1] Programming with gtkmm3, Changes in gtkmm3: https://developer.gnome.org/gtkmm-tutorial/3.24/changes-gtkmm3.html.en "... Gdk::Cursor are now used via Glib::RefPtr." Closes #7 - Port to Gtk3 2018-08-29 Luca Bacci port-to-gtk3: Rework Gtk header includes (#7) In Gtk3 individual headers cannot be included directly in application code, only the header can be included (with a few exceptions for some platform specific headers). This has always been considered good practice even for Gtk2, though was not a hard requirement. In Gtk3 this is enforced by preprocessor checks. Failure to do so yields a preprocessor error and compilation fails: "error: Only can be included directly." Change specific Gtk header includes to: #include References: [1] Migrating from GTK+ 2.x to GTK+ 3 - "Do not include individual headers" https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.3 [2] Commit - "Remove all traces of GDK_PIXBUF/GTK_DISABLE_SINGLE_INCLUDES" https://gitlab.gnome.org/GNOME/gtk/commit/5e29973773d4e2177f234675cc2a2b2016aa9fbc Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci port-to-gtk3: Rework Gtkmm header includes (#7) Now that we are compiling against Gtkmm3 there are missing declarations of Gtkmm identifiers due to changes in Gtkmm internal header structure. All we have to do is bring back the declarations by including the appropriate headers where needed. Add necessary Gtkmm header includes. Closes #7 - Port to Gtk3 2018-12-04 Luca Bacci port-to-gtk3: Rework Glibmm header includes (#7) Now that we are compiling against Gtkmm3 there are missing declarations of Glibmm identifiers due to changes in Gtkmm internal header structure. All we have to do is bring back the declarations by including the appropriate headers where needed. Add necessary Glibmm header includes. Closes #7 - Port to Gtk3 2018-08-27 Luca Bacci port-to-gtk3: Switch to Gtkmm3 (#7) Switch to Gtkmm3 in configure.ac. Require version 3.0.0. Also update the build instructions in README and the package list in .gitlab-ci.yml. Starting from version 3.18.0 Gtkmm requires C++11 compilation [1][2][3]. Add a check for Gtkmm >= 3.18.0 in configure.ac and enable C++11 compilation accordingly. References: [1] Gtkmm 3.18.1 NEWS "Changes in 3.18 ... Use, and require C++11, ..." https://gitlab.gnome.org/GNOME/gtkmm/blob/3.18.1/NEWS#L35 [2] Murray's Blog - "gtkmm now uses C++11" https://www.murrayc.com/permalink/2015/07/31/gtkmm-now-uses-c11 [3] Murray's Blog - "gtkmm 3.18 and glibmm 2.46" https://www.murrayc.com/permalink/2015/09/25/gtkmm-3-18-and-glibmm-2-46 Closes #7 - Port to Gtk3 2018-08-09 Luca Bacci prepare-for-gtk3: Prepare for removal of Gtk::Widget::modify_fg() (#7) The Gtk::Widget::modify_fs() API was removed in Gtkmm3 [1] and also there is no direct replacement. GParted uses this in one place. So instead use the C gtk_widget_modify_fg() version that is still present in Gtk3. This is just a temporary change to port GParted to Gtk3. In future this will be replaced as part of the switch from Gdk::Color to Gtk::RGBA, since Gdk::Color was deprecated in Gtkmm 3.10 [2]. Reference: [1] https://gitlab.gnome.org/GNOME/gtkmm/commit/ee432e21901c8ee7f68f6562c46f9e5e6ef17de7 commit message "... Remove the modify_*() methods, ..." [2] Gtkmm 3.10 Gdk::Color Class Reference https://developer.gnome.org/gtkmm/3.10/classGdk_1_1Color.html#details Deprecated: Use Gdk::RGBA instead. Closes #7 - Port to Gtk3 2018-08-02 Luca Bacci prepare-for-gtk3: Prepare for removal of Gtk::Menu_Helpers::MenuList (#7) GParted uses Gtk::Menu_Helpers::MenuList helper class to access individual menu items. This helper class made it easy to navigate menu items by index. Gtk::Menu_Helpers::MenuList was removed in the switch from Gtkmm2 to Gtkmm3 [1]. Instead, use a separate std::map to keep track of individual Gtk::MenuItem objects. Reference: [1] Gtkmm 3 commit "MenuShell: Remove items()." removed the code https://gitlab.gnome.org/GNOME/gtkmm/commit/c8e47b0db5505db0e10e74ce1d7286c2230958b5 Closes #7 - Port to Gtk3 2018-07-31 Luca Bacci prepare-for-gtk3: Prepare for removal of Gtk::Menu_Helpers::Element (#7) Gtk::Menu_Helpers::Element class and subclasses help in Gtk::MenuItem widgets and also automate tasks like registering keyboard accelerators when parented to a top-level window [1][2]. Gtk::Menu_Helpers::Element class and subclasses were removed in Gtkmm3 [3]. Provide compatible implementations under the namespace GParted::Menu_Helpers. References: [1] gtkmm: Gtk::Menu_Helpers Namespace Reference https://developer.gnome.org/gtkmm/2.24/namespaceGtk_1_1Menu__Helpers.html [2] gtkmm: Gtk::Menu_Helpers::Element Class Reference https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Menu__Helpers_1_1Element.html [3] Gtkmm 3 commit "MenuShell: Remove items()." removed the code https://gitlab.gnome.org/GNOME/gtkmm/commit/c8e47b0db5505db0e10e74ce1d7286c2230958b5 Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci prepare-for-gtk3: Replace deprecated GDK_ constants (#7) During the switch from Gtk2 to Gtk3 keyname constants were renamed from GDK_ to GDK_KEY_ [1]. This was done to avoid name clashes in gobject-introspection and language bindings. The new constant names were also backported to Gtk 2.22 [2]. Make use of the new constant names. References: [1] Migrating from GTK+ 2.x to GTK+ 3 - "Replace GDK_ with GDK_KEY_" https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.6 [2] Commit - "gdk: Prefix keys with _KEY by default" https://gitlab.gnome.org/GNOME/gtk/commit/750c81f43dda6c783372b983e630ecd30b776d7e Closes #7 - Port to Gtk3 2018-08-03 Luca Bacci prepare-for-gtk3: Remove calls to Gtk::Dialog::set_has_separator() (#7) Originally in Gtk2, by default, dialogs showed a horizontal separator between the content area and the action area (buttons). GParted explicitly called Gtk::Dialog::set_has_separator(false) for all it's dialogs to remove the separator. In Gtk2/Gtkmm2 2.22, separators were deprecated [1]. In Gtk3/Gtkmm3 separators in dialogs were removed altogether, including all the related APIs [2][3][4]. Therefore remove all calls. References: [1] Commit - "Document separator-related api in GtkDialog as deprecated" https://gitlab.gnome.org/GNOME/gtk/commit/6f6650e6cff06ff7c7e70db634ab10510a80c04c [2] Commit - "Remove separators from dialogs" https://gitlab.gnome.org/GNOME/gtk/commit/d433a606111d89727530f71d7b956ba40655bcbf [3] GTK+ 3.0.0 NEWS file https://gitlab.gnome.org/GNOME/gtk/blob/3.0.0/NEWS#L779 " Overview of Changed from GTK+ 2.90.6 to 2.90.7 ============================================== * Various deprecated APIs have been removed: ... - GtkDialog separators, including the GtkDialog::has-separator property, including setter/getter, the GTK_DIALOG_NO_SEPARATOR flag and the GtkMessageDialog::use-separator style property " [4] Gtkmm 3.0.0 NEWS file https://gitlab.gnome.org/GNOME/gtkmm/blob/3.0.0/NEWS#406 " * Dialog: - Remove get/set_has_separator() and property. - Constructors: Remove use_separator parameters. " Closes #7 - Port to Gtk3 2019-01-28 Balázs Úr Update Hungarian translation 2019-01-20 Mike Fleetwood Update to Google Test 1.8.1 Update to Google Test C++ test framework from release 1.8.0 to 1.8.1. Replace the following files and directories from Google Test 1.8.1: LICENSE README.md include/ src/ Note the LICENSE file is identical, where as the other files changed. Also see commit which initially added Google Test: 87f7170a55e1a04aeca5412ebb97e0fe0bfe7b4c Add Google Test 1.8.0 files (#781978) 2019-01-20 Mike Fleetwood Remove custom main() from test_PipeCapture (!22) After removing Glib::thread_init() from test_PipeCapture's main() all it does is exactly what the built in Google Test main() does [1][2]. So use that instead like the other unit test programs do. [1] Google Test, Primer, Writing the main() Function https://github.com/google/googletest/blob/master/googletest/docs/primer.md#writing-the-main-function [2] Google Test 1.8.0, gtest_main.cc::main() file: lib/gtest/src/gtest_main.cc https://github.com/google/googletest/blob/release-1.8.0/googletest/src/gtest_main.cc#L34 Closes !22 - Increase minimums to libparted 2.2 and glibmm 2.32 2018-12-24 Mike Fleetwood Remove deprecated Glib::thread_init() (!22) Use of Glib::thread_init() was deprecated in glibmm 2.32 [1]. The oldest supported distributions have these versions: Debian 8 glibmm 2.42.0 RHEL / CentOS 7 glibmm 2.56.0 SLES 12 glibmm 2.38.1 Ubuntu 14.04 LTS glibmm 2.39.93 Checking further the glibmm 2.32 reference manual says this about Glib::thread_init() [2]: Initializes the GLib thread system. Deprecated: Calling thread_init() is no longer necessary and no longer has any effect. However only some of the glibmm example programs had Glib::thread_init() removed, others had it replaced by Glib::init() [3]. Again the glibmm 2.32 reference manual says this about Glib::init() [4]: Initialize glibmm. You may call this more than once. You do not need to call this if you are using Glib::MainLoop or Gtk::Main, because they call it for you. GParted does call Gtk::Main and test_PipeCapture does call Glib::MainLoop. Therefore just raise the minimum version to glibmm 2.32 and remove both calls to Glib::thread_init(). [1] Glibmm 2.32 NEWS file https://gitlab.gnome.org/GNOME/glibmm/blob/2.32.0/NEWS#L207 [2] glibmm 2.32, glibmm: Glib Namespace Reference, Glib::thread_init() https://developer.gnome.org/glibmm/2.32/namespaceGlib.html#ab26d01c776801f1fff00753e97af4fc7 [3] glibmm commit "Avoid use of deprecates API in tests and examples." https://gitlab.gnome.org/GNOME/glibmm/commit/3e0fbb22c0d4814de4174d32e12a45cbad79980e [4] glibmm 2.32, glibmm: Glib Namespace Reference, Glib::init() https://developer.gnome.org/glibmm/2.32/namespaceGlib.html#ac90aee10d0b90e3d8a96a86b5394f87b Closes !22 - Increase minimums to libparted 2.2 and glibmm 2.32 2018-12-18 Mike Fleetwood Increase minimum required libparted to 2.2 (!22) Raise the minimum required version of GNU Parted from 1.7.1 to 2.2, released 2010-02-16 [1][2]. The oldest supported distributions, also with gtkmm >= 2.24, since commit [3], are: Debian 8 parted 3.2 RHEL / CentOS 7 parted 3.1 SLES 12 parted 3.1 Ubuntu 14.04 LTS parted 2.3 Raising the minimum required version allows removal of optional code associated with these definitions: * USE_LIBPARTED_LARGE_SECTOR_SUPPORT Fallback code reporting ignored device with logical sector size other than 512 bytes. * ENABLE_PT_REREAD_WORKAROUND Fallback code re-attempting to inform the kernel of partition changes. [1] GNU Parted 2.2 release announcement http://lists.gnu.org/archive/html/info-gnu/2010-02/msg00016.html [2] NEWS file from GNU Parted 2.2 http://git.savannah.gnu.org/cgit/parted.git/tree/NEWS?h=v2.2 [3] 8b42bab1eea572a2a43e99e3d86fe93920675599 modern-gtk2: Require Gtkmm version 2.24 (!17) Closes !22 - Increase minimums to libparted 2.2 and glibmm 2.32 2019-01-20 Carmen Bianca BAKKER Update Esperanto translation 2019-01-02 Anders Jonsson Update Swedish translation 2018-12-28 Yuras Shumovich Add Belarusian translation 2018-12-13 Curtis Gedak Update name typo in NEWS file 2018-12-13 Curtis Gedak Append -git to version for continuing development 2018-12-13 Curtis Gedak ========== gparted-0.33.0 ========== 2018-12-11 Milo Casagrande Update Italian translation 2018-12-09 Baurzhan Muftakhidinov Update Kazakh translation 2018-12-06 Daniel Șerbănescu Update Romanian translation 2018-12-06 Daniel Șerbănescu Update Romanian translation 2018-12-05 Kristjan SCHMIDT Update Esperanto translation 2018-10-14 Mike Fleetwood Strip unnecessary scope from GParted::STAT_* (!20) The code inconsistently uses GParted:: scope in front of STAT_*. $ fgrep 'GParted::STAT_' src/*.cc | wc -l 3 $ egrep '[^:]STAT_' src/*.cc | wc -l 41 GParted:: scope resolution is unnecessary as all the code is inside the GParted scope, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups 2018-10-14 Mike Fleetwood Strip unnecessary scope from GParted::TYPE_* (!20) The code inconsistently uses GParted:: scope in front of TYPE_*. $ fgrep 'GParted::TYPE_' src/*.cc | wc -l 35 $ egrep '[^:]TYPE_' src/*.cc | wc -l 83 GParted:: scope resolution is unnecessary as all the code is inside the GParted scope, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups 2018-10-14 Mike Fleetwood Strip unnecessary scope from GParted::FS_* (!20) The code inconsistently uses GParted:: scope in front of FS_*. $ fgrep 'GParted::FS_' src/*.cc | wc -l 41 $ egrep '[^:]FS_' src/*.cc | wc -l 441 GParted:: scope resolution is unnecessary as all the code is inside the GParted namespace, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups 2018-10-13 Mike Fleetwood Strip unnecessary scope from GParted::FS::* (!20) The code inconsistency uses GParted::FS::* and FS::*. $ fgrep 'GParted::FS::' src/*.cc | wc -l 97 $ egrep '[^:]FS::' src/*.cc | wc -l 152 GParted:: scope resolution is unnecessary as all the code is inside the GParted namespace, except for main(). So remove it. Closes !20 - Minor namespace and scope operator tidy-ups 2018-11-22 Mike Fleetwood Put Frame_Resizer_{Base,Extended} modules into GParted namespace (!20) All the other modules are in the GParted namespace, except for main() which has to be in the global namespace, so put these in the GParted namespace too. Closes !20 - Minor namespace and scope operator tidy-ups 2018-11-25 Aurimas Černius Updated Lithuanian translation 2018-11-18 Mike Fleetwood Fix false usage figures for busy SWRAID members (#27) Create an active Linux Software RAID member which is larger than /dev virtual file system and GParted will report the usage figure of the /dev virtual file system for the SWRAID member. # df -h /dev Filesystem Size Used Avail Use% Mounted on devtmpfs 732M 0 732M 0% /dev # sgdisk -n 1:1M:+1G /dev/sdb # mdadm --create --verbose /dev/md1 --level=linear --raid-devices=1 --force /dev/sdb1 mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. GParted reports the usage of /dev/sdb1 as: Partition Mount Point Size Used Unused Unallocated /dev/sdb1 /dev/md1 1.00GiB 0.00B 731.04MiB 292.96MiB However GParted should have reported the usage as "---" for unknown because it isn't coded to query the size of the SWRAID member within a partition. The fault has been bisected to this commit: Extend un/mounting and usage reporting to unsupported file systems (!13) 95903efb1f284f3d6819f38e894dc6c3464b2183 What happens for busy Linux Software RAID array members: * GParted_Core::is_busy() has custom code to identify busy members. * GParted_Core::set_mountpoints() has custom code to add the array device name as the "mount point" of the member. * GParted_Core::set_used_sectors() falls into the else not a supported file system (because SWRAID doesn't have a derived FileSystem implementation class). * GParted_Core::mounted_set_used_sectors() is called to get the file system usage of mounted, but unsupported file systems, such as UFS and any others. * Utils::get_mounted_filesystem_usage() is called which queries the kernel using statvfs() and gets the file system usage of the /dev virtual file system because the array device name will always start /dev. Fix by ensuring that GParted only asks the kernel for the usage of paths which it knows are mount points of mounted file systems. (As read from /proc/mounts and cached in the Mount_Info module). Also rename the method, by inserting "_fs", to mounted_fs_set_used_sectors() to remind us that it is for mounted *file systems* only. Closes #27 - GParted may report incorrect usage for SWRAID partitions instead of unknown S 2018-10-30 Mike Fleetwood Recognise contribution by Luca Bacci 2018-08-02 Luca Bacci modern-gtk2: Use Cairo for drawing the partition visualizer (!17) Third commit in a series to convert Gdk::GC based drawing to Cairo based drawing. This specific commit makes the transition for the graphical partition visualizer widget that is used in the main application window. Closed !17 - Gtk2 modernisation 2018-08-02 Luca Bacci modern-gtk2: Use Cairo for drawing the partition info (!17) Second commit in a series to convert Gdk::GC based drawing to Cairo based drawing. This specific commit makes the transition for the graphical partition info widget that is used in the "Information about" dialog. Closes !17 - Gtk2 modernisation 2018-08-02 Luca Bacci modern-gtk2: Use Cairo for drawing the partition resizer (!17) GdkGC has been deprecated in the underlying C / GTK+ 2.22 library. It is less clearly stated but Gdk::GC is also deprecated in C++ / gtkmm. Cairo based rendering should be used instead. https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html https://gitlab.gnome.org/GNOME/gtk/blob/2.22.0/NEWS#L124 https://developer.gnome.org/gtkmm/2.24/classGdk_1_1GC.html First commit in a series to convert Gdk::GC based drawing to Cairo based drawing. This specific commit makes the transition for the graphical partition resizing widget that is used in the "Create New Partition", "Paste" creating new partition and "Resize/Move" dialogs. Cairo is not pixel based but instead uses a continuous coordinate space. To draw in a pixel aligned way follow the guidance in the Cairo FAQ. https://www.cairographics.org/FAQ/#sharp_lines Additional references: https://developer.gnome.org/gdk2/stable/gdk2-Drawing-Primitives.html#gdk-draw-line https://developer.gnome.org/gdk2/stable/gdk2-Drawing-Primitives.html#gdk-draw-rectangle Closes !17 - Gtk2 modernisation 2018-10-27 Luca Bacci modern-gtk2: Delay construction of Gtk::TreeModel* objects (!17) C++ initialises static member variables before main() is called. Therefore the static members of: struct Slots { static Gtk::TreeModelColumn text; static Gtk::TreeModelColumn sensitive; private: static Gtk::TreeModel::ColumnRecord record_; }; are constructed before Gtk::Main() is called in main(). However the Gtkmm documentation specifically says that they must be constructed afterwards [1]. Resolve this by using the Construct On First Use Idiom [2] to delay initialisation until the slots are first used. Normally this idiom uses static local objects, however it is being applied to class static objects here because the objects are accessed in many methods. The downside of this approach is that the objects are never destructed, which memory analysers like Valgrind could see as a memory leak, but that is actually deliberate. That leak can be removed once we can use C++11 and std::unique_ptr. [1] gtkmm: Gtk::TreeModelColumnRecord Class Reference https://developer.gnome.org/gtkmm/2.24/classGtk_1_1TreeModelColumnRecord.html#details "Neither TreeModel::ColumnRecord nor the TreeModelColumns contain any real data - they merely describe what C++ type is stored in which column of a TreeModel, and save you from having to repeat that type information in several places. Thus TreeModel::ColumnRecord can be made a singleton (as long as you make sure it's instantiated after Gtk::Main), even when creating multiple models from it. " [2] C++ FAQ / How do I prevent the "static initialization order problem"? https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use Closes !17 - Gtk2 modernisation 2018-08-03 Luca Bacci modern-gtk2: Rename callback after OptionComboBox class switch (!17) Final part in a series of commits to replace Gtk::OptionMenu widgets with GParted::OptionComboBox. This specific commit renames the signal handler callback to match the previously renamed combobox widget variable names. Closes !17 - Gtk2 modernisation 2018-07-31 Luca Bacci modern-gtk2: Use OptionComboBox class for file system combobox (!17) Third part in a series of commits to replace Gtk::OptionMenu widgets with GParted::OptionComboBox. This specific commit is about file system combobox. Closes !17 - Gtk2 modernisation 2018-07-31 Luca Bacci modern-gtk2: Use OptionComboBox class for partition type combobox (!17) Second part in a series of commits to replace Gtk::OptionMenu widgets with GParted::OptionComboBox. This specific commit is about partition type combobox. Closes !17 - Gtk2 modernisation 2018-07-31 Luca Bacci modern-gtk2: Use OptionComboBox class for alignment combobox (!17) First part in a series of commits to replace Gtk::OptionMenu widgets with GParted::OptionComboBox. This specific commit is about partition alignment combobox. Closes !17 - Gtk2 modernisation 2018-07-30 Luca Bacci modern-gtk2: Introduce OptionComboBox class (!17) Gtk::OptionMenu is a combobox type widget that is constructed from a Gtk::Menu rather than a Gtk::TreeModel. However Gtk::OptionMenu was deprecated in gtkmm 2.4.1. In GParted the Gtk::OptionMenu widget is used for: - partition alignment combobox - partition type combobox - file system combobox While they consist only of text we cannot use Gtk::ComboBoxText because it doesn't expose functionality in its interface to make items inactive. Create OptionComboBox helper class that builds a combobox consisting of only text items, much like Gtk::ComboBoxText, but has the added functionality to set items as inactive. References: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1OptionMenu.html#details https://gitlab.gnome.org/GNOME/gtkmm/blob/GTKMM_2_10_1/ChangeLog#L3515 https://gitlab.gnome.org/GNOME/gtkmm/commit/bba503b0473413e474d9b6d297226479d29fd47f https://developer.gnome.org/gtkmm/2.24/classGtk_1_1ComboBoxText.html Closes !17 - Gtk2 modernisation 2018-08-13 Luca Bacci modern-gtk2: Use Gtk::Widget::set_tooltip_text() (!17) GParted was using Gtk::Tooltips widgets for tooltips, but they were deprecated in gtkmm 2.12 in favour of Gtk::Tooltip widgets. (Note the spelling difference, with and without a trailing 's'). As GParted's tooltips are all text only continue to use the shortcut, which is now Gtk::Widget::set_tooltip_text(). References: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Tooltips.html#details https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Tooltip.html#details https://gitlab.gnome.org/GNOME/gtkmm/blob/2.20.0/NEWS#L740 Closes !17 - Gtk2 modernisation 2018-08-13 Luca Bacci modern-gtk2: Use Gtk::MenuItem::unset_submenu() (!17) Gtk::MenuItem::remove_submenu() was deprecated in gtkmm 2.12. Replace with Gtk::MenuItem::unset_submenu() introduced in gtkmm 2.22. References: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1MenuItem.html https://gitlab.gnome.org/GNOME/gtkmm/blob/2.22.0/NEWS#L24 Closes !17 - Gtk2 modernisation 2018-08-11 Luca Bacci modern-gtk2: Use Gtk::AboutDialog::set_program_name() (!17) Gtk::AboutDialog::set_name() was deprecated in gtkmm 2.12. Replace with Gtk::AboutDialog::set_program_name(). References: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1AboutDialog.html https://gitlab.gnome.org/GNOME/gtkmm/blob/2.20.0/NEWS#L741 Closes !17 - Gtk2 modernisation 2018-08-10 Luca Bacci modern-gtk2: Use Gtk::AlignmentEnum::ALIGN_START (!17) Gtkmm 2.22 deprecated Gtk::AlignmentEnum::ALIGN_{LEFT,RIGHT,TOP,BOTTOM} replacing with Gtk::AlignmentEnum::ALIGN_{START,END}. References: https://developer.gnome.org/gtkmm/2.24/group__gtkmmEnums.html#ga98983d4e80f67ffa5148dd554706ffac https://gitlab.gnome.org/GNOME/gtkmm/blob/2.22.0/NEWS#L14 Closes !17 - Gtk2 modernisation 2018-08-10 Luca Bacci modern-gtk2: Use Gtk::TreeView::Column::get_first_cell() (!17) Gtk::TreeView::Column::get_first_cell_renderer() was deprecated in gtkmm 2.24. Replace with Gtk::TreeView::Column::get_first_cell(). References: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1TreeViewColumn.html https://gitlab.gnome.org/GNOME/gtkmm/blob/2.24.0/NEWS#L64 Closes !17 - Gtk2 modernisation 2018-08-10 Luca Bacci modern-gtk2: Use Gtk::ComboBoxText::append() (!17) Gtk::ComboBoxText::append_text() was deprecated in gtkmm 2.24. Replace with Gtk::ComboBoxText::append(). References: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1ComboBoxText.html https://gitlab.gnome.org/GNOME/gtkmm/blob/2.24.0/NEWS#L20 Closes !17 - Gtk2 modernisation 2018-08-27 Luca Bacci modern-gtk2: Always use Gtk::MessageDialog::get_message_area() (!17) Remove check for Gtk::Messagedialog::get_message_area() and associated fallback code as it is always available from gtkmm 2.22. Reference: https://gitlab.gnome.org/GNOME/gtkmm/blob/2.22.0/NEWS#L25 Closes !17 - Gtk2 modernisation 2018-08-26 Luca Bacci modern-gtk2: Require Gtkmm version 2.24 (!17) Require the latest minor version of gtkmm2, released back in 2011 [1]. This is the first step in porting to Gtk3 [2]. This drops GParted support for very old but still supported distributions: Distribution EOL Gtkmm RHEL / CentOS 6 2020-Nov 2.18.2 SLES 11 2022-Mar 2.14.1 References: [1] ANNOUNCE: gtkmm 2.24.0 https://mail.gnome.org/archives/gtkmm-list/2011-February/msg00038.html [2] Migrating from GTK+ 2.x to GTK+ 3 / Preparation in GTK+ 2.x https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3 Closes !17 - Gtk2 modernisation 2018-08-27 Luca Bacci Use Gtk::Viewport wrapper class There is a GtkViewport wrapper class in gtkmm, Gtk::Viewport. Make use of that class instead of direct gtk calls. Reference: https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Viewport.html 2018-07-30 Luca Bacci .gitignore: Do not track compile script Automake 1.14 also now always creates the 'compile' script. http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS?h=v1.14#n110 2018-11-11 Mike Fleetwood Enhance comment about the 3 levels of file system support Add a little extra explaining how the file systems' supported actions are determined. 2018-10-28 Mike Fleetwood Improve translation help for "unformatted" file system type 2018-11-10 Mike Fleetwood Adjust shades of aquamarine, cyan and orange The shades of aquamarine, cyan and orange didn't fit with the GNOME 32-colour palette. Create a set of aquamarine, cyan and orange shades which match the GNOME palette shades and update the colours of the relevant file systems accordingly. Aquamarine Hilight (#97DFC7) - Aquamarine Medium (#70D2B1) - NTFS Aquamarine Dark (#3EA281) - REFS Aquamarine Shadow (#1F7258) - Cyan Hilight (#95E3E5) - EXTENDED Cyan Medium (#6FCECE) - Cyan Dark (#3C9899) - Cyan Shadow (#166F70) - Orange Hilight (#E59F6A) - Orange Medium (#E58749) - BTRFS Orange Dark (#C26825) - ZFS Orange Shadow (#984F18) - Note that the hues of aquamarine and cyan are quite close and for the thin outlines of partitions used in GParted they aren't easy to distinguish. Hence also using different lightness to additionally separate the colour for extended partitions from NTFS and ReFS file systems. 2018-11-07 Mike Fleetwood Recognise APFS (Apple File System) (#23) Just add detection of APFS using GParted's internal magic string detection. It just matches 1 byte of the 2 byte object type and the 4 byte magic field found in the super block [1]. See code comment for more details. Blkid has just gained recognition of APFS with util-linux v2.33 released 06-Nov-2018 [2]. This will write enough for GParted's simple internal detection to find APFS: # python -c ' import sys sys.stdout.write("\0"*24 + "\1\0" + "\0"*6 + "NXSB") ' > /dev/sdb1 [1] Apple File System Reference https://developer.apple.com/support/apple-file-system/Apple-File-System-Reference.pdf [2] [ANNOUNCE] util-linux v2.33 https://marc.info/?l=linux-fsdevel&m=154150400305928&w=2 Closes #23 - GParted doesn't detect APFS (Apple File System) 2018-11-10 Mike Fleetwood Switch HFS and HFS Plus colours to a magenta range (#23) Currently Linux Swap, Linux Suspend, and HFS use reds from the GNOME 32-colour palette with HFS Plus using serene red outside that palette. HFSPLUS - Serene Red HFS - Red Hilight LINUX_SWAP - Red Medium LINUX_SUSPEND - Red Dark - Red Shadow Apple have a new file system, APFS (Apple File System), which is a successor to HFS Plus [1][2]. With HFS Plus using a colour outside the GNOME 32-colour palette and there not being enough distinct reds available for a new file system, create a new range of magenta colours which fit with the GNOME palette and use them for the group of Apple file systems. Magenta Hilight (#D59FD4) - HFS Magenta Medium (#B173B0) - HFSPLUS Magenta Dark (#874986) - APFS Magenta Shadow (#662C64) - This commit just moves HFS and HFS Plus to their new magenta colours. [1] About Apple File System https://developer.apple.com/documentation/foundation/file_system/about_apple_file_system "Overview Apple File System replaces HFS Plus as the default file system for iOS 10.3 and later, and for macOS High Sierra and later. Apple File System offers improved file system fundamentals as well as several new features, including cloning, snapshots, space sharing, fast directory sizing, atomic safe-save, and sparse files. " [2] Apple File System Reference https://developer.apple.com/support/apple-file-system/Apple-File-System-Reference.pdf "About Apple File System Apple File System is the default file format used on Apple platforms. Apple File System is the successor to HFS Plus, so some aspects of its design intentionally follow HFS Plus to enable data migration from HFS Plus to Apple File System. Other aspects of its design address limitations with HFS Plus and enable features such as cloning files, snapshots, encryption, and sharing free space between volumes. " Closes #23 - GParted doesn't detect APFS (Apple File system) 2018-11-02 Daniel Mustieles Updated Spanish translation 2018-11-02 Alan Mortensen Updated Danish translation 2018-10-21 Emin Tufan Çetin Update Turkish translation 2018-10-08 Curtis Gedak Update GParted appdata file (#12) Closes #12 - Appstream metadata needs valid license 2018-10-05 Rafael Fontenelle Update Brazilian Portuguese translation 2018-10-04 Stas Solovey Update Russian translation 2018-09-20 Mike Fleetwood Update GParted appdata file (#12) Update appdata file to be inline with the current AppStream specification [1]. Start by running: appstream-util upgrade gparted.appdata.xml.in and then editing the appdata as wanted. Ensure that the file passes validation: appstream-util validate-relax --nonet gparted.appdata.xml.in When Richard Hughes added the appdata file he licensed it under the GFDL but assigned the copyright to Curtis Gedak [3]. Now change the license to CC0-1.0 [4] as that is what most appdata files are licensed under [5][6]. Curtis Gedak agrees to this by reviewing this change and being the committer of this commit. [1] AppStream specification https://www.freedesktop.org/software/appstream/docs/ [2] Fedora Packaging Guidelines for AppData Files https://fedoraproject.org/wiki/Packaging:AppData [3] 640f92790b7cc5e91f367dfaa01a02a7497afbb4 Add an AppData file (#709164) [4] CC0 1.0 Universal (CC0 1.0) Public Domain Dedication https://creativecommons.org/publicdomain/zero/1.0/ [5] Issue #12 - Appstream metadata needs valid license https://gitlab.gnome.org/GNOME/gparted/issues/12 [6] Merge Request !15, note 331954 - Update GParted appdata file https://gitlab.gnome.org/GNOME/gparted/merge_requests/15#note_331954 Closes #12 - Appstream metadata needs valid license 2018-09-23 Piotr Drąg Update Polish translation 2018-09-22 gogo Update Croatian translation 2018-09-22 Marek Černocký Updated Czech translation 2018-09-21 Bernd Homuth Update German translation 2018-09-19 Mike Fleetwood Disallow resizing btrfs if any of it's mount points are read-only (#10) No other file system allows this, but btrfs allows simultaneous mounting with different read-write permission. Further, btrfs allows resizing via read-write mounts, but not via read-only mounts. # mkfs.btrfs /dev/sdb1 btrfs-progs v4.15.1 ... Filesystem size: 512.00MiB ... Number of devices: 1 Devices: ID SIZE PATH 1 512.00MiB /dev/sdb1 # mount -o ro /dev/sdb1 /mnt/1 # mount -o rw /dev/sdb1 /mnt/2 # grep sdb1 /proc/mounts /dev/sdb1 /mnt/1 btrfs ro,relatime,space_cache,subvolid=5,subvol=/ 0 0 /dev/sdb1 /mnt/2 btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 # btrfs filesystem resize 1:500M /mnt/1 Resize '/mnt/1' of '1:500M' ERROR: unable to resize '/mnt/1': Read-only file system # echo $? 1 # btrfs file system resize 1:500M /mnt/2 Resize '/mnt/2' of '1:500M' # echo $? 0 # btrfs filesystem show /dev/sdb1 Label: none uuid: 74ccd37a-e665-4f25-b77e-a305b8a025e9 Total devices 1 FS bytes used 128.00KiB devid 1 size 500.00MiB used 88.00MiB path /dev/sdb1 Also with the above order of the read-only mount listed in /proc/mounts first and the read-write mount second, GParted again allows a resize operational to be tried, but if fails just like before: Grow /dev/sdb1 from 512.00 MiB to 1.0 GiB (ERROR) * calibrate /dev/sdb1 (SUCCESS) * grow partition from 512.00 MiB to 1.00 GiB (SUCCESS) * grow filesystem to fill the partition (ERROR) * btrfs filesystem resize 1:max '/mnt/1' (ERROR) Resize '/mnt/1 to '1:max' ERROR: unable to resize '/mnt/1': Read-only file system What happened is that the Mount_Info module only stores single read-only flag against the mounted block device, not for each mount point, and as the first and second sdb1 lines from /proc/mounts were processed, the MountEntry became: 1st) mount_info[BS("/dev/sdb1")] -> {true , ["/mnt/1"] 2nd) mount_info[BS("/dev/sdb1")] -> {false, ["/mnt/1", "/mnt/2"] So GParted thought the file system was mounted read-write, but used the first mount point, /mnt/1, which was mounted read-only. This is a very unusual situation so unlikely to be encountered by users. Fix simply and safely by treating the mounted block device as mounted read-only if any of the mount points are mounted read-only, rather than just the last processed mount point. Closes #10 - Gparted fails to resize btrfs partition that is mounted read-only 2018-09-17 Mike Fleetwood Prevent online resizing of file systems mounted read-only (#10) Resizing a file system mounted read-only fails. Example: # mkfs.btrfs /dev/sdb1 # mount -o ro /dev/sdb1 /mnt/1 In GParted try to resize partition sdb1. The operation fails like this: Grow /dev/sdb1 from 512.00 MiB to 1.00 GiB (ERROR) * calibrate /dev/sdb1 (SUCCESS) * grow partition from 512.00 MiB to 1.00 GiB (SUCCESS) * grow filesystem to fill the partition (ERROR) * btrfs filesystem resize 1:max '/mnt/1' (ERROR) Resize '/mnt/1' of '1:max' ERROR: unable to resize '/mnt/1': Read-only file system See GitLab issue for the testing results of attempting to online resize all supporting file system while mounted read-only. No file system allows online resizing while mounted read-only, except for reiserfs. Issue #10 - Gparted fails to resize btrfs partition that is mounted read-only https://gitlab.gnome.org/GNOME/gparted/issues/10 Fix by preventing online resizing of *all* file systems mounted read-only, including reiserfs. Instead of displaying the resize dialog in this case, display an information dialog explaining why the partition can't be resized. This is similar to what happens when attempting to create a new partition on a disk without a partition table. The new dialog looks like: (!) Unable to resize read-only file system /dev/sdb1 The file system can not be resized while it is mounted read-only. Either unmount the file system or remount it read-write. [ OK ] Closes #10 - Gparted fails to resize btrfs partition that is mounted read-only 2018-09-17 Mike Fleetwood Add and set read-only mount flag in the Partition object (#10) Set the partition read-only mount flag at the same time as setting the file system mount points. Closes #10 - Gparted fails to resize btrfs partition that is mounted read-only 2018-09-17 Mike Fleetwood Add parsing of read-only mount option into mount maps (#10) Parse file system mount options string from file and mount command output, extracting the setting for the read-only flag and storing in the mount maps. Read-only flag for swap space gets the struct MountEntry constructor default of false. Closes #10 - Gparted fails to resize btrfs partition that is mounted read-only 2018-09-17 Mike Fleetwood Add read-only flag to mounted file system entries (#10) Just updates the 2 maps in the Mount_Info module so that they also have a read-only flag for each mount. Ensure that when a struct MountEntry is created the readonly bool POD (Plain Old Data) type is initialised by the constructor. Nothing yet sets or uses the flag. Closes #10 - Gparted fails to resize btrfs partition that is mounted read-only 2018-09-19 gogo Update Croatian translation 2018-09-18 Mario Blättermann Update German translation 2018-09-18 Marek Cernocky Updated Czech translation 2018-09-11 Mike Fleetwood White space tidy-up of Utils::get_filesystem_string() Use smart tab alignment, list cases in enumeration order and update translation help for unallocated space. 2018-09-05 Mike Fleetwood Replace open coding FS unknown usage check in prepare_new_partition() Back when unallocated space handling was being added, this case was not converted from open coding to using the provided method to check for unknown file system usage. Specifically this commit missed using Partition::sector_usage_known() in Dialog_Base_Partition::prepare_new_partition(): 7ebedc4bb3b81e85fb4c628a2a05308ada147d68 Don't show intrinsic unallocated space (#499202) Fix it now. 2018-09-10 Mike Fleetwood Refactor get_filesystem_object() The function was using std::map::count() [1] to test if the file system entry existed in the map before looking up the value using std::map::operator[] to avoid having operator[] inserting elements which don't exist [2]. Rewrite using std::map::find() [3] so that map is only searched once, and so that it is more obvious what is happening without having to know the subtleties of std::map::count() and ::operator[]. [1] std::map::count() http://www.cplusplus.com/reference/map/map/count/ "Searches the container for elements with a key equivalent to k and returns the number of matches. Because all elements in a map container are unique, the function can only return 1 (if the element is found) or zero (otherwise). " [2] std::map::operator[] http://www.cplusplus.com/reference/map/map/operator[]/ "If k does not match the key of any element in the container, the function inserts a new element with that key and returns a reference to its mapped value. Notice that this always increases the container size by one, even if no mapped value is assigned to the element (the element is constructed using its default constructor). " [3] std::map::find http://www.cplusplus.com/reference/map/map/find/ "Searches the container for an element with a key equivalent to k and returns an iterator to it if found, otherwise it returns an iterator to map::end. " 2018-09-07 Mike Fleetwood Re-assign UFS to be a basic supported file system (!13) There is no prospect of there being ufs-tools on Linux. The was a project which did release ufs-tools version 0.1 in 2004, but has been inactive since then. http://ufs-linux.sourceforge.net/ Copying and moving is now implemented for file systems in the basic supported category. Also mounting and unmounting of unsupported file system and reporting their usage while mounted has been added. This is all the support that GParted has ever implemented for UFS. Therefore re-assign UFS as a basic supported file system as it looses no functionality. Closes !13 - Support copying and moving of unsupported partition content 2018-09-06 Mike Fleetwood Extend un/mounting and usage reporting to unsupported file systems (!13) For unsupported (including basic supported) file systems, also record the mount point(s) when mounted and from /etc/fstab when not. This allows mounted unsupported file systems to be unmounted and ones with /etc/fstab entries to be mounted, just like fully supported file systems. Also for unsupported (again including basic supported) mounted file systems query the kernel for the usage, just like is already done for supported file systems. Closes !13 - Support copying and moving of unsupported partition content 2018-09-04 Mike Fleetwood Correctly preview unknown FS usage when pasting into an existing partition (!13) When previewing copying a partition of unknown file system usage into an existing partition, the usage still shows that of the overwritten file system. This affects existing supported file systems EXFAT, F2FS, MINIX and UFS and the new basic supported one too, all for which GParted can't read the file system usage. Handle the case of the source file system usage being unknown and explicitly set the copied usage to unknown too. Closes !13 - Support copying and moving of unsupported partition content 2018-09-03 Mike Fleetwood Correctly preview unknown FS usage when pasting into a new partition (!13) GParted previews copying a partition of unknown file system usage into a new partition as 100% used. This affects existing supported file systems EXFAT, F2FS, MINIX and UFS and the new basic supported ones too, all for which GParted can't read the file system usage. When preparing the working new_partition object in the Copy / Paste dialog, the maths for the known file system usage happened to convert the figures of used = -1 and unused = -1 into set_sector_usage(-1, 0). Those values passed to set_sector_usage() mean unable to query the file system size so assume it fills the partition and unused is 0, hence 100% used. Fix this by specifically handling the copying of file systems with unknown usage, setting the pasted file system usage to unknown too, used = -1 and unused = -1. Closes !13 - Support copying and moving of unsupported partition content 2018-09-08 Mike Fleetwood Display "other" in the File System Support dialog (!13) To display the supported actions for all basic supported file systems to the users. Prepare the list of file system actions in Win_GParted because calling get_fs() for the "other" actions requires the gparted_core object and load_filesystems() currently doesn't have access to it. One alternative would have been to make get_fs() and FILESYSTEMS static members of GParted_Core class. Another alternative would have been to pass the gparted_core object to load_filesystems(). The chosen way seemed simplest. Closes !13 - Support copying and moving of unsupported partition content 2018-09-07 Mike Fleetwood Add "other" file system type (!13) Want a single term under which the supported actions for all basic supported file systems are displayed in the File System Support dialog. "Unknown" isn't the correct adjective because the group includes unknown, but also includes: BitLocker, GRUB2 core image, ISO9660, Linux SWRaid, Linux Suspend, REFS and ZFS. Add "other" file system type just for displaying in the dialog. Closes !13 - Support copying and moving of unsupported partition content 2018-09-10 Mike Fleetwood Enable copy and move for basic supported file systems (!13) Add copy and move supported action set for each basic supported file system. Closes !13 - Support copying and moving of unsupported partition content 2018-09-10 Mike Fleetwood Limit FILESYSTEM_MAP entries to supported and basic supported FSs (!13) Introduce a third category of basic file system support to go along with the existing full and none. Use the file system's entry in FILESYSTEM_MAP to determine the level of support. See comment in GParted_Core::init_filesystems() for details. Add and remove FILESYSTEM_MAP NULL pointer entries as required, so that only the file system types intended to have basic support have such entries. Closes !13 - Support copying and moving of unsupported partition content 2018-09-10 Mike Fleetwood Separate unknown file system type from unsupported actions (!13) PATCHSET OVERVIEW: Forum user wanted to be able to move a partition with unknown content: Topic: Can't move/rezise partition on android device (unknown format) http://gparted-forum.surf4.info/viewtopic.php?id=17742 While GParted isn't going to be able to run any sort of file system check on the unknown content there isn't any reason why such a partition can't be copied or moved so long as the partition stays the same size. GParted can just use it's existing internal block copy routine it uses for copying and moving most partition content. This is no different to a few of the already supported file system types which don't have a check-repair tool: exfat, f2fs, nilfs2, udf, ufs. This patchset introduces a third category called basic file system support to go along with the existing full and unsupported categories. Basic supported file systems will just use GParted's inbuilt capabilities to perform actions so they won't need a derived FileSystem implementation class. Unknown file systems along with all other recognised, but otherwise unsupported, file systems will be assigned to this new basic supported category. THIS PATCH: FS_UNKNOWN is used when GParted is unable to identify the contents of a partition. FS_UNKNOWN is also used to generate a file system support set with no supported actions, in the FileSystem::FS::FS() constructor and in GParted_Core::get_fs(). As support for operations on partitions with unknown content is being added, the second usage will be confusing or even wrong. FS( FS_UNKNOWN ) constructs the no supported actions set, yet GParted will support some actions for the FS_UNKNOWN file system type. Therefore add FS_UNSUPPORTED for the second usage. Closes !13 - Support copying and moving of unsupported partition content 2018-09-17 Marek Cernocky Updated Czech help translation 2018-09-07 Alan Mortensen Updated Danish translation 2018-09-07 Marek Cernocky Updated Czech translation 2018-09-05 Anders Jonsson Update Swedish translation 2018-09-04 Efstathios Iosifidis Update Greek translation 2018-09-02 gogo Update Croatian translation 2018-09-01 Rafael Fontenelle Update Brazilian Portuguese translation 2018-09-01 Rafael Fontenelle Update Brazilian Portuguese translation 2018-09-01 Rafael Fontenelle gparted.xml: closed -> closes The Open and Close pages use third person present tense for the "Choose:" paragraph. On the Close instruction, it had "closed" next to a "refreshes". So this commit simply applies present tense to "closed". 2018-08-28 Emin Tufan Çetin Update Turkish translation 2018-08-27 Kukuh Syafaat Update Indonesian translation 2018-08-26 Piotr Drąg Update Polish translation 2018-08-25 Mario Blättermann Update German translation 2018-08-24 Mike Fleetwood White space tidy-up of Utils::get_color() No functional change. The code layout is old and a mess, not lining up vertically. Use more common code layout and spaces to align text vertically. List cases in enumeration order. Identify each colour choice as either in the GNOME palette (no marking), an extended shade to a colour in the GNOME palette [+], or a colour outside the GNOME palette [*]. There's lots of other switch statements just in Utils.cc which could do with tidying up, but this is the one I am looking at now. 2018-08-06 Mike Fleetwood Switch FAT16/32 colours to Accent Greens from the GNOME palette FAT16 was a fully saturated green (RGB #00FF00) and FAT32 was a little darker. These are out of character with the colours from the GNOME palette for other file systems. Change the colours to use near alternative Accent Greens from the GNOME colour palette. So now we have the following file system colours, from light to dark: FAT16 - Accent Green Hilight FAT32 - Accent Green EXFAT - Accent Green Dark UDF - Accent Green Shadow Strictly speaking only Accent Green and Accent Green Dark are part of the GNOME palette. Accent Green Hilight and Accent Green Shadow are extensions expanding the range of Accent Greens. GNOME Human Interface Design 2.2.1 / Visual Design / colour / https://developer.gnome.org/hig-book/2.32/design-color.html.en "Guidelines * Use the GNOME color palette. If you need a darker or lighter shade, start from one of the colors from the palette and darken or lighten as needed. " 2018-08-19 Mike Fleetwood Add support for minix file system (!12) Util-linux package, at least as far back as version 2.23.2 as found on CentOS 7, provides the mkfs.minix and fsck.minix commands. Also blkid from the same package, recognises minix file systems. Create version 3 file systems because MINIX 3 [1] is the only supported version and that reportedly uses version 3 of the file system [2]. [1] MINIX 3 / History https://en.wikipedia.org/wiki/MINIX_3#History [2] Regarding MINIX 3 file system https://groups.google.com/forum/#!topic/minix3/3-TeHR_23X8 "MINIX 3 uses Minix File System (MFS). More precisely MFS V3." Closes !12 - Add minix file system support 2018-08-20 Mike Fleetwood Use one shade darker blue for EXT2/3/4 file systems (!12) I see the MINIX file system as a kind of forerunner to EXT* because of it's history [1]. No body uses the original EXT file system any more, however the MINIX file system is still used by the MINIX 3 operating system. So use the same range of colours for MINIX and EXT2/3/4. Use one shade darker blue for EXT2/3/4, allowing MINIX to use the lightest blue. After adding MINIX support in the next patch, the colours will become: MINIX - Blue Hilight EXT2 - Blue Medium EXT3 - Blue Dark EXT4 - Blue Shadow [1] MINIX file system / History https://en.wikipedia.org/wiki/MINIX_file_system#History "When Linus Torvalds first started writing his Linux operating system kernel (1991), he was working on a machine running MINIX, and adopted its file system layout. This soon proved problematic, since MINIX restricted filename lengths to fourteen characters (thirty in later versions), it limited partitions to 64 megabytes, and the file system was designed for teaching purposes, not performance. The Extended file system (ext; April 1992) was developed to replace MINIX's, but it was only with the second version of this, ext2, that Linux obtained a commercial-grade file system. As of 1994, the MINIX file system was "scarcely in use" among Linux users. " Closes !12 - Add minix file system support 2018-08-24 Mike Fleetwood Update bug links in the UI translation files too (!11) The translations which have been updated for the 0.32.0 release, and since the migration to GitLab hosting, have been updated with the new GitLab issue bug reporting URL. Update all the remaining translation files to match. Closes !11 - Update bugzilla references 2018-08-22 Curtis Gedak Update bug links from Bugzilla to GitLab issues (!11) - Bugzilla has disabled reporting of new bugs. - Existing Bugzilla bug reports permit new comments only. - New bugs are to be created on GitLab issues. Reference: [GitLab] IMPORTANT: Mass migration plan https://mail.gnome.org/archives/desktop-devel-list/2018-March/msg00023.html Closes !11 - Update bugzilla references 2018-08-22 Curtis Gedak Fix broken XML tag in Romanian translation of help manual 2018-08-22 Curtis Gedak Append -git to version for continuing development 2018-08-22 Curtis Gedak ========== gparted-0.32.0 ========== 2018-08-22 A S Alam Update Punjabi translation 2018-08-21 صفا الفليج Update Arabic translation 2018-08-20 Fabio Tomat Add Friulian translation 2018-08-20 Alan Mortensen Updated Danish translation 2018-08-19 Daniel Șerbănescu Update Romanian translation 2018-08-19 Daniel Șerbănescu Update Romanian translation 2018-08-18 Mario Blättermann Update German translation 2018-08-18 Jiri Grönroos Update Finnish translation 2018-08-18 Hannie Dumoleyn Update Dutch translation 2018-08-17 Mario Blättermann Update German translation 2018-08-17 Aurimas Černius Updated Lithuanian translation 2018-08-17 Baurzhan Muftakhidinov Update Kazakh translation 2018-08-17 Trần Ngọc Quân Updated Vietnamese translation Signed-off-by: Trần Ngọc Quân 2018-08-16 Anders Jonsson Update Swedish translation 2018-08-16 Claude Paroz Updated French translation 2018-08-16 Anders Jonsson Update Swedish translation 2018-08-16 Emin Tufan Çetin Update Turkish translation 2018-08-09 Mike Fleetwood Update help manual with opening and closing encrypted partitions (#795617) Bug 795617 - Implement opening and closing of LUKS mappings 2018-08-13 Yi-Jyun Pan Update Chinese (Taiwan) translation 2018-07-28 Mike Fleetwood Update Autoconf macro AX_CXX_COMPILE_STDCXX_11 to latest serial 18 Update to the latest version of the AX_CXX_COMPILE_STDCXX_11 macro from the Autoconf Archive, Note that the macro now depends on AX_CXX_COMPILE_STDCXX so this macro has to be included too. 2018-07-09 Mike Fleetwood Remove unused member Win_GParted::menu_item Usage of menu_item was removed in this commit from 2006. fb672f5219c5cceaae26246fb2c914478b8d2bbd happy new year ;) fixed some alignment issues removed confirmation dialogs 2018-07-09 Mike Fleetwood Remove unused members Win_GParted::label_device_info[12] Usage of members label_device_info1 and label_device_info2 was removed in this commit from 2004. 8ae5ebb2e6d91e2671851e25659e19a90925d65c several (mostly) i18n related fixes/cleanups 2018-07-30 Mike Fleetwood Re-add getting EXT2/3/4 free space from dumpe2fs as a fallback (#8) If an EXT2/3/4 file system needs checking, then resize2fs will report an error, rather than report the minimum file system size. # mkfs.ext4 /dev/sdb11 # resize2fs -P /dev/sdb11 resize2fs 1.42.9 (28-Dec-2013) Estimated minimum size of the filesystem: 17012 # debugfs -w -R "ssv state 0" /dev/sdb11 # resize2fs -P /dev/sdb11 resize2fs 1.42.9 (28-Dec-2013) Please run 'e2fsck -f /dev/sdb11' first. # echo $? 1 This will prevent GParted reading the file system usage and in turn GParted won't allow the file system to be shrunk. Re-add the previous method of reading the free space from dumpe2fs output as a fallback. With this change, the worst case scenario is that GParted allows the user to attempt to shrink an unclean EXT4 file system, smaller that that which resize2fs allows and gets an error telling them so. As part of the failed shrink operation GParted will have checked the file system so on refresh GParted will get the correct minimum size next time. This scenario only seems to apply to unclean EXT4 file systems because resize2fs has a larger minimum size that the free blocks would suggest because of extra space requirements when resizing EXT4 file systems [1]. [1] e2fsprogs 1.44.3, resize/resize2fs.c:calculate_minimum_resize_size() https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/resize/resize2fs.c?h=v1.44.3#n2946 /* * For ext4 we need to allow for up to a flex_bg worth of * inode tables of slack space so the resize operation can be * guaranteed to finish. */ /* * We need to reserve a few extra blocks if extents are * enabled, in case we need to grow the extent tree. The more * we shrink the file system, the more space we need. * * The absolute worst case is every single data block is in * the part of the file system that needs to be evacuated, * with each data block needs to be in its own extent, and * with each inode needing at least one extent block. */ Closes #8 - Shrinking an EXT4 partition does not respect resize2fs limits 2018-07-19 Mike Fleetwood Use resize2fs -P to get minimum EXT2/3/4 FS size (#8) A user reported GParted failed to shrink an EXT4 file system because GParted tried to shrink it smaller than resize2fs reported minimum size. Operation details were: Shrink /dev/sdc1 from 931.51 GiB to 605.00 GiB (ERROR) calibrate /dev/sdc1 (SUCCESS) path: /dev/sdc1 (partition) start: 63 end: 1953520064 size: 1953520002 (931.51 GiB) check file system on /dev/sdc1 for errors and (if poss...(SUCCESS) e2fsck -f -y -v -C 0 '/dev/sdc1' (SUCCESS) ... 158165624 blocks are used (64.77% of 244190000) ... shrink file system (ERROR) resize2fs -p '/dev/sdc1' 634389176K (ERROR) resize2fs 1.44.2 (14-May-2018) resize2fs: New size smaller than minimum (171882113) The GParted figures: * Partition size = 1953520064 (512b sectors) = 976760032 KiB * FS size = 244190000 (4K blocks) = 976760000 KiB * Used FS size = 158165624 (4K blocks) = 632662496 KiB * Requested FS size = 634389176 KiB The resize2fs figure: * Minimum FS size = 171882113 (4K blocks) = 687528452 KiB GParted uses the number of free blocks in the file system to determine the minimum size it can shrink a file system to. However resize2fs uses it's own internally calculated minimum size and won't shrink a file system below that size, as seen in the above details. Resize2fs does have a force flag, (-f) which overrides some safety checks which are normally enforced, to allow it to try to shrink a file system smaller than it's calculated minimum. GParted currently doesn't use the force flag and it seems unwise for it to start to do so. So for unmounted EXT2/3/4 file systems, change GParted to use 'resize2fs -P' to get the minimum file system size, rather than using the number of free blocks direct from the super block, as reported by 'dumpe2fs -h'. Mounted file systems still use statvfs() to provide file system usage. As mounted EXT2/3/4 file systems can't be shrunk the fact that statvfs() produces different, possibly smaller than minimum, figures than those from 'resize2fs -P' doesn't matter. Closes #8 - Shrinking an EXT4 partition does not respect resize2fs limits 2018-07-30 Mike Fleetwood Work in FS blocks until later while reading EXT2/3/4 usage (#8) No functional change. Just work in FS block sized units until as late as possible in ext2::set_used_sectors(), before converting to device sector size units. This is to make the following change simpler and easier to understand. Closes #8 - Shrinking an EXT4 partition does not respect resize2fs limits 2018-07-24 Mike Fleetwood Stop xmllint scrollkeeper-omf.dtd fetch failure breaking CI tests (#9) The GitLab Continuous Integration test stage jobs can fail like this: $ make check ... Making check in help make[1]: Entering directory `/builds/mfleetwo/gparted/help' ... xmllint --noout --xinclude --dtdvalid 'http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd' gparted-C.omf warning: failed to load external entity "http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd" Could not parse DTD http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd xmllint --noout --xinclude --dtdvalid 'http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd' gparted-cs.omf ... make[1]: *** [check-doc-omf] Error 2 make[1]: Leaving directory `/builds/mfleetwo/gparted/help' make: *** [check-recursive] Error 1 ERROR: Job failed: exit code 1 It fails when the scrollkeeper.sourceforge.net site reports that SourceForge is undergoing maintenance or is temporarily unavailable. I have seen this occur on 3 separate occasions in the last 4 weeks since I started experimenting with GitLab CI, which is rather too often. Xmllint comes from the GNOME 2 gnome-doc-utils.make rules used to build and validate GNOME 2 documentation. Fragment of useful Debian bug report 730688: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730688 --disable-scrollkeeper requieres scrollkeeper installed "You can reproduce the problem in mdbtoools version 0.7.1-1 with no network, and rarian-compat not installed. When the network is available, buildd downloads the DTD for checks. When there is no network, gnome-doc-utils fails. " Fix by: (1) adding the rarian-compat package to the CI Docker images, which provides a local copy of the scrollkeeper-omf.dtd file; (2) adding the xmllint --nonet option to prevent fetching of DTDs remotely. With reference to earlier commit: 0eb9f1fcfb2a438ecd85ad7e526f0ec3d01e2da6 Reduce dependency on scrollkeeper (#743318) That commit allowed GParted to be installed on GNOME 3 desktops without requiring rarian-compat package to be installed. This commit adds rarian-compat to the CI images so that 'make check' can succeed without accessing the Internet. Just the intricate path to continue to build and test a GNOME 2 application in a world of GNOME 3 desktops with beginning to be reduced backward compatibility. Closes #9 - CI test jobs occasionally fail with xmllint not loading external entity http://scrollkeeper.sourceforce.net/dtds/ scrollkeeper-omf-1.0/scrollkeeper-omf.dtd 2018-07-06 Mike Fleetwood Stop parallelising make distcheck in GitLab CI test jobs (!6) Unfortunately parallelising 'make distcheck' causes it to fail like this: $ nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1 $ echo nproc=$nproc nproc=8 ... $ make -j $nproc distcheck ... make[1]: Entering directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub' ERROR: files left after uninstall: ./share/icons/hicolor/icon-theme.cache Makefile:896: recipe for target 'distuninstallcheck' failed make[1]: Leaving directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub' make[1]: *** [distuninstallcheck] Error 1 make: *** [distcheck] Error 1 Makefile:840: recipe for target 'distcheck' failed ERROR: Job failed: exit code 1 Therefore go back to serial 'make distcheck'. Closes !6 - Reduce the time taken by the GitLab CI jobs 2018-07-06 Mike Fleetwood Parallelise building GParted in GitLab CI jobs (!6) Reduce the time taken by the GitLab Continuous Integration jobs by parallelising make to use all available CPUs in the Docker CI image when it is building GParted code. This includes 'make diskcheck' because that also does a second build of the GParted code in a separate subdirectory. Closes !6 - Reduce the time taken by the GitLab CI jobs 2018-06-19 Mike Fleetwood Move enum CUSTOM_TEXT into FileSystem.h The CUSTOM_TEXT enumeration is exclusively used as the type of one of the parameters to the functions get_generic_text() and get_custom_text() in the FileSystem class and derived classes. The definition of the enumeration therefore belongs in FileSystem.h. Move it. 2018-06-13 Mike Fleetwood Set FSType when constructing FS in luks::get_filesystem_support() This is functionally identical, but is just to follow established coding pattern [1] of specifying the FSType when constructing struct FS, rather and setting it afterwards. luks.cc was added after the aforementioned commit, but was being developed in parallel so was created [2] following the old coding pattern. [1] 1a4cefb9601de47a1d4fdd31d60be9e37fadda2d Initialise all struct FS members [2] 070d734e57e8c10cfc4264b34e8bd95bba7cf3ff Add busy detection of LUKS mapping (#760080) 2018-07-17 Mike Fleetwood Recognise additional GRUB2 core.img signatures (!5) Bootinfoscript v0.77 (2018-06-10) added additional signatures to recognise GRUB2 core.img by. Commit: https://github.com/arvidjaar/bootinfoscript/commit/9a00c1a8877c9693ef908211f3dfd264c6172986 Add more core.img diskboot signatures Specifically the new signatures are: 5256be63 - trustedgrub2 1.4 5256be56 - diskboot.S with mjg TPM patches (e.g. in openSUSE Tumbleweed) Add those signatures into GParted. Closes !5 - Recognise additional GRUB2 core.img signatures 2018-06-24 Mike Fleetwood Add CI job to test GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-23 Mike Fleetwood Add CI job to build GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-23 Mike Fleetwood Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-22 Mike Fleetwood Rename CI jobs to reflect that they use a CentOS Docker image (!4) Ready for adding additional Continuous Integration jobs using different distribution Docker images. Rename thus: build -> centos_build test -> centos_test Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-22 Mike Fleetwood Exclude unit test which fails in Docker CI image (!4) Fragment of the tests/test-suite.log from the Docker CI image showing details of the unit test failure: Running main() from gtest_main.cc [==========] Running 26 tests from 1 test case. [----------] Global test environment set-up. [----------] 26 tests from BlockSpecialTest ... [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches test_BlockSpecial.cc:137: Failure Failed get_link_name(): Failed to open directory '/dev/disk/by-id' test_BlockSpecial.cc:168: Failure Failed follow_link_name(): Failed to resolve symbolic link '' test_BlockSpecial.cc:255: Failure Expected: (lnk.m_name.c_str()) != (bs.m_name.c_str()), actual: "" vs "" [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms) ... [==========] 26 tests from 1 test case ran. (1 ms total) [ PASSED ] 25 tests. [ FAILED ] 1 test, listed below: [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches 1 FAILED TEST So the code is trying to find a symbolic link to a block device to use in the test. It is trying to read the directory /dev/disk/by-id to find a symbolic link, but the directory doesn't exist in the Docker CI image. The used directory was recently changed [1] to use one which existed on all distributions. Docker images don't even have the /dev/disk directory. Exclude just this specific test. [1] 7fe41480749c795dfb79daeba7b058cece2dfdd2 Use /dev/disk/by-id/ to get device symlink in test_BlockSpecial Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-22 Mike Fleetwood Debug unit test failure in CI test job (!4) Recursively list all the files below /dev as part of the 'test' job as certain block device names are needed by the failing test_BlockSpecial unit test. The artifact captures all the files from the directory in which the CI script runs to build and test GParted. It creates a ZIP file which can be downloaded after the job finishes, whether the job succeeds of fails. This is to capture logs from the failure of the test_BlockSpecial unit test. Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-22 Mike Fleetwood Add CI testing job on CentOS (!4) Add GitLab Continuous Integration job named 'test' which runs the GParted unit tests and distcheck. Note that the job starts from a fresh official CentOS Docker image so also has to rebuild GParted too. So far this job fails on unit test test_BlockSpecial. Fragment of the CI job log: make check-TESTS make[2]: Entering directory `/builds/mfleetwo/gparted/tests' make[3]: Entering directory `/builds/mfleetwo/gparted/tests' PASS: test_dummy FAIL: test_BlockSpecial PASS: test_PasswordRAMStore PASS: test_PipeCapture make[4]: Entering directory `/builds/mfleetwo/gparted/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/builds/mfleetwo/gparted/tests' ============================================================================ Testsuite summary for gparted 0.31.0-git ============================================================================ # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted ============================================================================ Closes !4 - Add GitLab CI jobs to build and test GParted 2018-06-22 Mike Fleetwood Create initial GitLab CI job which builds on CentOS (!4) Initial GitLab Continuous Integration configuration with a single job named 'build' which just confirms GParted can be built and installed on the latest official CentOS Docker image. Closes !4 - Add GitLab CI jobs to build and test GParted 2018-07-02 Jordi Mas Update Catalan translation 2017-10-09 Jordi Mas Fixes to Catalan translation 2018-06-10 Mike Fleetwood Remove support for obsolete devkit-disks automount inhibitor Back in 2009 devicekit-disks package was renamed to udisks [1]. All supported distributions use udisks (or more recently udisks2). None have the old devkit-disks command. Therefore remove it from the GParted shell wrapper. [1] https://www.freedesktop.org/wiki/Software/DeviceKit-disks/ "Note On December 1st 2009, DeviceKit-disks was renamed to udisks. This release is expected to appear in distributions released in the first half of 2010." 2018-06-22 Daniel Mustieles Updated Spanish translation 2018-06-11 Mike Fleetwood Fix LVM2 PV shrinking with lvm2 2.02.171 and later (#1) Shrinking an LVM2 Physical Volume on CentOS 7 with the latest lvm2 2.02.177 fails like this: Shrink /dev/sda9 from 1.00 GiB to 768.00 MiB * calibrate /dev/sda9 * check file system on /dev/sda9 for errors and (if possib...(SUCCESS) * shrink file system (ERROR) * lvm pvresize -v --setphysicalvolumesize 786432K '/dev/...(ERROR) 0 physical volume(s) resized / 1 physical volume(s) not resized Wiping internal VG cache Wiping cache of LVM-capable devices /dev/sda9: Requested size 712.00 MiB is less than real size 1.00 GiB. Proceed? [y/n]:[n] Physical Volume /dev/sda9 not resized. This upstream change to lvm2 [1] makes pvresize prompt for confirmation whenever the --setphysicalvolumesize option is used. (The change was included in lvm2 2.02.171 and later, which is used in recent distributions. The reporter found the issue on Ubuntu 18.04 LTS and I reproduced the issue on RHEL/CentOS 7.5). The set size option has to be used when shrinking the PV before shrinking the partition therefore fix this issue by adding lvm common option --yes when using the set size option. [1] https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=cbc69f8c693edf0d1307c9447e2e66d07a04bfe9 pvresize: Prompt when non-default size supplied. Closes #1 - Can't shrink LVM partition due to pvresize prompt 2018-05-26 Mike Fleetwood Clear previous LUKS unlock failure error before next attempt (#795617) After a failed LUKS unlock attempt the password entry dialog shows the error "Failed to open LUKS encryption". Improve the user experience by clearing that error message at the start of the next attempt to avoid contradictory information with the main windows status of "Opening encryption on $PARTITION" whilst performing the next unlock attempt. Bug 795617 - Implement opening and closing of LUKS mappings 2018-05-25 Mike Fleetwood After LUKS unlock failure select failed password (#795617) When the wrong LUKS password is entered and the [Unlock] button clicked, the wrong password is left in the entry box and focus remains on the [Unlocked] button. Improve the user experience by selecting (highlighting) the whole of the wrong password ready for deletion or retyping and ensuring that the entry box always has focus. Just for completeness also programmatically make the password entry box have focus when the dialog box is created and first displayed, even though it gets this by default. Bug 795617 - Implement opening and closing of LUKS mappings 2018-06-19 Piotr Drąg Avoid unnecessary string change Restore whitespace to previous version, so no translations need to be updated. 2018-05-27 Mike Fleetwood Increment GParted Manual version 2018-05-27 Mike Fleetwood Update SystemRescueCd URL in the GParted Manual http://www.sysresccd.org redirects to http://www.system-rescue-cd.org. Update the GParted Manual to the new address. 2018-05-27 Mike Fleetwood Update URLs in the remaining files to https://gparted.org (#796411) Update URLs in the README file, man page, metadata files and polkit action file. Bug 796411 - Enhancements request - URL links 2018-05-27 Mike Fleetwood Update URLs in the app to https://gparted.org (#796411) We previously migrated our web site from http://gparted.org to https://gparted.org under: bug 786707 - gparted.org does not use HTTPS and updated URLs in the GParted Manual to match in commit: a8172ecb04afabd636e3ad3d6f6665af894516f1 Convert Manual links to HTTPS where possible and update version Now update the URLs displayed in the GParted application too. Bug 796411 - Enhancements request - URL links 2018-05-21 Mike Fleetwood Rework scope of fat16:: and ntfs::Change_UUID_Warning vectors The Change_UUID_Warning vectors were fat16 and ntfs class member variables, but are only ever accessed in the get_custom_text() method. Make them local variables in get_custom_text() instead. Static so that references to them can be returned. 2018-05-19 Mike Fleetwood Move the xfs_db -r flag to the start when reading XFS usage I completely missed that when reading XFS file system size and usage it was using the '-r' read-only flag to xfs_db because it was at the end of the string on the following line of code. Move it to the start of the xfs_db command line, like it is when reading the file system label. 2018-05-16 Mike Fleetwood Simplify from Gtk::Table to HBox in Partition Name dialog Same case as for FileSystem Label dialog before; the Partition Name dialog only has a single line of just 2 widgets. Therefore switch to a simpler horizontal box widget to lay them out. 2018-05-15 Mike Fleetwood Simplify from Gtk::Table to HBox in FileSystem Label dialog The FileSystem Label dialog only has a single line of just 2 widgets; a text label and entry box widget. There is no need to use a multi-line capable table to hold this. Switch to a simpler horizontal box widget. Note that this change is not related to porting to Gtk 3 and stopping using deprecated APIs because both HBox [1] and Table [2] are deprecated in Gtk 3.2 and Gtk 3.4 and replaced by Box with horizontal orientation and Grid respectively. [1] NEWS file from gtkmm 3.2, actually first released in gtkmm 3.1.6 (unstable): https://git.gnome.org/browse/gtkmm/tree/NEWS?h=3.2.0#n91 "Gtk: * All H* or V* specialized classes have been deprecated, to match the deprecations in the GTK+ C API. You should now set the orientation instead. This includes HBox, VBox, HButtonBox, VButtonBox, HPaned, VPaned, HScale, VScale, HSeparator, VSeparator, HScrollbar and VScrollbar." [2] NEWS file from gtkmm 3.4, actually first released in gtkmm 3.3.2 (unstable): https://git.gnome.org/browse/gtkmm/tree/NEWS?h=3.4.0#n162 "* Deprecate Gtk::Table in favour of Gtk::Grid." 2018-01-30 Mike Fleetwood Make get_custom_text() and get_generic_text() return by reference Replace return by value of const strings from FileSystem::get_custom_text() and get_generic_text() because that implies duplication of those strings. Return a reference to constant strings instead. 2018-05-18 Mike Fleetwood Recognise blkid identified BitLocker encrypted partitions (#795127) Future util-linux release after v2.32 will include this commit for blkid to recognise BitLocker encrypted partitions. It is much better than GParted's inbuilt detection. https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=136f89ce5ed8cd159a1c56b5a775dada2363ecd3 libblkid: add BitLocker detection Make GParted also recognise BitLocker encrypted partitions reported by blkid. Bug #795127 - Displayed Name is incorrect for bitlocker encrypted partitions 2018-06-13 Curtis Gedak Add Mike Fleetwood as GParted maintainer 2018-05-25 Mike Fleetwood Add logo.png for automatic GitLab/GitHub project avatar Generated from GParted SVG icon using: rsvg -w 256 -h 256 data/icons/hicolor_apps_scalable_gparted.svg logo.png 2018-05-21 Robert Ancell Fix null pointer check accidentally disabled (#796293) Compiling (with new enough g++) produces this warning: PasswordRAMStore.cc: In member function 'void GParted::PWStore::erase_all()': PasswordRAMStore.cc:177:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if ( protected_mem != NULL ); ^~ PasswordRAMStore.cc:193:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' memset( protected_mem, '\0', ProtectedMemSize ); ^~~~~~ Looks like a stray semicolon... Bug 796293 - Fix null pointer check accidentally disabled 2018-05-06 Piotr Drąg Update Polish translation 2018-05-02 Rafael Fontenelle Update Brazilian Portuguese translation 2018-04-30 Marek Černocký Updated Czech translation 2018-04-23 Mike Fleetwood Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings 2018-03-26 Mike Fleetwood Report LUKS unlock errors into the password dialog (#795617) Reports generic GParted error "Failed to open LUKS encryption" on any failure unlocking the partition. Choosing not to display cryptsetup reported errors because those messages and their translations are not under GParted control. Bug 795617 - Implement opening and closing of LUKS mappings 2018-03-22 Mike Fleetwood Stop copying password into insecure memory when getting entry (#795617) The underlying C coded Gtk Entry widget is careful to zero memory after use, allowing the widget to be safely used for password entry [1]. However the C++ method Gtk::Entry::get_text() just takes the underlying C string from the Gtk Entry widget and copies it when constructing a Glib::ustring for the return value [2]. So directly use the Gtk/C API to get the C string instead. [1] https://git.gnome.org/browse/gtk+/tree/gtk/gtkentrybuffer.c?h=3.22.28#n92 See function trash_area() which zeros memory and its use in gtk_entry_buffer_normal_insert_text(), gtk_entry_buffer_normal_delete_text() and gtk_entry_buffer_finalize(). [2] https://git.gnome.org/browse/gtkmm/tree/gtk/src/entry.hg?h=3.22.2#n104 _WRAP_METHOD(Glib::ustring get_text() const, gtk_entry_get_text) https://git.gnome.org/browse/glibmm/tree/docs/internal/using_gmmproc.txt?h=2.46.1#n53 _WRAP_METHOD(Glib::ustring METHOD const, FUNC) is processed to: Glib::ustring METHOD() const { return Glib::convert_const_gchar_ptr_to_ustring( FUNC(const_cast(gobj()))); } https://git.gnome.org/browse/glibmm/tree/glib/glibmm/utility.h?h=2.46.1#n82 Glib::ustring convert_const_gchar_ptr_to_ustring(const char* str) { return (str) ? Glib::ustring(str) : Glib::ustring(); } So Gtk::Entry::get_text() calls Glib::ustring() constructor which copies the C string to create the Glib::ustring object returned. Bug 795617 - Implement opening and closing of LUKS mappings 2018-02-11 Mike Fleetwood Keep password dialog open until successful unlock or cancellation (#795617) To keep password dialog open, just keep running it in a loop performing LUKS mapping unlock attempts with the entered passphrase until it succeeds or the dialog is cancelled or closed. This is the same model that is already used for the File Support System dialog and how the [Rescan For Supported Actions] button is implemented. Also any error from attempting to open the LUKS mapping is no longer displayed in a separate error dialog or at all. Will add some sort of error reporting into the password entry dialog in a following commit. Creates new method Win_GParted::open_encrypted_partition() which handles the non UI parts of attempting to open an encrypted partition. Running "cryptsetup luksOpen" and updating the stored passphrase as needed. Bug 795617 - Implement opening and closing of LUKS mappings 2017-10-22 Mike Fleetwood Add password entry dialog and attempt LUKS unlock once (#795617) Initial addition of a password entry dialog. Looks like: +------------------------------------------------+ | LUKS Passphrase /dev/sdb1 | +------------------------------------------------+ | Enter LUKS passphrase to open /dev/sdb1 | | Passphrase: [ ] | | | | [ Cancel ] [ Unlock ] | +------------------------------------------------+ A standard Gtk Dialog is used to accept the password once, with any errors displayed in a separate error dialog afterwards. This is poor UI design. A password dialog should remain open for all authentication attempts and only close when successful or the dialog is cancelled or closed. This UI design issue will be improved in following commits. Bug 795617 - Implement opening and closing of LUKS mappings 2017-10-18 Mike Fleetwood Add closing LUKS mappings (#795617) Implement Close Encryption partition menu item. The Open Encryption action is not yet implemented and instead reports an error detailing the open encryption command. A dialog needs to be written to accept the password entry and pass it to the open encryption command. Bug 795617 - Implement opening and closing of LUKS mappings 2016-10-25 Mike Fleetwood Add unimplemented open/close encryption to the partition menu (#795617) Add new item to the partition menu to allow the user to open and close the LUKS mapping. However for now the menu item is always disabled and there is no implementation behind it to actually open or close the LUKS mapping. Fragment of the partition menu is now: ... Format to > ----------------- Open Encryption <- New menu item Mount ----------------- Name Partition ... Has to be two separate menu items to clearly represent to the user that LUKS mappings and file system mounting are two separate busy states. And also in the case of an open but unmounted file system to offer both actions; close encryption and mount file system. The text of the menu item automatically changes similarly to how it does for the Mount/Unmount, Swapon/Swapoff, Activate/Deactivate item depending on the state of the LUKS mapping. For open LUKS mappings it will show "Close Encryption" and for all other cases (closed LUKS mapping or partition is not encrypted) "Open Encryption". Again similar to how the default of "Mount" is shown for unallocated and unknown partitions. Bug 795617 - Implement opening and closing of LUKS mappings 2016-10-25 Mike Fleetwood Rename some Win_GParted members to *toggle_fs_busy* (#795617) In preparation for adding the ability to toggle the encryption busy state (open/close the encryption volume), rename existing members to reflect that they are related to changing the file system state. (Swap and LVM2 Physical Volumes are handled as file systems by GParted). class Win_GParted renaming: MENU_TOGGLE_BUSY -> MENU_TOGGLE_FS_BUSY allow_toggle_busy_state() -> allow_toggle_fs_busy_state() toggle_busy_state() -> toggle_fs_busy_state() check_toggle_busy_allowed() -> check_toggle_fs_busy_allowed() Bug 795617 - Implement opening and closing of LUKS mappings 2017-10-20 Mike Fleetwood Stop using shell when reading jfs file system usage (#795617) Replace echoing "dm" into jfs_debugfs via a shell command to directly writing "dm" to the input of the jfs_debug command. One less use of the shell. Bug 795617 - Implement opening and closing of LUKS mappings 2017-10-20 Mike Fleetwood Add ability for small writes to stdin of child processes (#795617) As discussed in "LUKS password handling, threats and preventative measures" [1] GParted must be able to pass LUKS passphrases to cryptsetup via standard input to avoid having to write passwords to the file system and deal with additional security requirements. Therefore add a way to write input into created child processes. For small amounts of input, writing up to the pipe buffer capacity won't block [2]. This is 64K on versions of Linux in any currently supported distributions. [1] LUKS password handling, threats and preventative measures https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56 GParted must not become a password manage so it must never save LUKS passwords to disk across separate invocations of GParted. ... GParted should avoid writing a temporary file containing the LUKS password as it introduces extra complexity with trying to safely handle and erase file content. Instead GParted must programmatically pass the LUKS password via standard input to the cryptsetup command. [2] pipe(7) manual page: Pipe capacity A pipe has a limited capacity. If the pipe is full, then a write(2) will block or fail, depending on whether the O_NONBLOCK flag is set (see below). ... In Linux versions before 2.6.11, the capacity of a pipe was the same as the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the pipe capacity is 65536 bytes. Bug 795617 - Implement opening and closing of LUKS mappings 2017-11-10 Mike Fleetwood Simplify obtaining address of password memory for unit tests (#795617) Use private access into the PasswordRAMStore class to directly obtain the address of the locked memory, rather than inferring it from the address of the first stored password. This simplifies PasswordRAMStoreTest::SetUpTestCase() and avoids encoding most of the implementation knowledge that the first password will be stored at the start of the protected memory. Bug 795617 - Implement opening and closing of LUKS mappings 2017-11-10 Mike Fleetwood Add unit testing of erasing all passwords (#795617) Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the same method as used in the PasswordRAMStore destructor. Bug 795617 - Implement opening and closing of LUKS mappings 2017-11-08 Mike Fleetwood Split out erasing all passwords into a separate method (#795617) Move zeroing of the locked memory into separate PWStore::erase_all() private method. Then use this in the PWStore destructor. This is so that zeroing of all passwords can be unit tested independently of destructing the singleton PWStore object. Bug 795617 - Implement opening and closing of LUKS mappings 2017-10-09 Mike Fleetwood Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings 2017-10-06 Mike Fleetwood Add PasswordRAMStore module (#795617) Application level requirements for secure password management were set out in "LUKS password handling, threats and preventative measures" [1]. The requirements are: 1) Passwords are stored in RAM and are not allowed to be paged to swap. (However hibernating with GParted still running will write all of RAM to swap). 2) Passwords are wiped from RAM when no longer needed. When each password is no longer needed and when GParted closes. 3) Passwords are referenced by unique key. Recommend using LUKS UUIDs as the unique key. (Each LUKS password should only ever need to be entered once for each execution of GParted. Therefore the passwords can't be stored in any of the existing data structures such as Partitions or LUKS_Info cache because all of these are cleared and reloaded on each device refresh). There seems to be two possible implementation methods: use an existing library to provide secure memory handling, or write our own. Libgcrypt [2] and libsodium [3] cryptographic libraries both provide secure memory handling. (Secure memory is quite simple really, some virtual memory locked into RAM which is zeroed when no longer needed). Linking to an encryption library just to provide secure memory seems like using a sledge hammer to crack a nut. Also because of requirement (3) above a module is needed to "own" the pointers to the passwords in the secure memory. Managing the secure memory ourselves is probably no more code that that needed to interface to libgcrypt. Therefore handle the secure memory ourselves. So far the module is only compiled. It is not used anywhere in GParted. [1] LUKS password handling, threats and preventative measures https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56 [2] libgcrypt general purpose cryptographic library, as used in GNU Privacy Guard https://gnupg.org/related_software/libgcrypt/ [3] libsodium crypto library https://download.libsodium.org/doc/ Bug 795617 - Implement opening and closing of LUKS mappings 2018-03-11 Mike Fleetwood Use /dev/disk/by-id/ to get device symlink in test_BlockSpecial Found that older but still supported distributions Debian 8 and Ubuntu 14.04 LTS don't have directory /dev/disk/by-path/. This is used by the BlockSpecial unit test as a source of a symbolic link to a block special device. This causes the unit test to fail like this: $ cd tests $ ./test_BlockSpecial ... [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches test_BlockSpecial.cc:137: Failure Failed get_link_name(): Failed to open directory '/dev/disk/by-path' test_BlockSpecial.cc:168: Failure Failed follow_link_name(): Failed to resolve symbolic link '' test_BlockSpecial.cc:255: Failure Expected: (lnk.m_name.c_str()) != (bs.m_name.c_str()), actual: "" vs "" [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms) ... [ FAILED ] 1 test, listed below: [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches 1 FAILED TEST Which in turn causes make check and make distcheck to fail. Use directory /dev/disk/by-id/ instead as it always exists. 2018-03-07 Mike Fleetwood Increase minimum required gtkmm to 2.16.0 (#794253) Increase the minimum required version of gtkmm to 2.16.0, thus allowing removal of HAVE_GTK_SHOW_URI autoconf definition and associated fallback code. Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required versions to glibmm 2.14.0 and gtkmm 2.16.0 2018-03-07 Mike Fleetwood Increase minimum required gtkmm to 2.11.1 (#794253) Increase the minimum required version of gtkmm to 2.11.1, thus allowing removal of: * HAVE_SET_DEFAULT_ICON_NAME autoconf definition and associated optional code. * INSTALL_PIXMAPS_DIR automake conditional and associated make instructions. This is reversing these 3 commits, except for the higher minimum gtkmm version: 1) a04210788399736ff7f097cb75650ebcbd0a4950 Only use Gtk::Window::set_default_icon_name method when available (#695279) 2) b09d6035cdca90debb145628b0c62a0213ee1225 Add fallback method for specifying GParted icon (#695279) 3) d6baac254677b7863af413a38f382e9a2e0252bd Only install fallback icon when required (#695279) Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required versions to glibmm 2.14.0 and gtkmm 2.16.0 2018-03-06 Mike Fleetwood Raise minimum required glibmm version to 2.14.0 (#794253) Increase the minimum required version of glibmm to 2.14.0, thus allowing removal of the HAVE_GLIB_REGEX autoconf definition and associated conditional code. This is reversing commit, except for the new glibmm minimum check: 456932846bfbfbd77bbf49165b9eb6c2b84e0da6 Implement fallback if Glib::Regex class is missing (#695279) Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required versions to glibmm 2.14.0 and gtkmm 2.16.0 2018-03-08 Mike Fleetwood Simplify ext2::get_filesystem_support() with regard ext4 support (#794253) E2fsprogs 1.41.0 (from 10 July 2008) first included ext4 support [1]. As RHEL / CentOS 6 is now the oldest supported distribution, and that includes e2fsprogs 1.41.12 (from 22 August 2009) [2] all the e2fs programs support ext4 so it is no longer necessary to also depend on finding mkfs.ext4 before enabling each supported capability for ext4. This makes the ext2::get_filesystem_support() look like all the others in which each supported capability only depends on the presence of the relevant file system specific command. [1] Release notes for the e2fsprogs package / E2fsprogs 1.41.0 http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.41.0 [2] pkgs.org > CentOS 6 > CentOS x86_64 > e2fsprogs https://centos.pkgs.org/6/centos-x86_64/e2fsprogs-1.41.12-23.el6.x86_64.rpm.html Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required versions to glibmm 2.14.0 and gtkmm 2.16.0 2018-03-08 Mike Fleetwood Remove checks for e4fsprogs commands (#794253) PATCHSET OVERVIEW: As of 31 March 2017 RHEL / CentOS 5 reached the end of their support [1][2]. Therefore remove code which supports them. This makes RHEL / CentOS 6 the oldest supported distribution. So the minimum required versions of glibmm and gtkmm can be increased dropping some autoconf checks and conditional code supporting older versions of these libraries. This will undo the bulk of these these previous bug fixes: * GParted 0.21.0 Bug 738706 - Add support for ext4 on RHEL/CentOS 5.x * GParted 0.16.1 Bug 695279 - Fix GParted doesn't compile on RHEL / CentOS 5.9 [1] Red Hat Enterprise Linux Life Cycle https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates [2] Subject: CentOS Linux 5 EOL https://lists.centos.org/pipermail/centos-announce/2017-April/022350.html THIS PATCH: Remove checks for e4fsprogs commands, removing support for ext4 on RHEL / CentOS 5.x. This is reverting earlier commit: f672f68863d36972c5fb28d6592e47ca790708dd Check for e4fsprogs commands for ext4 support on RHEL/CentOS 5.x (#738706) Mkfs_cmd member variable is being kept as a convenience so that it is created once rather than on each use. Also note that as it is a Glib::ustring type object, it's constructor will be called which will initialise it to the empty string so it doesn't need initialising to the empty string in the initialiser list of the ext2() constructor itself. Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required versions to glibmm 2.14.0 and gtkmm 2.16.0 2018-03-19 Andre Klapper Fix broken markup in Romanian user docs translation 2018-03-19 Aurimas Černius Updated Lithuanian translation 2018-03-19 Curtis Gedak Append -git to version for continuing development 2018-03-19 Curtis Gedak ========== gparted-0.31.0 ========== 2018-03-19 Curtis Gedak Update copyright year 2018-03-19 Rūdolfs Mazurs Update Latvian translation 2018-03-18 Milo Casagrande Update Italian translation 2018-03-13 Trần Ngọc Quân Updated Vietnamese translation Signed-off-by: Trần Ngọc Quân 2018-03-12 Claude Paroz Updated French translation 2018-03-11 Anders Jonsson Update Swedish translation 2018-03-10 Alan Mortensen Updated Danish translation 2018-03-10 Mario Blättermann Update German translation 2018-03-04 Balázs Úr Update Hungarian translation 2018-03-03 Baurzhan Muftakhidinov Update Kazakh translation 2018-03-03 Daniel Șerbănescu Update Romanian translation 2018-03-02 GNOME Translation Robot Update Dutch translation 2018-02-24 Piotr Drąg Fix Spanish translation header 2018-02-22 Daniel Mustieles Updated Spanish translation 2018-02-17 Мирослав Николић Updated Serbian translation 2018-02-09 Kukuh Syafaat Update Indonesian translation 2018-02-01 Mike Fleetwood Remove deprecated USE_GNOME2_MACROS from autogen.sh Use of USE_GNOME2_MACROS is deprecated in GNOME 3 and produced this warning: $ ./autogen.sh /usr/bin/gnome-autogen.sh ... ***Warning*** USE_GNOME2_MACROS is deprecated, you may remove it from autogen.sh ... It's use appears to have been removed first from GNOME 2.8 with this commit from 2004: https://git.gnome.org/browse/gnome-common/commit/?id=ea9e85851445efa0135c3f8d08c3d1ea53760d91 delete some files that were unused after the reorganisation The oldest supported distribution is RHEL / CentOS 6 which is using gnome-common-2.28.0 from 2009. Therefore unconditionally remove the USE_GNOME2_MACROS setting. Also confirmed that it makes no difference by running ./autogen.sh with and without USE_GNOME2_MACROS being set. The produced GParted build trees were the same. Therefore the release and executable can't be affected. 2018-01-30 Curtis Gedak Reduce dependency on scrollkeeper (#743318) Scrollkeeper and the associated OMF catalog files are used by the GNOME 2 version of yelp to display the GParted help manual. To see how this works try the following command: yelp ghelp:gparted GNOME version 3 and higher yelp do not require scrollkeeper or the OMF catalog files to properly display the GParted help manual. And in fact GNOME 3 deprecated the GNOME 2 method of building and installing GNOME help documents altogether; including use of GNOME_DOC_INIT autoconf macro, the gnome-doc-utils package and use of scrollkeeper. [GNOME 3] GNOME Goal: Port To New Documentation Infrastructure https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure Further, the next release of Debian, Debian 10 (Buster), will be removing the scrollkeeper / rarian package. rarian: Don't release with Buster https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885657 GParted is still a GNOME 2 app using GNOME 2 documentation build system using autoconf GNOME_DOC_INIT macro. [GNOME 2] Migrating your documentation to gnome-doc-utils https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo This is needed to build GParted documentation on still supported GNOME 2 distributions RHEL / CentOS 6. So avoid requiring deprecated scrollkeeper on GNOME 3 by automatically disabling scrollkeeper database updates when the scrollkeeper-update command is not available. Executable | Configure option used | Use scrollkeeper scrollkeeper-update | on command line | when building help exists? | | for GParted? --------------------+------------------------+------------------- Yes | | Yes Yes | --enable-scrollkeeper | Yes Yes | --disable-scrollkeeper | No | | No | | No Note that because GParted is still using the GNOME 2 documentation build system it still builds and installs OMF files. It is just that they are not required with GNOME 3 yelp and this commit automatically disables updating the scrollkeeper database when the scrollkeeper-update command is not available. Bug 743318 - configure script missing check for scrollkeeper dependency 2018-01-10 Mike Fleetwood Add comment about needing to compute encryption overhead in activate_format() To explain why just using the size of the LUKS header won't always be correct. 2018-01-18 Mike Fleetwood Move struct FS and FS_Limits into FileSystem.h Struct FS and struct FS_Limits are strongly related to the FileSystem class, both being return values from members and associated with storing file system attributes. Move their definitions from Utils.h into FileSystem.h. 2018-01-02 Mike Fleetwood Rename enum FILESYSTEM to FSType There are too many different types of things named "filesystem" in the GParted code with the potential to cause confusion. Namely: std::vector FILESYSTEMS Vector of file system capabilities. class FileSystem Base class interfacing to file system specific executables for querying and modification. enum FILESYSTEM Symbolic constants representing each file system type. Many recent written or re-written functions already used a variable named fstype. Rename enum FILESYSTEM to enum FSType to clearly distinguish it from the other things with very similar names. Only changing the name of the enumeration, not the name of variables of that type too because that is a lot more lines of code and those can be changed when the relevant code is re-written. 2018-01-17 Mike Fleetwood Fix cannot format error dialog which always reported the file system as encrypted Try to format an existing partition with a file system which doesn't fit. The error dialog reporting the partition as too small or too large always claimed the file system was encrypted, whether it was or not. For example trying to format a 128 MiB partition as btrfs produces this error dialog: (-) Cannot format this file system to [Encrypted] btrfs A [Encrypted] btrfs file system requires a partition of at least 256.00 MiB. [ OK ] This commit: 88136c96d7dd8576963c2e62eb2e9c85f5bff026 Extend functions generating encrypted file system string (#774818) just completely missed handling the case for non-encrypted file systems in Utils::get_filesystem_string(). Add the missed code. 2018-01-15 Mike Fleetwood Extract common code into GParted_Core::get_filesystem_limits() (#787204) There are multiple repetitions of the same code getting a FileSystem object, checking for NULL and then calling the file system specific get_filesystem_limits(). Extract that into a common function. GParted_Core::get_filesystem_limits() can't use the file system from the passed Partition object because that is the current file system which will be different from the intended file system for new and format operations. So would look up the wrong derived FileSystem specific object and call the wrong get_filesystem_limits(). Hence still needing fstype as a separate parameter to pass the intended file system. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-17 Mike Fleetwood Set dynamic UDF file system size limits (#787204) UDF file system minimum and maximum size limits are defined in terms of numbers of file system blocks. So when resizing an existing file system compute the byte size limits from the existing UDF file system's block size. Alternatively when creating a new UDF file system use the device's sector size as the multiplier instead. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-16 Mike Fleetwood Pass Partition object to get_filesystem_limits() (#787204) As described in the previous commit, this is so that file system specific implementations can dynamically determine size limits based on Partition object attributes: such as the device sector size and the file system block size. (Assuming set_used_sectors() sets partition.fs_block_size for the type of file system in question). Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-16 Mike Fleetwood Reorder code in Win_GParted::activate_paste() (#787204) Background information about UDF is that when creating a file system it's block size must match the underlying device's sector size. For optical media like CDs and DVDs that is 2K. For hard drives that is usually 512 bytes or 4K. However if a UDF file system has been copied from a device with a different sector size the UDF block size won't match the sector size. Linux will happily mount such UDF file system. Therefore the derived udf::get_filesystem_limits() will need access to the file system block size when determining the size limits of an existing UDF file system being resized and use the device sector size when a new UDF file system is being created. All this can be queried from an appropriate Partition object passed to get_filesystem_limits(). All the calls to get_filesystem_limits() have an appropriate Partition object available already, except in Win_GParted::activate_reformat() when composing a format operation. Or more correctly activate_reformat() constructs temp_ptn, a suitable Partition object, including with fs_block_size member defaulting to -1 indicating not a resize, but not until after the file system size limits had been checked and get_filesystem_limits() called. Therefore reorder the code in activate_paste() so that the file system size limits are checked after the wanted Partition object has been created. No functional change with this commit. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-15 Mike Fleetwood Remove struct FS members .MIN & .MAX (#787204) All the code has been switched to call get_filesystem_limits() and use struct FS_Limits. Remove struct FS members .MIN & .MAX. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-12 Mike Fleetwood Use struct FS_Limits in Win_GParted::activate_format() (#787204) Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-12 Mike Fleetwood Use struct FS_Limits in GParted_Core::create() (#787204) Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-15 Mike Fleetwood Switch to using struct FS_Limits inside Dialog_Partition_New (#787204) Change Dialog_Partition_New to use a fs_limits rather than struct FS and .MIN and .MAX. No passing of struct FS_Limits required. Just use the FILESYSTEMS vector of struct FS to provide the file system type and look up it's size limits each time the selection changes. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-12 Mike Fleetwood Query and pass struct FS_Limits into Dialog_Partition_Resize_Resize_Move (#787204) Refactor Win_GParted::activate_resize() to query the file system size limits using the new get_filesystem_limits() method and pass those limits into the dialog class as struct FS_Limits. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-12 Mike Fleetwood Switch to using struct FS_Limits inside Dialog_Partition_Resize_Move (#787204) Changes the internal code in Dialog_Partition_Resize_Move to use fs_limits instead of fs.MIN and fs.MAX. The limits are still passed into the constructor via struct FS and it's members .MIN and .MAX but immediately used to assign to fs_limits. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-12 Mike Fleetwood Query and pass struct FS_Limits into Dialog_Partition_Copy (#787204) Refactor Win_GParted::activate_paste() to query the file system size limits using the new get_filesystem_limits() method and pass those limits into the the dialog class as struct FS_Limits. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-12 Mike Fleetwood Switch to using struct FS_Limits inside Dialog_Partition_Copy (#787204) Adds working copy fs_limits member into common Dialog_Base_Partition class. Changes the internal code in Dialog_Partition_Copy class to use fs_limits instead of fs.MIN and fs.MAX. The limits are still passed into the constructor via object of struct FS and it's members .MIN and .MAX but immediately used to assign to the fs_limits member. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-11 Mike Fleetwood Assign to duplicate FS_Limits (#787204) Duplicate the assignment of file system size limits into struct FS_Limits, matching the fixed values currently assigned to struct FS members .MIN and .MAX. Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-11 Mike Fleetwood Create separate file system limits structure and getter method (#787204) PATCH SET OVERVIEW: Currently the supported actions of each file system and their size limits are stored in struct FS objects. These are created by calling file system specific derived implementations of FileSystem::get_filesystem_support(). This happens when GParted is started or when a when a rescan for supported actions is performed. The file system size limits are expressed as a fixed number of bytes. The maximum UDF file system size is specified in terms of file system block size units. Also the file system block size must match the sector size of the underlying device. Typically 2K for optical media and 512 bytes or 4K for hard drives. Therefore GParted can't properly express the true UDF file system size limits because they depend on the block size of an existing UDF file system or the sector size of the device for new UDF file systems. In fact other file systems such as EXT2/3/4 and XFS actually express their maximum file system size in terms of numbers of file system blocks but these tend to always be 4K and don't have to match the sector size of the underlying device, so fixed byte values tend to suffice. To update GParted for this, first separate file system size limits from struct FS into struct FS_Limits and provide new FileSystem::get_filesystem_limits() method to allow the limits to be queried independently of the calls to get_filesystem_support(). Second, pass Partition objects and allow derived get_filesystem_limits() implementations. THIS PATCH: Just creates a separate structure storing fixed value file system minimum and maximum size limits along with getter method get_filesystem_limits(). Bug 787204 - Minimum and maximum size of the UDF partition/disk 2018-01-28 Marek Cernocky Updated Czech translation 2018-01-08 Piotr Drąg Update Polish translation 2018-01-06 Rafael Fontenelle Update Brazilian Portuguese translation 2018-01-04 gogo Update Croatian translation 2018-01-02 Pali Rohár Use external tools udfinfo and udflabel for UDF file system (#792052) Those external tools were introduced in version 2.0 of udftools package and can show or change UDF label, UDF uuid and can provide information needed for counting total/free sectors. Bug 792052 - Add support for changing UDF label/uuid and show disk usage 2017-11-30 Mike Fleetwood Rename function and reword text for rollback of failed file system move To better reflect specifically that it is a failed (internally implemented) file system move which is being rolled back. 2017-12-30 Mike Fleetwood Fix rollback when growing a partition by more than twice fails (#791875) Attempt to grow a partition to more than twice it's size. If committing that change to the partition fails in such a way that the new larger partition boundaries are not written to the disk drive then rolling back will fail with libparted error: Can't have overlapping partitions. Example operation details: Grow /dev/sdb8 from 1.00 GiB to 2.20 GiB * calibrate /dev/sdb8 (SUCCESS) * check file system on /dev/sdb8 for errors and (if poss...(SUCCESS) * grow partition from 1.00 GiB to 2.20 GiB (ERROR) * attempt to rollback failed change to the partition (ERROR) original start: 7350272 original end: 9447423 original size: 2097152 (1.00 GiB) * libparted messages (ERROR) Can't have overlapping partitions. What happened is that resize_move_partition() passed the new Partition object to resize_move_partition_implement() as the source partition for the rollback, and than called ped_disk_partition_by_sector() with a sector in the middle to identify the partition to be changed. However the new partition was never written to the drive so in the middle was outside the old smaller partition. Therefore libparted identified empty space after the partition, rather than the partition itself, as the intended target so when ped_disk_set_partition_geom() was called it reported error "Can't have overlapping partitions" because it thought another partition was being created with the same boundaries as the old partition, rather than the boundaries of the old partition being updated. The same error also occurs when rolling back a failed partition change as part of a move operation when the middle of the new partition falls outside of the boundaries of the old partition. Fix by making a temporary Partition object from the intersection of the old and new partition boundaries just to be used to identify the partition being changed to libparted. As this is only rolling back a single step adjusting the partition boundaries as part of a resize and/or move operation, the old and new partition boundaries must intersect (and in fact that intersection contains the file system data). Bug 791875 - Rollback specific failed partition change steps 2017-12-18 Mike Fleetwood Enable failed partition change rollback for selected steps (#791875) The general rule is that: 1) For a partition change step BEFORE a file system change step, rollback on failure; 2) For a partition change step AFTER a file system change step, don't rollback on failure. Examining every case where resize_move_partition() is called and whether rollback on failure is wanted or not: * In resize_move() Resize / move extended partition. No associated file system change. NO ROLLBACK Just to keep possibly applied operation. * #1 in move() Making all encompassing partition before moving file system. ROLLBACK To restore partition boundaries back to those of the file system. * #2 in move() Recreating original partition boundaries after file system move failed or was cancelled and has been rolled back. NO ROLLBACK To keep updated partition boundaries to match restored file system data. * #3 in move() Replacing all encompassing partition with final partition after successful file system move. NO ROLLBACK Keep new partition boundaries to match moved file system. * #1 in resize_encryption() Making the partition larger before growing closed LUKS encrypted data. ROLLBACK Restore partition boundaries back to those of the closed LUKS encrypted data. * #2 in resize_encryption() Shrinking the partition after open LUKS mapping has been shrunk, but before swap is re-created (smaller). NO ROLLBACK Difficult case because the partition shrink is in the middle of a LUKS shrink and a swap shrink (re-create). If swap was actually shrunk like other types of file system, rather than re-created, then the operation sequence would be (1) shrink swap, (2) shrink LUKS encryption, (3) shrink partition. In this hypothetical case and the actual case no rollback is preferred to try to keep the new partition boundaries match the shrunk open LUKS encryption mapping. * #3 in resize_encryption() Grow the partition before growing open LUKS mapping and re-creating swap larger. ROLLBACK Restore partition boundaries back to those of the smaller open LUKS encryption mapping. * #4 in resize_encryption() Shrink the partition after shrinking the file system and open LUKS encryption mapping. NO ROLLBACK Keep new smaller partition boundaries to match shrunk encrypted file system. * #5 in resize_encryption() Grow the partition before growing the open LUKS encryption mapping and file system. ROLLBACK Restore partition boundaries back to those of the not yet grown encrypted file system. * #1 in resize_plain() Resize partition before re-creating swap a different size. ROLLBACK Restore partition boundaries back to those of the not yet resized (re-created) swap space. * #2 in resize_plain() Shrink partition after shrinking the file system. NO ROLLBACK Keep new smaller partition boundaries to match shrunk file system. * #3 in resize_plain() Grow partition before growing the file system. ROLLBACK Restore partition boundaries back to those of the not yet grown file system. Removes the default value from the rollback_on_fail parameter so rollback or not has to be explicitly specified for every call of resize_move_partition(). Bug 791875 - Rollback specific failed partition change steps 2017-12-08 Mike Fleetwood Implement rollback of failed partition resize/move steps (#791875) Even after implementing a fix for bug 790418 "Unable to inform the kernel of the change message may lead to corrupted partition table" GParted/libparted can still encounter errors informing the kernel of the new partition layout. This has been seen with GParted on CentOS 7 with libparted 3.1. In such a case the partition has been successfully written to the disk but just informing the kernel failed. This is a problem because when a partition is being moved in advance of a file system move step, failure to inform the kernel leaves the partition boundaries not matching the on disk limits of the file system. For a move to the left this leaves the partition reported as unknown, apparently losing the user's data. For example start with a 512 MiB partition containing an XFS file system. This is recognised by blkid and parted, hence also by GParted. # blkid /dev/sdb1 /dev/sdb1: UUID=... TYPE="xfs" PARTUUID="37965980-01" # parted /dev/sdb unit s print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 16777216s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1048576s 2097151s 1048576s primary xfs Now move the partition 100 MiB to the left and have it fail to inform the kernel after the first partition change step. Operation details: Move /dev/sdb1 to the left (ERROR) * calibrate /dev/sdb1 (SUCCESS) * check file system on /dev/sdb1 for errors and (if poss...(SUCCESS) * grow partition from 512.00 MiB to 612.00 MiB (ERROR) old start: 1048576 old end: 2097151 old size: 1048576 (512.00 MiB) requested start: 843776 requested end: 2097151 requested size: 1253376 (612.00 MiB) * libparted messages (ERROR) Error informing the kernel about modifications to partition /dev/sdb1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Failed to add partition 1 (resource temporarily unavailable) Now because the start of the partition is 100 MiB before the start of the file system, the file system is no longer recognised, and apparently the user's data has been lost. # blkid /dev/sdb1 /dev/sdb1: PARTUUID="37965980-01" # parted /dev/sdb unit s print ... Number Start End Size Type File system Flags 1 843776s 2097151s 1253376s primary It doesn't matter why updating the partition failed, even if it was because of an error writing to the disk. Rollback of the change to the partition should be attempted. The worst case scenario is that rollback of the change fails, which is the equivalent to how the code worked before this patch set. However in other cases where the partition boundaries are being updated after a file system move or shrink step then the partition should be updated to match the new location of the file system itself. And no rollback is wanted. If the failure was only informing the kernel then in fact the partition has actually been updated on disk after all. So each partition resize/move step needs examining on a case by case basis to decide if rolling back the change to the partition is wanted or not. This patch only adds partition change rollback into resize_move_partition(). Rollback remains disabled until all cases are examined in the following patch. Bug 791875 - Rollback specific failed partition change steps 2017-12-28 Mike Fleetwood Extract common code into update_dmraid_entry() (#791875) Extract common code which updates a DMRaid device mapper entry into a sub-function. This will also be needed when adding rollback of a partition change on failure. Bug 791875 - Rollback specific failed partition change steps 2017-12-08 Mike Fleetwood Extract code into resize_move_partition_implement() (#791875) Extract the code which actually implements the partition change into a sub-function ready for adding rollback of the change on failure. Bug 791875 - Rollback specific failed partition change steps 2017-12-27 Christian Kirbach Update German translation 2017-12-20 Daniel Mustieles Updated Spanish translation 2017-12-08 Mike Fleetwood Match up OperationDetail creation and status setting for internal copy (#790842) This is not required, but it is more logical to have an OperationDetail object created and it's final status set in the same function rather than split between caller and callee. So move creation of "copy %1 using a block size of %2" OperationDetail objects into GParted_Core::copy(). Also introduces a couple of variables to remove some recomputation: benchmark_od & remaining_length. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-12-10 Mike Fleetwood Set OperationDetail status last during internal copy benchmarking (#790842) Performing a copy or move operation which uses GParted's internal copy routine triggered the new GParted bug message. Example operation details: Copy /dev/sdb8 to /dev/sdb (start at 4.51 GiB) (SUCESSS) * calibrate /dev/sdb8 (SUCCESS) * check file system on /dev/sdb8 for errors and (if possib...(SUCCESS) * create empty partition (SUCCESS) * set partition type on /dev/sdb9 (SUCCESS) * copy file system from /dev/sdb8 to /dev/sdb9 (SUCCESS) using internal algorithm copy 1.00 GiB * finding optimal block size * copy 16.00 MiB using a block size of 1.00 MiB (SUCCESS) 16.00 MiB of 16.00 MiB copied GParted Bug: Adding more information to the result...(WARNING) 0.797269 seconds * copy 16.00 MiB using a block size of 2.00 MiB (SUCCESS) * copy 16.00 MiB using a block size of 4.00 MiB (SUCCESS) * copy 16.00 MiB using a block size of 8.00 MiB (SUCCESS) * copy 16.00 MiB using a block size of 16.00 MiB (SUCCESS) optimal block size is 1.00 MiB * copy 944.00 MiB using a block size of 1.00 MiB (SUCCESS) This is because when performing the initial benchmarking copies the time taken by each copy is added to the operation detail results in the calling GParted_Core::copy_blocks() after the final status was set in CopyBlocks::copy() with set_success_and_capture_errors(). Fix by setting the final status in the parent function after adding the time to the benchmark copies. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-12-10 Piotr Drąg Update Polish translation 2017-12-08 gogo Update Croatian translation 2017-12-05 Kukuh Syafaat Update Indonesian translation 2017-12-03 Mike Fleetwood Make OperationDetail no_more_children bug message translatable (#790842) To be consistent with all previous bug messages being translatable. Also only mark the bug as a warning instead of an error because the bug doesn't cause any disk drive operations to fail. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-12-03 Piotr Drąg Update Polish translation 2017-11-28 Mike Fleetwood Wait for the kernel and udev to settle partitions for a second time (#790418) There is still another subtle issue. When GParted_Core::commit() closes the device, the kernel initiates a second set of events which removes and re-adds the partitions again. Need to wait for these to complete to prevent any following step failing with missing partition device nodes. Bug 790418 - "Unable to inform the kernel of the change" message may lead to corrupted partition table 2017-11-27 Mike Fleetwood Avoid libparted failing to inform the kernel about partition changes (#790418) Operations involving modifications to a partition are sometimes failing with a libparted error informing the kernel about modifications to partitions. For example I encountered these errors when just creating a fourth partition on CentOS 7 in a VirtualBox VM. Operation results: Create Primary Partition #1 (ext4, 4.73 GiB) on /dev/sdb (ERROR) * create empty partition (ERROR) * libparted messages (ERROR) * Error informing the kernel about modification to partition /dev/sdb1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. * Failed to add partition 1 (Resource temporarily unavailable) Those two libparted messages were presented in "Libparted Error" dialogs and [Cancel] was selected both times. Libparted Error (-) Error informing the kernel about modifications to partition /dev/sdb1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. [ Cancel ] [ Ignore ] Libparted Error (-) Failed to add partition 1 (Resource temporarily unavailable) [ Retry ] [ Cancel ] This is the edited output showing GParted print debugging, stracing of GParted and monitoring of udev events for this case. # ./gpartedbin /dev/sdb ====================== libparted : 3.1 ====================== ... 24.541604 +23.923435 create_partition() start (new_partition, optdet, min_size=0) new_partition.device_path="/dev/sdb" 24.556101 +0.014497 create_partition() type=PED_PARTITION_NORMAL 24.556354 +0.000253 commit() start (lp_disk) lp_disk->dev->path="/dev/sdb" D: strace pid 18054. Press [Return] to continue. ^Z [1]+ Stopped ./gpartedbin /dev/sdb # udevadm monitor & [2] 18124 monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent # strace -p 18054 -e open,ioctl,write,close & [3] 18129 strace: Process 18054 attached # fg %1 ./gpartedbin /dev/sdb 128.175811 +103.619457 commit() calling ped_disk_commit_to_dev(lp_disk) ... open("/dev/sdb", O_RDWR) = 6 ioctl(6, BLKFLSBUF) = 0 write(6, "\372\270\0\20\216\320\274\0\260\270\0\0\216\330\216\300\373\276\0|\277\0\6\271\0\2\363\244\352!\6\0"..., 512) = 512 ioctl(6, BLKFLSBUF) = 0 close(6) 128.181352 +0.005542 commit() ped_disk_commit_to_dev(lp_disk) returned true 128.181475 +0.000122 commit_to_os() start (lp_disk, timeout=10) lp_disk->dev->path="/dev/sdb" 128.181527 +0.000052 commit_to_os() calling ped_disk_commit_to_os(lp_disk) ... open("/dev/sdb", O_RDWR) = 6 ioctl(6, BLKFLSBUF) = 0 open("/sys/block/sdb/ext_range", O_RDONLY) = 7 close(7) = 0 KERNEL[1158935.380543] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) KERNEL[1158935.380565] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) KERNEL[1158935.380578] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) ioctl(6, BLKPG, {BLKPG_DEL_PARTITION, flags=0, datalen=152, data={start=0, length=0, pno=1, devname="", volname=""}}) = -1 ENXIO (No such device or address) ioctl(6, BLKPG, {BLKPG_DEL_PARTITION, flags=0, datalen=152, data={start=0, length=0, pno=2, devname="", volname=""}}) = -1 ENXIO (No such device or address) ioctl(6, BLKPG, {BLKPG_DEL_PARTITION, flags=0, datalen=152, data={start=0, length=0, pno=3, devname="", volname=""}}) = -1 ENXIO (No such device or address) ... KERNEL[1158935.380977] change /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb (block) KERNEL[1158935.381296] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) KERNEL[1158935.381367] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) KERNEL[1158935.381432] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) KERNEL[1158935.382992] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block) ioctl(6, BLKPG, {BLKPG_DEL_PARTITION, flags=0, datalen=152, data={start=0, length=0, pno=62, devname="", volname=""}}) = -1 ENXIO (No such device or address) ioctl(6, BLKPG, {BLKPG_DEL_PARTITION, flags=0, datalen=152, data={start=0, length=0, pno=63, devname="", volname=""}}) = -1 ENXIO (No such device or address) ioctl(6, BLKPG, {BLKPG_DEL_PARTITION, flags=0, datalen=152, data={start=0, length=0, pno=64, devname="", volname=""}}) = -1 ENXIO (No such device or address) ioctl(6, BLKPG, {BLKPG_ADD_PARTITION, flags=0, datalen=152, data={start=1048576, length=1073741824, pno=1, devname="/dev/sdb1", volname=""}}) = -1 EBUSY (Device or resource busy) write(2, "Error informing the kernel about"..., 251) = 251 Error informing the kernel about modifications to partition /dev/sdb1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. UDEV [1158935.384641] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) UDEV [1158935.390203] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) UDEV [1158935.390243] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) UDEV [1158935.462866] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block) UDEV [1158935.469207] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) UDEV [1158935.471512] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) UDEV [1158935.492173] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) write(2, "Failed to add partition 1 (Resou"..., 60) = 60 Failed to add partition 1 (Resource temporarily unavailable) close(6) KERNEL[1158955.730960] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) KERNEL[1158955.731095] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) KERNEL[1158955.731314] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) KERNEL[1158955.731397] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block) KERNEL[1158955.731817] change /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb (block) KERNEL[1158955.731981] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) KERNEL[1158955.732166] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) KERNEL[1158955.732232] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) KERNEL[1158955.733955] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block) 148.533154 +20.351627 commit_to_os() ped_disk_commit_to_os(lp_disk) returned false UDEV [1158955.738262] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) UDEV [1158955.738460] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) UDEV [1158955.738525] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) 148.537648 +0.004494 execute_command() udevadm settle --timeout=10 UDEV [1158955.740864] remove /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block) UDEV [1158955.760192] change /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb (block) UDEV [1158955.801211] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb4 (block) UDEV [1158955.815262] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb3 (block) UDEV [1158955.815314] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb2 (block) UDEV [1158955.828134] add /devices/pci0000:00/0000:00:0d.0/ata4/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) 148.630797 +0.093149 execute_command() exit status 0 148.630882 +0.000085 commit_to_os() return false D: stop strace pid 18054. Press [Return] to continue. ^Z [1]+ Stopped ./gpartedbin /dev/sdb # kill %3 strace: Process 18054 detached [3]- Done strace -p 18054 -e open,ioctl,write,close # kill %2 [2] Done udevadm monitor # fg %1 ./gpartedbin /dev/sdb 173.700143 +25.069261 commit() return false 173.700470 +0.000327 create_partition() return false What happens is that GParted calls ped_disk_commit_to_dev() which opens the device, writes the updated partition table and closes the device. When the device closes the kernel initiates asynchronous uevents and user space udev rules which remove and re-add all the partitions. In the mean time GParted calls ped_disk_commit_to_os() to inform the kernel of the changes to the partition table. This involves opening the device, using ioctl() to remove all possible partitions [1] and re-add needed partitions. It finds partitions 1 to 3 already removed and accepts this along with all other non-existent partitions up to 64. When it tries to re-add partition 1 the ioctl() BLKPG_ADD_PARTITION call returns EBUSY. Presumably because the partition is in use by udev which is in the process of running the user space rules associated with removing and re-adding it. Then ped_disk_commit_to_os() closes the device which initiates a second round of asynchronous uevents and user space udev rules removing and re-adding all the partitions again. So in summary the kernel and udev are removing and re-adding the partitions exactly when libparted is trying to do exactly the same thing! [1] The algorithm in libparted 3.1 is to try to remove all possible partitions, 64 for this kernel, followed by re-adding the needed partitions. parted/libparted/arch/linux.c:_disk_sync_part_table() http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c?h=v3.1#n2541 Partprobe has had exactly the same issue with failing to inform the kernel about modifications to the partition table [2]. This was fixed in libparted post v3.2 release by this commit [3]. [2] rhbz#1339705 - ceph-disk prepare: Error: partprobe /dev/vdb failed : Error: Error informing the kernel about modifications to partition /dev/vdb1 -- Device or resource busy. https://bugzilla.redhat.com/show_bug.cgi?id=1339705 [3] partprobe: Open the device once for probing Previously there were 3 open/close pairs for the device, which may result in triggering extra udev actions. Instead, open it once at the start of process_dev and close it at the end. http://git.savannah.gnu.org/cgit/parted.git/commit/?id=cfafa4394998a11f871a0f8d172b13314f9062c2 Implement the same fix as implemented for partprobe. Hold a file handle open which libparted can use internally to avoid having to open() and close() the device itself twice, once for each of the calls ped_disk_commit_to_dev() and ped_disk_commit_to_os(). This avoids the first close() initiating the kernel and udev to remove and re-add the partitions exactly when ped_disk_commit_to_os() is trying to do the same thing. Bug 790418 - "Unable to inform the kernel of the change" message may lead to corrupted partition table 2017-10-09 Mike Fleetwood Remove left behind #include "ProgressBar.h" The includes were missed being removed by this earlier refactoring commit which reduced direct access to the single ProgressBar object: b1313281bdaa40a7afc19687a14ac96c919f333c Simplify use of the progress bar via OperationDetail (#760709) 2017-11-25 Mike Fleetwood Rename OperationDetailStatus STATUS_N_A to STATUS_WARNING Make the enumeration name match it's use as indicating a warning. Also spell SUCCESS correctly. Follow on to icon variable names too. 2017-11-26 Mike Fleetwood Identify libparted messages as either success or error (#790842) All libparted messages were reported as informational, even for a step which failed. Instead identify libparted messages as either informational or errors depending on whether this step was successful or not respectively. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-26 Mike Fleetwood Set the status last for the OperationDetails in mk/rm_temp_dir() (#790842) Resizing any unmounted file system which has to be mounted to be resized triggered the new GParted bug message. However the operation did complete successfully. Example operation details: Grow /dev/sdb8 from 1.00 GiB to 1.50 GiB (SUCCESS) * calibrate /dev/sdb * check file system on /dev/sdb8 for errors and (if possib...(SUCCESS) * grow partition from 1.00 GiB to 1.50 GiB (SUCCESS) * grow file system to fill the partition (SUCCESS) * mkdir -v /tmp/gparted-wvH0Ez (SUCCESS) * GParted Bug: Adding another child after no_more_chil...(ERROR) * Created directory /tmp/gparted-wvH0Ez * mount -v -t btrfs '/dev/sdb8' '/tmp/gparted-wvH0Ez' (SUCCESS) * btrfs filesystem resize 1:max '/tmp/gparted-wvH0Ez' (SUCCESS) * umount -v '/tmp/gparted-wvH0Ez' (SUCCESS) * rmdir -v /tmp/gparted-wvH0Ez (SUCCESS) * GParted Bug: Adding another child after no_more_chil...(ERROR) * Removed directory /tmp/gparted-wvH0Ez This is because set_success_and_capture_errors() was called first and the child details added after. Reverse this ordering to fix. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Transition other code to callback error collection (#790842) Transition all remaining code, DMRaid and file system code, to use the new method of reporting success of a step and automatic error collection. None of this code calls libparted so can't generate any libparted exceptions. This is just for consistency so all code follows the same pattern using set_success_and_capture_errors(). Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Refactor ntfs resize code (#790842) Refactor nested if-then-else into a sequence of if fail return early. Makes the code simpler to understand and converts separate OperationDetail::set_status() calls for success or error into a single call using ternary conditional matching how it is or was done everywhere else. This is also ready for status and error capture refactoring. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Transition code using libparted to callback error collection (#790842) Transition GParted block copying code and partition manipulation code, which uses libparted API, to the new method of reporting success of a step and automatic error collection. Libparted exceptions are now reported with the step at which they occurred. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Allow child OperationDetails to emit error capture callback too (#790842) Just copies the callback into each newly added child detail. As there are no more uses of set_success_and_capture_errors() yet, libparted errors are still only captured once at the top-level of each operation. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Capture libparted messages via callback at top-level only (#790842) Replace the explicit adding of libparted exception messages with a callback to do it instead, and fire the callback just once per operation by only changing the very top-level OperationDetail to use the new set_success_and_capture_errors(). Therefore this still produces exactly the same operation details with libparted messages at the end of each operation. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Add mechanism to capture exception messages into an OperationDetail (#790842) All code implementing a step of an operation follows this pattern: od.add_child(OperationDetail("Step heading")); od.get_last_child().add_child(OperationDetail("More details")); // Do step success = ... od.get_last_child().set_status(success ? STATUS_SUCCESS : STATUS_ERROR); At this point any libparted messages reported via exceptions need to be added into the OperationDetail tree. Also adding further children into the tree after collecting those errors needs to be prohibited (as much as the previous patch prohibited it). Add a new method which will replace the final set_status() call above like this which set the status, captures the errors and flags that further children shouldn't be added: ... od.get_last_child().set_success_and_capture_errors(status); It emits a callback to capture the errors to provide flexibility and so that the OperationDetail class doesn't have to get into the details of how GParted_Core saves libparted exception messages. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-25 Mike Fleetwood Add mechanism to stop adding more child OperationDetails (#790842) Want functionality to prevent further child details being added to an OperationDetail. This is so that the captured libparted error messages are always the last child in the list, and more details (at that point in the tree) can't be added. For example we want GParted to report like this: Move /dev/sdb3 to the right and shrink it from 1.14 GiB to...(SUCCESS) ... * shrink partition from 1.14 GiB to 1.00 GiB (SUCCESS) * old start: 4464640 old end: 6856703 old size: 2392064 (1.14 GiB) * new start: 4464640 new end: 6561791 new size: 2097152 (1.00 GiB) * libparted messages (INFO) * DEBUG: GParted generated synthetic libparted excepti... and not like this: Move /dev/sdb3 to the right and shrink it from 1.14 GiB to...(SUCCESS) ... * shrink partition from 1.14 GiB to 1.00 GiB (SUCCESS) * old start: 4464640 old end: 6856703 old size: 2392064 (1.14 GiB) * libparted messages (INFO) * DEBUG: GParted generated synthetic libparted excepti... * new start: 4464640 new end: 6561791 new size: 2097152 (1.00 GiB) So actually preventing the addition of more child details would stop users seeing information they should see. So instead just report a bug message into the operation details. This doesn't stop anything, but the bug message will be seen and allow us to fix GParted. So far nothing is enforced. This patch just adds the mechanism to report a bug when a new child detail is added when prohibited. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-24 Mike Fleetwood Also stop OperationDetail execution timer when setting status to N/A (#790842) PATCH SET SUMMARY: Libparted exception messages are reported into the operation details at the end of each separate operation. For operations which involve multiple steps of partition manipulation there is no way to identify which exceptions occurred with which steps. Example resize/move operation in which multiple libparted exceptions were raised: Move /dev/sdb to the right and shrink it from 1.15 GiB to ...(ERROR) * calibrate /dev/sdb3 (SUCCESS) * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * shrink file system (SUCCESS) * resize2fs -p 'dev/sdb3' 1048576K (SUCCESS) * shrink partition from 1.14 GiB to 1.00 GiB (SUCCESS) * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * grow partition from 1.00 GiB to 1.12 GiB (SUCCESS) * move file system to the right (SUCCESS) * e2image -ra -p -O 134217728 '/dev/sdb3' (SUCCESS) * shrink partition from 1.12 GiB to 1.00 GiB (ERROR) * libparted messages (INFO) * DEBUG: GParted generated synthetic libparted exception... * Error informing the kernel about modifications to part... * Error informing the kernel about modifications to part... * DEBUG: GParted generated synthetic libparted exception... * DEBUG: GParted generated synthetic libparted exception... But there is no way to know which of the libparted steps: 1 calibrate or 3 partition resize steps encountered which exceptions. Fix this by reporting the libparted messages into the operation details at the point at which they occur. Then the above example would become: Move /dev/sdb to the right and shrink it from 1.15 GiB to ...(ERROR) * calibrate /dev/sdb3 (SUCCESS) * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * shrink file system (SUCCESS) * resize2fs -p 'dev/sdb3' 1048576K (SUCCESS) * shrink partition from 1.14 GiB to 1.00 GiB (SUCCESS) * libparted messages (INFO) * DEBUG: GParted generated synthetic libparted excepti... * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * grow partition from 1.00 GiB to 1.12 GiB (SUCCESS) * libparted messages (INFO) * Error informing the kernel about modifications to pa... * Error informing the kernel about modifications to pa... * DEBUG: GParted generated synthetic libparted excepti... * move file system to the right (SUCCESS) * e2image -ra -p -O 134217728 '/dev/sdb3' (SUCCESS) * shrink partition from 1.12 GiB to 1.00 GiB (ERROR) * libparted messages (ERROR) * DEBUG: GParted generated synthetic libparted excepti... THIS PATCH: Small change so that setting the status of an OperationDetail to N/A, warning, also stops the execution timer if it was running. Matching what happens when the status is set to either success or error. This is to avoid having to set status twice, first time just to stop the timer, and second time to set it to the desired status when reporting a warning. Bug 790842 - Report libparted messages into operation details at the point at which they occur 2017-11-11 Ask Hjorth Larsen Updated Danish translation 2017-11-04 Alan Mortensen Updated Danish translation 2017-11-01 Khaled Hosny Update Arabic translation 2017-10-15 Aurimas Černius Updated Lithuanian translation 2017-10-11 Milo Casagrande Update Italian translation 2017-10-10 Curtis Gedak Remove extraneous blank line from NEWS file 2017-10-10 Curtis Gedak Append -git to version for continuing development 2017-10-10 Curtis Gedak ========== gparted-0.30.0 ========== 2017-10-08 Claude Paroz Updated French translation 2017-10-08 Rūdolfs Mazurs Update Latvian translation 2017-10-07 Daniel Șerbănescu Update Romanian translation 2017-10-07 Daniel Șerbănescu Update Romanian translation 2017-10-04 Mario Blättermann Update German translation 2017-10-04 Daniel Mustieles Update Spanish translation 2017-10-04 Daniel Mustieles Update Spanish translation 2017-10-04 Trần Ngọc Quân Updated Vietnamese translation Signed-off-by: Trần Ngọc Quân 2017-10-03 Rafael Fontenelle Update Brazilian Portuguese translation 2017-10-03 Rafael Fontenelle Update Brazilian Portuguese translation 2017-09-26 Mike Fleetwood Extract common code into new method get_lp_partition() 2016-08-20 Mike Fleetwood Calibrate whole disk device partitions again (#788308) Fix up following switch from whole_device flag to TYPE_UNPARTITIONED. Also calibrate the type for whole disk device partitions. Bug 788308 - Remove whole_device partition flag 2016-08-20 Mike Fleetwood Restore Information dialog display of whole disk devices (#788308) So they display as previously; as all grey in the graphic and with only the correct attributes shown. Fix up following switch from whole_device flag to TYPE_UNPARTITIONED. Bug 788308 - Remove whole_device partition flag 2016-08-20 Mike Fleetwood Disallow formatting of unrecognised whole disk devices again (#788308) Fix up following switch from whole_device flag to TYPE_UNPARTITIONED. Bug 788308 - Remove whole_device partition flag 2016-08-20 Mike Fleetwood Allow Partition > New on unallocated whole disk devices again (#788308) Fix up following switch from whole_device flag to TYPE_UNPARTITIONED. Again use FS_UNALLOCATED to determine if a partition represents unallocated space and creation of a new partition should be allowed. This is so that trying to create a new partition on a whole disk device shows the "No partition table found on device /dev/DEV" warning again. Bug 788308 - Remove whole_device partition flag 2016-08-20 Mike Fleetwood Select unallocated whole disk devices again (#788308) After the change from whole_device flag to TYPE_UNPARTITIONED, unallocated whole disk devices are no longer automatically selected because the partition type is no longer TYPE_UNALLOCATED. Fix by checking for file system type FS_UNALLOCATED when identifying the largest unallocated space. Bug 788308 - Remove whole_device partition flag 2016-08-20 Mike Fleetwood Display unrecognised whole disk devices as all grey again (#788308) Following the switch from whole_device flag to TYPE_UNPARTITIONED, unallocated space can be found in two partition types: TYPE_UNALLOCATED TYPE_UNPARTITIONED (only when filesystem == FS_UNALLOCATED) As the file system in both cases is FS_UNALLOCATED check for that when determining whether a partition is unallocated or not. Bug 788308 - Remove whole_device partition flag 2016-08-19 Mike Fleetwood Switch from whole_device flag to TYPE_UNPARTITIONED (#788308) Remove whole_device flag and replace with new partition type TYPE_UNPARTITIONED. Minimally adapt the remaining code to compile and run. Bug 788308 - Remove whole_device partition flag 2016-08-13 Mike Fleetwood Add TYPE_UNPARTITIONED partition type (#788308) Just adds the enumeration. Using it will follow. Bug 788308 - Remove whole_device partition flag 2016-08-19 Mike Fleetwood Update partition related checks in set_valid_operations() (#788308) Update the partition can be named and partition flags can be managed checks from being disallowed on unallocated partition types, to being allowed on primary, logical and extended partition types. This is in preparation for the introduction of new unallocated partition type. Bug 788308 - Remove whole_device partition flag 2016-08-19 Mike Fleetwood Add FILESYSTEM_MAP[FS_EXTENDED] entry Now when refreshing the devices, GParted_Core::read_label() calls GParted_Core::get_fs() with parameter FS_EXTENDED. Before this change, get_fs() would fail to find file system capabilities set for FS_EXTENDED and construct a not supported capabilities set and return that. Afterwards, find_supported_filesystems() creates a not supported capabilities set from the NULL pointer for FS_EXTENDED and adds this entry into the FILESYSTEMS vector. Then get_fs() finds that not supported capabilities set for FS_EXTENDED in the FILESYSTEMS vector and returns that. This makes no functional difference. It just seems right as other unsupported but used file system types have entries in FILESYSTEM_MAP. See this earlier commit doing the same thing: 7870a92b8097b3b8067cc87b891451d5164e9b74 Add FILESYSTEM_MAP[FS_UNALLOCATED] entry 2016-08-19 Mike Fleetwood Remove some unnecessary extended partition checks from GParted_Core (#788308) For example GParted_Core::read_label() is already called for empty partitions where .filesystem = FS_UNKNOWN. In that case get_fs() returns an unsupported capability set with all capabilities set to FS::NONE. The same would be true extended partitions where .filesystem = FS_EXTENDED too; get_fs() would return an unsupported capability set with all capabilities set to FS::NONE. Therefore the if not extended partition condition around the switch statements is not necessary in GParted_Core::read_label(), read_uuid(), label_filesystem() and change_uuid(). Remove. This also achieves removal of some uses of partition type enumerations in advance of the introduction of new partition type TYPE_UNPARTITIONED. Bug 788308 - Remove whole_device partition flag 2016-08-13 Mike Fleetwood Add and use Partition::set_unpartitioned() method (#788308) PATCHSET OVERVIEW: When unpartitioned drive read-write support was added this commit added a whole_device flag: 5098744f9aa958ba18d2a4657ea4345e275c885b Add whole_device flag to the partition object (#743181) Using a whole_device flags now seems not the correct way to model unpartitioned drives. GParted models an uninitialised drive as: .path = _("uninitialized") .type = TYPE_UNALLOCATED .whole_device = true .filesystem = FS_UNALLOCATED and a whole drive file system, using ext4 for example, as: .path = "/dev/sdb" .type = TYPE_PRIMARY .whole_device = true .filesystem = FS_EXT4 No partitioning changed yet the type of the partition in the model changed between TYPE_UNALLOCATED and TYPE_PRIMARY depending on whether the whole drive contains a recognised file system or not. The partition object describing a file system within a LUKS encryption mapping is another case of the model not matching reality. .path = /dev/mapper/crypt_sdb1_crypt .type = TYPE_PRIMARY .whole_device = true .filesystem = FS_EXT4 There is no partition table within the encryption mapping, the file system fills it, but GParted records it as a primary partition. Make TYPE_UNALLOCATED and TYPE_PRIMARY be reserved for representing unallocated space and primary partitions within a partitioned disk drive and introduce new TYPE_UNPARTITIONED for all cases of an unpartitioned whole disk drive. The GParted UI does differentiate between an unallocated whole disk device and anything else by requiring a partition table to be created first, even if that is just the loop partition table. That determination can simply look for the partition object containing file system type FS_UNALLOCATED instead. THIS PATCH: Create set_unpartitioned() helper method to set a partition object to represent a whole disk drive and use everywhere such an object is modelled. This matches what existing methods Set_Unallocated() and indeed Set() do for unallocated space and any type of partition respectively. For now the partition type is still set to either TYPE_UNALLOCATED or TYPE_PRIMARY so the rest of the code base remains the same. TYPE_UNPARTITIONED will be introduced later. Bug 788308 - Remove whole_device partition flag 2017-10-02 Mario Blättermann Update German translation 2017-09-30 Dušan Kazik Update Slovak translation 2017-09-28 Anders Jonsson Update Swedish translation 2017-09-25 Marek Cernocky Updated Czech translation 2017-09-25 Curtis Gedak Convert Manual links to HTTPS where possible and update version 2017-09-16 Mike Fleetwood Describe Create New Partition / Partition name field in the Manual Missed when adding partition naming at creation time in enhancement: Bug 746214 - Partition naming enhancements starting with this commit: f804bc3244c1ee4509fe02b66990709566b69d08 Allow partition naming on busy partitions (#746214) 2017-09-19 Mike Fleetwood Pass string literals directly to execute_command() There were a few cases of creating a local string variable from a literal and then passing the variable to execute_command() like this: Glib::ustring cmd = "whatever"; Utils::execute_command( cmd, ... ); This creates an unnecessary local variable. Instead pass the string literal directly to Utils::execute_command() like this: Utils::execute_command( "whatever", ... ); This also make the code a little bit more grep friendly. 2017-09-21 Mike Fleetwood Stop nicing external commands run by the DMRaid module (#788007) No other commands run by GParted are niced, so stop nicing commands run from the DMRaid module. I think nicing of possibly long running file system modification commands would have made virtually no difference because "nice -n 19" lowered the CPU priority, but such command would be I/O bound. History: Nicing of file system modification commands was added by this commit from 2006-08-21: 82e6f6b132fd7960950a71a2af2db6ef93fde583 added nice -n 19, so that all extensive filesystem operations will be Nicing of DMRaid operations was copied into the DMRaid module when it was added here in 2009-03-14: 5865c92dc054dc87739e6a70b21f91825f214c9e Added new class for dmraid support Nicing was removed from file system modification commands with this commit from 2013-02-22: 52a2a9b00a32996921ace055e71d0e09fb33c5fe Reduce threading (#685740) Bug 788007 - Remove minor bits of legacy from DMRaid module 2017-09-21 Mike Fleetwood Remove backward compatibility for dmraid without -P option (#788007) The -P option was first added to dmraid-1.0.0.rc15 released 2006-09-17 [1]. dmraid-1.0.0.rc16 (a later release) was included in Debian 6 and Ubunbu 12.04 LTS. dmraid-1.0.0.rc13 was included in RedHat/CentOS 5 however the -P option was back ported into RedHat/CentOS 5.1. All of these distributions are so old as to be no longer supported and yet they provided the dmraid -P option. Therefore backward compatibility for dmraid without the -P option is no longer required. So remove it. [1] old dmraid source code releases http://people.redhat.com/heinzm/sw/dmraid/src/old/ Bug 788007 - Remove minor bits of legacy from DMRaid module 2017-09-25 Andre Klapper Fix typo in Romanian user docs translation 2017-09-25 Andre Klapper Fix typo in pt_BR user docs translation 2017-09-03 Pali Rohár Correctly quote and escape arguments passed to external commands (#787203) Trying to set a file system label to (including the double quotes): " --help " fails. For example labelling an ext4 file system would try to run this command: # e2label /dev/sdb1 "" --help "" Usage: e2label device [newlabel] # echo $? 1 Alternatively trying to create a file system with a label of just a double quote also fails. The Applying Pending Operations dialog waits forever and won't cancel or force cancel. Have to use the window manager close window button to close the dialog. Also GParted reports this error to the console: (gpartedbin:9648): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: g-shell-error-quark code : 0 what : Text ended before matching quote was found for ". (The text was 'mkfs.xfs -f -L """ /dev/sdb2') Command strings are parsed and split into argv array by function Glib::shell_parse_argv() which calls internal glib function tokenize_command_line() for shell tokenization. It expects the command string to be properly quoted and escaped and after tokenization, calls g_shell_unquote() on every parsed argument. So to prevent constructing incorrect commands, every non-static string needs to be properly quoted. GParted only puts labels and mount points into double quotes, but has not escaped special characters in those values itself. This patch fixes all these problems by using Glib::shell_quote() on all variable values. Labels, mount points, paths and all others too. Probably a better solution would be to use a new function which takes argv array instead of one string with all the, correctly quoted and escaped, arguments concatenated together. Bug 787203 - Correctly quote and escape arguments of external programs passed to execute_command() 2017-09-03 Pali Rohár Correctly quote and escape command line argument passed to "sh -c" (#787203) Shell fragments must be properly quoted and escaped to prevent execution of unintended commands derived from user controllable data. For example: $ printf '#!/bin/sh\necho test > out\n' > script.sh $ chmod +x script.sh $ truncate -s 20M 'jfs;script.sh' $ mkfs.jfs -q 'jfs;script.sh' $ ls -l out ls: cannot access out: No such file or directory $ sudo PATH=$PWD:$PATH /usr/local/bin/gparted 'jfs;script.sh' $ sudo PATH=$PWD:$PATH /usr/local/bin/gparted 'jfs;script.sh' $ ls -l out -rw-r--r-- 1 root root 5 Sep 12 23:11 out $ cat out test What is happening is that jfs::set_used_sectors() is using the device name 'jfs;script.sh' without quoting it and passing it to the shell to execute like this: sh -c 'echo dm | jfs_debugfs jfs;script.sh' which the shell duly executes as these two commands: echo dm | jfs_debugfs jfs script.sh This could be a security related issue as "sh -c" is able to execute arbitrary shell commands from the argument if if contains shell special characters. Use Glib::shell_quote() [1] to quote and escape file names and whole commands passed to the shell. [1] Glib::shell_quote(const std::string & unquoted_string) https://developer.gnome.org/glibmm/stable/group__ShellUtils.html "Quotes a string so that the shell (/bin/sh) will interpret the quoted string to mean unquoted_string. If you pass a filename to the shell, for example, you should first quote it with this function." Bug 787203 - Correctly quote and escape arguments of external programs passed to execute_command() 2017-09-02 Pali Rohár Make sure that FS_Info cache is loaded for all named paths (#787181) Naming a file system image file on the command line is shown by GParted as unknown. $ truncate -s 100M /tmp/fat.img $ mkfs.vfat /tmp/fat.img $ sudo ./gpartedbin /tmp/fat.img Currently the FS_Info cache is loaded for all devices reported by blkid (plus all whole disk devices identified from /proc/partitions even if blkid reports nothing). However file system images named on the command line are not queried so GParted can't identify them. Fix by ensuring that the FS_Info blkid cache is loaded for all named devices, including named file system image files. Note that Mount_Info::load_cache() depends on the contents of the FS_Info cache to lookup UUID= and LABEL= device names from /etc/fstab. However only file systems in block devices can be mounted like this, and never file system image files, so the fact that the cache may be extended afterwards by FS_Info::load_cache_for_paths() does not matter. History Prior to version 0.22.0, when unpartitioned drive support was added, GParted could recognise some file system image files using loop partition handling in libparted. However libparted before version 3.2 reported the loop partition name as the whole disk device name appended with "1" so all the query commands were provided a non-existent name to use. Therefore no file system usage or the label was displayed. Bug 787181 - Fix detection of file system images 2017-09-10 Anders Jonsson Update Swedish translation 2017-09-09 Daniel Șerbănescu Update Romanian translation 2017-09-07 gogo Update Croatian translation 2017-09-03 Pali Rohár Update list of prohibited fat label characters (#787202) Add double quote (") to the list of prohibited FAT label characters, previously missed [1][2]. Also add single quote (') because mlabel encoded it in a way that both Windows and blkid don't understand, although mlabel can correctly decode it itself. # export MTOOLS_SKIP_CHECK=1 # mlabel ::"MIKE'S" -i /dev/sdf1 # mlabel -s :: -i /dev/sdf1 Volume label is MIKE'S (abbr=MIKE_S~1???) # blkid -o value -s LABEL /dev/sdf1 MIKE_S~1??? (8-bit characters in the above output have been replaced with question marks (?) just to keep this commit message as 7-bit ASCII). Finally exclude ASCII control characters below SPACE (0x00 to 0x1F) as they also cause mlabel to ask a question and wait for input in the same way that prohibited characters do. As discussed in the previous commit [1] the only way to stop GParted waiting forever is to manually kill mlabel with signal 9 (KILL). # mlabel ::"^A" -i /dev/sdf1 Long file name "^A" contains illegal character(s). a)utorename A)utorename-all r)ename R)ename-all s)kip S)kip-all q)uit (aArRsSq): [1] 584137b32b4deed2c20022628baaee6b38570fa5 Remove prohibited characters from FAT16/32 labels (#755608) [2] Microsoft TechNet: Label https://technet.microsoft.com/en-us/library/bb490925.aspx Bug 787202 - Update list of prohibited fat label characters 2017-09-05 Balázs Úr Update Hungarian translation 2017-09-04 Marek Cernocky Updated Czech translation 2017-09-03 Piotr Drąg Update Polish translation 2017-08-28 Mike Fleetwood Support /etc/fstab using Unicode labels as mount points (#786502) So far GParted is still loading the default non-reversible encoded labels from blkid in the initial loading of the FS_Info module cache. This encoded label is used to match LABEL=