Tests fail on NFS

[frankcrawford]

This is following on from the discussions in Issue #8 as it is really independent to the spec files.

[frankcrawford]

Yes, I suspect it is an issue between NFS and bash.

The results on NFS are:

===== Loading script =====

  Script general-functions loaded

===== Check version requirements =====

  Version enforcement working
./results/xx.match
1-radvd.conf  3-radvd.conf  general-test.err
2-radvd.conf  4-radvd.conf  general-test.log
/bin/ls: cannot access './results/*.match': No such file or directory
 F45  OK
 F45f FAIL | nmg::foreach_filematch(<2 matches>) - makes callbacks (reg 1)
diff: <expected> <found>
1,2c1
< ./results/xx.match xx
< ./results/yy.match yy
---
> 

For reference local disk gives:

===== Loading script =====

  Script general-functions loaded

===== Check version requirements =====

  Version enforcement working
./results/xx.match
1-radvd.conf  3-radvd.conf  general-test.err  xx.match
2-radvd.conf  4-radvd.conf  general-test.log  yy.match
-rw-r--r--. 1 frank frank 0 Jun 13 12:42 ./results/xx.match
-rw-r--r--. 1 frank frank 0 Jun 13 12:42 ./results/yy.match
 F45  OK
 F45f OK

The system is running
GNU bash, version 5.1.16(1)-release (x86_64-redhat-linux-gnu)
and automount is giving
bits:/home on /net/bits/home type nfs4 (rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=fdd2:7aad:d478:1::cb10:cc07,local_lock=none,addr=fdd2:7aad:d478:1::cb10:cc01)
NFS kernel implementation kernel version 5.17.12

I'm not sure, but suspect the issue is that bash is holding open the file descriptor in and the kernel NFS implementation is caching the data until it is closed. However, I'm not sure this is what is really happening or something entirely different.

[sshambar]

I tried on a nearly identical nfs4.2 mount with bash 5.1.8, and couldn't trigger the "missing file" behavior... I'm basically using printf "" >> "file" as a "fork-free touch" -- alternatively, I could either:
a) use: command -p touch $file
b) try: echo > $file
The first is a new process so should avoid caching issues, the second creates file content and may force a file creation... either one does feel a bit like a workaround for a NFS bug, but I didn't find anything reported in my quick googling, so it is really really odd that a file isn't visible to bash after the same bash creates it ...

Do you suppose you could try the options above to see if either has the desired result? Cheers :)

[frankcrawford]

Strange, neither of these make any difference, however, strangely, if I put a sleep after the xrm "$TEST_OUT/"*".match" line above and then works correctly.
I'm investigating what seems to be cached or not and is causing the problem.

[frankcrawford]

And further, if I drop the to NFS v3, it works fine.
However, just about every thing I can tweak about caching for NFS v4 does not seem to have an effect.