Hi Steve,
I've seeing some weird behaviour in the upstream Linux cifs filesystem that's
causing generic/002 to fail. The test case makes a file and creates a number
of hardlinks to it, then deletes those hardlinks in reverse order, checking
the link count on the original file each time it removes one.
However, I'm seeing the original file disappear when the most recent link is
removed, leading to the check for the link count to fail due to $x evaluating
blank and the '[' program complaining about syntax.
I've distilled the testcase down to a small shell script:
#!/bin/sh
TEST_DIR=/xfstest.test/tmp/
top=3
if [ ! -d $TEST_DIR ]
then
mkdir $TEST_DIR || exit $?
else
rm $TEST_DIR/foo.*
fi
touch $TEST_DIR/foo.1
for ((l=2; l<=$top; l++))
do
ln -v $TEST_DIR/foo.1 $TEST_DIR/foo.$l
done
ls $TEST_DIR
for ((l=$top; l>=1; l--))
do
if [ ! -f $TEST_DIR/foo.1 ]
then
echo "Arrgh, foo.1 is missing!"
ls $TEST_DIR
exit 1
fi
x=`stat -c %h $TEST_DIR/foo.1`
if [ "$l" -ne $x ]
then
echo "Arrgh, incorrect link count"
$here/src/lstat64 $TEST_DIR/foo.1
status=1
fi
rm -v -f $TEST_DIR/foo.$l
done
that I'm running on a Linux v6.6 ksmbd share mounted with:
mount //192.168.6.1/test /xfstest.test -o user=...,pass=...,noperm,vers=3.1.1,cache=loose
The server includes the following settings:
server role = standalone server
log level = 1
security = user
load printers = no
#smb3 encryption = yes
netbios name = SMBD
server multi channel support = yes
smb2 leases = yes
The output I see is:
'/xfstest.test/tmp//foo.2' => '/xfstest.test/tmp//foo.1'
'/xfstest.test/tmp//foo.3' => '/xfstest.test/tmp//foo.1'
foo.1 foo.2 foo.3
removed '/xfstest.test/tmp//foo.3'
Arrgh, foo.1 is missing!
foo.1 foo.2 foo.3
I've attached a wireshark trace of the script being run.
I see a lot of STATUS_DELETE_PENDING apparently being applied to foo.1.
David
Attachment:
pcap.gz
Description: application/gzip
