Test that e2fsck doesn't report errors when an inode with the 'verity'
flag has blocks past i_size.
This is a regression test for commits 3baafde6a8 ("e2fsck: allow
verity files to have initialized blocks past i_size") and 43466d0396
("e2fsck: handle verity files in scan_extent_node()").
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In some cases if the translation file is missing some translations,
mke2fs can end up printing an English message, e.g.:
% LANG=it_IT.UTF-8 ./mke2fs /tmp/foo.img 8M
mke2fs 1.45.1 (12-May-2019)
/tmp/foo.img contiene un file system ext4
created on Mon May 27 19:35:48 2019
Proceed anyway? (y,N)
However, if there is a translation for string to match with "yY"
(e.g., to "sS" for Italian), then 'y' won't work. Fix this by falling
back to the english 'yY' characters.
Addresses-Debian-Bug: #907034
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Don't report PR_1_EXTENT_END_OUT_OF_BOUNDS on verity files during
scan_extent_node(), since they will have blocks stored past i_size.
This was missed during the earlier fix because this check only triggers
if the inode has enough extents to need at least one extent index node.
This bug is causing one of the fs-verity xfstests to fail with the
reworked fs-verity patchset.
Fixes: 3baafde6a8 ("e2fsck: allow verity files to have initialized blocks past i_size")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Running lsblk when there are no valid block devicse results in
generating all block devices as the list of devices to scrub; this
results in a lot of e2scrub_all failures.
Addresses-Debian-Bug: #929186
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In scrub/Makefile the various 'install-*' targets do not explicitly
depend on their corresponding 'installdirs-*' target, so they get run
in parallel.
Addresses-Gentoo-Bug: #680030
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add the ability to save a log of problems found by e2fsck in a log
file that can be specified via /etc/e2fsck.conf.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The check in mke2fs is intended to be for the number of blocks in the
filesystem exceeding the maximum number of addressable blocks in 2^32
bitmaps, which is (2^32 * 8 bits/byte * blocksize) = 2^47 blocks,
or 2^59 bytes = 512PiB for the common 4KiB blocksize.
However, s_log_blocksize holds log2(blocksize_in_kb), so the current
calculation is a factor of 2^10 too small. This caused mke2fs to fail
while trying to format a 900TB filesystem.
Fixes: 101ef2e93c ("mke2fs: Avoid crashes / infinite loops for absurdly large devices")
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently, e2fsck effectively checks only tail of the last inode and
block bitmap in the filesystem. Thus if some previous bitmap has unset
bits it goes unnoticed. Mostly these tail bits in the bitmap are
ignored; however, if blocks_per_group are smaller than 8*blocksize,
the multi-block allocator in the kernel can get confused when the tail
bits are unset and return bogus free extent.
Add support to libext2fs to check these bitmap tails when loading
bitmaps (as that's about the only place which has access to the bitmap
tail bits) and make e2fsck use this functionality to detect buggy bitmap
tails and fix them (by rewriting the bitmaps).
Reported-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Callers of libext2fs don't need to use this structure, and this gives
us the ability to change it later on without worrying about
changing public ABI's.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Also change mke2fs so that the encoding and encoding flags are
specified in mke2fs.conf in the fs_types and defaults stanzas instead
of the options stanza.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Merge nls_utf8-norm.c and nls_utf8.c. This also allows us to comment
out functions which we don't actually need for e2fsprogs.
Also fix some gcc -Wall complaints, including one which would have
caused utf8_casefold() to misbehave (this was fixed in the kernel, but
not carried back to e2fsprogs).
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Also remove nls.h, and avoid declaring static functions and variables
in a header file, which is wasteful of space.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In ext2fs_write_inode2(), the 'old_flags' variable is never used.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In parse_inode_csum(), the outer 'tmp_inode' variable is never used.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In ext2fs_dirhash2(), the outer 'buff' variable is never used.
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fix the following bugs:
1. 'encoding' and 'hash_flags' are not initialized, causing a segfault.
2. 'hash_flags' incorrectly uses a __bitwise type.
3. The optstring doesn't contain "c" or "e", so the -c and -e options
aren't recognized.
4. The code that handles the -e option always returns.
Fixes: ef733f1a97 ("debugfs: support encoding when printing the file hash")
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The way debugfs escapes filenames is ambiguous because a sequence like
M-A can mean either the byte 'A' + 128 == 0xc1 or the three bytes
{'M', '-', 'A'}. Similarly, ^A can mean either the byte
'A' ^ 0x40 == 0x01 or the two bytes {'^', 'A'}.
Fix this and simplify the code by switching to a simpler strategy where
all bytes < 32, all bytes >= 127, and backslash are encoded with C-style
hex escape sequences. E.g., the byte 0xc1 will now be encoded as \xc1
rather than M-A as it was before, while a filename consisting of the
three bytes {'M', '-', 'A'} will continue to be shown as M-A.
I want to fix this mainly because I want to use debugfs to retrieve raw
encrypted filenames for ciphertext verification tests. But this doesn't
work if the returned filenames are ambiguous.
Fixes: 68a1de3df3 ("debugfs: pretty print encrypted filenames in the ls command")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Document the fact that the encoding support is only used by directories
with the +F attribute.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
As agreed on the kernel side, ext4 will only support utf8 for now, and
not plain ASCII, so we don't need this anymore.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
As agreed on the new design, even if fname_encoding is enabled,
directories entries who aren't owned by a +F directory will not be
normalized.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Since we didn't release a kernel version that supports version 11.0.0,
it should be safe to reuse the sb entry for version 12.1.0.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>