Test script: ------------ #!perl use IO::Handle; $io = new IO::Handle; open($io, ">Z:/samba_test/blah") or die; while (1) { print $io "blah"; print "wrote to blah\n"; sleep 5; print "flushing handle\n"; $io->flush; sleep 5; } If I run the above test script on Windows against a Solaris 3.0.8 smbd *without* write cache: * I see nothing before the flush * I see "blah" immediately after the flush The above behavior is what you would expect. If I run the script on a system *with* write cache: * I see nothing before the flush * I see 4 null characters after the flush: useq1.nyc:/u/woodd/tmp/samba_test > cat -v blah; echo "" ^@^@^@^@ * I never see anything other than the 4 null characters until I kill the script. Once the script is killed the filehandle is closed and the file contents are correct. The write cache is set to 256K: write cache size = 262144 David
Still a problem in 3.0.11. David
David, from what I recall, the write cache is managed by smbd and not the client. Jeremy has made changes to the code recently so I';ll let him decide what to do with this bug.
Looking at the code for flushing a file it does indeed flush the write cache if 'strict sync = yes' is set. Do you have that set? If not, I'd be interested in a sniff and debug level 10 log of smbd while running your script. Thanks, Volker
Created attachment 1230 [details] Info for Volker Hi Volker, I've uploaded the information you requested (I also included smb.conf). The problem occurs no matter how "strict sync" is set. David
Closing this bug as invalid because this is exactly the behaviour that is to be expected from setting 'write cache size'. The client requests an oplock on the newly created file, the flush() from perl triggers another ntcreate&x with another oplock from the same client. So the client still holds that oplock, and there is no need to write the data out to disk. The 'flush' does not trigger the 'smbflush' request over the network, so Samba can't do much about it. Volker
> The 'flush' does not trigger the 'smbflush' request over > the network, so Samba can't do much about it. Okay, thanks for looking into it. I certainly can't argue the semantics of the CIFS specification; however, I can say that Samba's behavior has definitely changed between v2.0.8 and v3.0.X given we used to use the "write cache" option extensively with no ill effect. BTW - I've run the same test script against a Netapp filer and it doesn't exhibit this behavior. The filer has all cache and oplocks enabled which means it must be flushing the file after the second oplock request (even without an 'smbflush' request). It might not be the ideal/correct behavior based on the CIFS specification; however, it is certainly pragmatic since it avoids problems like this one. Thank you again for your time. David