Some filesystems (e.g. UBIFS) fail with EPERM when trying to move a
file into an encrypted directory via cross rename, without having
access to the encryption key.
Since rename is perfectly allowed to return EPERM, which is also
tested for, and no precise specification seems to exist that
clarifies when to expect EPERM and when ENOKEY, this patch modifies
the generic/398 test to accept both, for the test case where the key
is not available.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
rm -f $tmp.*
}
+filter_enokey()
+{
+ # rename without key can also fail with EPERM instead of ENOKEY
+ sed -e "s/Required key not available/Operation not permitted/g"
+}
+
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
efile2=$(find $edir2 -type f)
echo -e "\n\n*** Exchange encrypted <=> encrypted without key ***"
-src/renameat2 -x $efile1 $efile2
+src/renameat2 -x $efile1 $efile2 |& filter_enokey
echo -e "\n*** Exchange encrypted <=> unencrypted without key ***"
-src/renameat2 -x $efile1 $udir/ufile
+src/renameat2 -x $efile1 $udir/ufile |& filter_enokey
# success, all done
status=0
*** Exchange encrypted <=> encrypted without key ***
-Required key not available
+Operation not permitted
*** Exchange encrypted <=> unencrypted without key ***
-Required key not available
+Operation not permitted