xfs/066: stat the test file, not the directory

Ever since commit 7e2a19504 ("ls -l reports different file size
depending on platform and user.") xfs/066 has been running stat on
the dump/restore directory instead of the large file that the test
is checking can be dumped and restored correctly. IOWs, it's not
been checking the correct thing for almost 10 years.

This test fails on CRC enabled filesystems because the shortform
directory entry size is different (an extra byte for the filetype
filed), and this is where tracking down the failure has lead me.

Fix this by using the correct target file, and improve it by dumping
an md5sum of the source and target files to ensure they contain the
same data.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

tests/xfs/066

@@ -60,11 +60,13 @@ fi
 
 _create_dumpdir_largefile
 echo "ls dumpdir/largefile"
-stat $dump_dir | _my_stat_filter
+stat $dump_dir/largefile | _my_stat_filter
+md5sum $dump_dir/largefile |_filter_scratch
 _do_dump_file
 _do_restore_file
 echo "ls restoredir/largefile"
-stat $restore_dir/$dump_sdir | _my_stat_filter
+stat $restore_dir/$dump_sdir/largefile | _my_stat_filter
+md5sum $restore_dir/$dump_sdir/largefile |_filter_scratch
 
 # success, all done
 status=0

tests/xfs/066.out

@@ -3,7 +3,8 @@ dd a largefile at offset 4294967297
 10+0 records in
 10+0 records out
 ls dumpdir/largefile
-22 largefile
+4294967307 largefile
+e2664609cb95c2215732cf4e71e45017  SCRATCH_MNT/dumpdir/largefile
 Dumping to file...
 xfsdump  -f DUMP_FILE -M stress_tape_media -L stress_066 SCRATCH_MNT
 xfsdump: using file dump (drive_simple) strategy
@@ -37,4 +38,5 @@ xfsrestore: restoring non-directory files
 xfsrestore: restore complete: SECS seconds elapsed
 xfsrestore: Restore Status: SUCCESS
 ls restoredir/largefile
-22 largefile
+4294967307 largefile
+e2664609cb95c2215732cf4e71e45017  SCRATCH_MNT/restoredir/dumpdir/largefile