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
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
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".
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.
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.
"
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
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
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
- 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.htmlCloses!11 - Update bugzilla references
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.
Usage of members label_device_info1 and label_device_info2 was removed
in this commit from 2004.
8ae5ebb2e6
several (mostly) i18n related fixes/cleanups
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
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
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
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:
0eb9f1fcfb
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
Mike Fleetwood