On most systems where we compile e2fsprogs, the u64 type is an unsigned long long. However, there are platforms (such as the PowerPC) where a long 64-bits and so u64 is typedef'ed to be unsigned long instead of a unsigned long long. Fix this by using explicit casts in printf statements. For scanf calls, we need to receive the value into a unsigned long long, and then assign it to a u64, after doing range checks. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If directories grow larger than 4GB in size with the large_dir
feature, e2fsck will consider them to be corrupted and clear
the high bits of the size.
Since it isn't very common to have directories this large, and
unlike sparse files that don't have ill effects if the size is
too large, an too-large directory will have all of the sparse
blocks filled in by e2fsck, so huge directories should still
be viewed with suspicion. Check for consistency between two of
the three among block count, inode size, and superblock large_dir
flag before deciding whether the directory inode should be fixed
or cleared, or if large_dir should be set in the superblock.
Update the f_recnect_bad test case to match new output.
Fixes: 49f28a06b738 ("e2fsck: allow to check >2GB sized directory")
Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
Lustre-bug-id: https://jira.whamcloud.com/browse/LU-14345
Change-Id: I1b898cdab95d239ba1a7b37eb96255acadce7057
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Adds support for EXT2_HASH_SIPHASH, and reading the hash from disk in
that case. We cannot compute the siphash without the key, so we must
not modify the names of any encrypted and casefolded directories,
which limits some recovery options, and we must assume the hashes
stored in dirents are correct.
This is in preparation for upcoming kernel support for encryption and
casefolding at the same time.
Google-Bug-Id: 138322712
Test: Create fs with casefold and encryption enabled via mke2fs and
tune2fs, run fsck after creating casefolded + encrypted folder
Change-Id: Icca32d7d9dd3c7f52da03d60e4d89273cbec0a7d
From AOSP commit: 67eae926bdac1a54dbb8335731c5e1581f93e4bb
We can't mutate a name without the key, as this will at best cause the
name to become gibberish, and at worst may introduce invalid characters
or even fail to be unique after decoding, so drop duplicates instead.
Files lost in this way will be reconnected to lost+found
Fixes: dbff534ec685 ("e2fsck: suppress bad name checks for encrypted directories")
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Google-Bug-Id: 138322712
Test: f_dup_de_crypt
Change-Id: I8d6cc3984872868a845fafabc554abdd86351fcc
From AOSP commit: 80b85f8a0b2ba7090a927f692ff9d2097ffd8d1f
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When directory link count is set to overflow value (1) but during pass 4 we find out the exact link count would fit, we either silently fix this (which is not great because e2fsck then reports the fs was modified but output doesn't indicate why in any way), or we report that link count is wrong and ask whether we should fix it (in case -n option was specified). The second case is even more misleading because it suggests non-trivial fs corruption which then gets silently fixed on the next run. Similarly to how we fix up other non-problems, just create a new error message for the case directory link count is not overflown anymore and always report it to clarify what is going on. Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> (cherry picked from commit 4ebce13292f54c96f43dcb1bd1d5b8df5dc8749d)
When directory link count is set to overflow value (1) but during pass 4 we find out the exact link count would fit, we either silently fix this (which is not great because e2fsck then reports the fs was modified but output doesn't indicate why in any way), or we report that link count is wrong and ask whether we should fix it (in case -n option was specified). The second case is even more misleading because it suggests non-trivial fs corruption which then gets silently fixed on the next run. Similarly to how we fix up other non-problems, just create a new error message for the case directory link count is not overflown anymore and always report it to clarify what is going on. Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
By design, the kernel enforces that all files in an encrypted directory use the same encryption policy as the directory. It's not possible to violate this constraint using syscalls. Lookups of files that violate this constraint also fail, in case the disk was manipulated. But this constraint can also be violated by accidental filesystem corruption. E.g., a power cut when using ext4 without a journal might leave new files without the encryption bit and/or xattr. Thus, it's important that e2fsck correct this condition. Therefore, this patch makes the following changes to e2fsck: - During pass 1 (inode table scan), create a map from inode number to encryption policy for all encrypted inodes. But it's optimized so that the full xattrs aren't saved but rather only 32-bit "policy IDs", since usually many inodes share the same encryption policy. Also, if an encryption xattr is missing, offer to clear the encrypt flag. If an encryption xattr is clearly corrupt, offer to clear the inode. - During pass 2 (directory structure check), use the map to verify that all regular files, directories, and symlinks in encrypted directories use the directory's encryption policy. Offer to clear any directory entries for which this isn't the case. Add a new test "f_bad_encryption" to test the new behavior. Due to the new checks, it was also necessary to update the existing test "f_short_encrypted_dirent" to add an encryption xattr to the test file, since it was missing one before, which is now considered invalid. Google-Bug-Id: 135138675 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca>