If the TEST_BITS file is sparse, then the "debugfs -R write" command may skip holes in the file when copying it into the test image (depending on whether SEEK_HOLE/SEEK_DATA and/or FIEMAP are available in the copy_file() function). This was causing test failures on MacOS in the f_dup_resize and d_loaddump tests because the TEST_BITS file was the compiled "debugfs" binary, which apparently has holes when built on MacOS, and the number of blocks allocated in the test image was reduced as a result. This caused the expect output to differ in the summary line and resulted in failure. Instead of using the debugfs binary for TEST_BITS, generate a temporary file using /dev/urandom, if available. If not, fall back to the old behaviour or using debugfs. Signed-off-by: Andreas Dilger <adilger@xxxxxxxxx> --- tests/test_config | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/tests/test_config b/tests/test_config index c13aa74..cf9c79c 100644 --- a/tests/test_config +++ b/tests/test_config @@ -13,7 +13,14 @@ E2IMAGE="$USE_VALGRIND ../misc/e2image" E2IMAGE_EXE="../misc/e2image" DEBUGFS="$USE_VALGRIND ../debugfs/debugfs" DEBUGFS_EXE="../debugfs/debugfs" -TEST_BITS="../debugfs/debugfs" +TEST_BITS="test_data.tmp" +if [ ! -s $TEST_BITS ]; then + # create a non-sparse test file if possible, since debugfs may be + # sparse and cause "debugfs write" (using copy_file()) to skip holes + # during testing if SEEK_DATA/SEEK_HOLE or FS_IOC_FIEMAP are available + dd if=/dev/urandom of=$TEST_BITS bs=128k count=1 > /dev/null 2&>1 || + TEST_BITS="$DEFBUGFS_EXE" +fi RESIZE2FS_EXE="../resize/resize2fs" RESIZE2FS="$USE_VALGRIND $RESIZE2FS_EXE" E2UNDO_EXE="../misc/e2undo" -- 1.8.0
