From: Eric Biggers Date: Tue, 13 Dec 2016 06:57:01 +0000 (-0800) Subject: generic/062: don't assume same readdir order after re-creating directory X-Git-Tag: v2022.05.01~2269 X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=84db46e3d327ad06b6eb7cb8c90bea72fed257aa;p=users%2Fhch%2Fxfstests-dev.git generic/062: don't assume same readdir order after re-creating directory generic/062 uses getfattr to dump xattrs for a directory tree, then deletes and recreates that directory tree, then dumps the xattrs again and compares the dump to the original. This was failing when run on ext4 with encryption enabled because getfattr's output is in readdir order, but ext4 encryption by design chooses unpredictable encrypted filenames for each new directory, causing the readdir order to change after backup and restore. It is not really a valid assumption that the readdir order will always be the same, so update the test to sort the filenames, removing this assumption. Signed-off-by: Eric Biggers Reviewed-by: Brian Foster Signed-off-by: Eryu Guan --- diff --git a/tests/generic/062 b/tests/generic/062 index e4dc2cc8c..643f02c3f 100755 --- a/tests/generic/062 +++ b/tests/generic/062 @@ -178,8 +178,11 @@ echo; echo _backup() { - # NB: no filtering of scratch here... (need to restore too) - $GETFATTR_PROG --absolute-names -dh -R -m '.' $SCRATCH_MNT >$1 + # Note: we don't filter scratch here since we need to restore too. But + # we *do* sort the output by path, since it otherwise would depend on + # readdir order, which on some filesystems may change after re-creating + # the files. + $GETFATTR_PROG --absolute-names -dh -R -m '.' $SCRATCH_MNT | _sort_getfattr_output >$1 echo BACKUP $1 >>$seqres.full cat $1 >> $seqres.full [ ! -s $1 ] && echo "warning: $1 (backup file) is empty"