Since coreutils upstream v8.32~47
commit a99ab266110795ed94a9cb4d2765ddad9c4310da
Author: Jeff Layton <jlayton@kernel.org>
Date: Thu Sep 19 11:59:45 2019 -0400
ls: use statx instead of stat when available
stat(1) starts to use statx(2) call.
In some testcase, if file does not exist, this breaks golden
output like this:
-stat: cannot stat 'SCRATCH_MNT/xxx': No such file or directory
+stat: cannot statx 'SCRATCH_MNT/xxx': No such file or directory
Add this filter to fix it, and add this filter to testcases that
need it.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/397 contains workarounds to allow for kernel bugs where trying
to open or create files in an encrypted directory without the encryption
key failed with ENOENT, EACCES, or EPERM instead of the expected ENOKEY.
However, all these bugs have been fixed. ext4 and f2fs were fixed years
ago by commit 54475f531bb8 ("fscrypt: use ENOKEY when file cannot be
created w/o key"). ubifs was fixed by commit b01531db6cec ("fscrypt:
fix race where ->lookup() marks plaintext dentry as ciphertext").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
fstests only supports Linux, so get rid of this unnecessary predicate.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Consistently use _require_symlinks on all generic tests which
create a symlink when they run.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Rename the helper functions that add/remove keys from the session
keyring, in order to distinguish them from the helper functions I'll
be adding to add/remove keys from the new filesystem-level keyring.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For conciseness in tests, add helper functions that wrap the xfs_io
commands 'set_encpolicy' and 'get_encpolicy'. Then update all
encryption tests to use them.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If generic/397 is executed in an environment with SIGPIPE ignored,
it fails because the 'yes' program prints an error message:
yes: standard output: Broken pipe
yes: write error
This can be reproduced with:
trap '' SIGPIPE; ./check generic/397
Fix it by generating the string of 255 y's using just 'head' and
'tr' instead of 'yes', 'head', and 'tr'.
Although it's not really a good idea to execute xfstests with
SIGPIPE ignored, this is the only test I've noticed where it causes
a problem, so it might as well be fixed in the test.
It would be much nicer to prevent this problem for all tests by
making the 'check' script restore the default SIGPIPE handler. But
that isn't straightforward because bash's 'trap' builtin doesn't
allow un-ignoring signals that were ignored on entry to the shell.
[ eguan added more background infomation to commit log, which is
also from Eric.
I think it's an easy problem for others to run into, since sometimes
processes ignore SIGPIPE because they want to get write errors
instead, but then when doing fork() + exec() they forget to reset
the SIGPIPE handler. Notably, Python got this wrong and it wasn't
fixed until Python 3, so any programs executing the 'check' script
from a Python 2 script will usually get this wrong (see:
https://bugs.python.org/issue1652). And usually everything works
fine but every once in a while there is a weird problem like this
which has to be debugged. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test accessing encrypted files and directories, both with and
without the encryption key.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Murphy Zhou
Eric Biggers
Darrick J. Wong
Eric Sandeen
Dave Chinner