On Tue, Jul 21, 2009 at 5:06 PM, Gerald Carter <je...@plainjoe.org> wrote:
> Nikhil, > > > I looked at the enabling kernel oplocks in the samba configuration file > and > > I have enabled "kernel oplocks = yes" in the [global] section on both of > > Linux-2.6.18-92 and Linux-2.4.21-47.0.1.ELsmp kernel machines running the > > samba and I notice that the behaviour is not as what is said. I still do > not > > see the exception being NOT caught on Windows java program when I delete > the > > file from a Unix terminal. > > > > Any idea, where I could be going wrong? > > It sounds more like smbd maintains the opens file descriptor > as long as the client has an open file handle. Standard > POSIX semantics allow you to delete open files with the inode > finally being released after the last open fd is closed. > I could speculate that it may be less to do with CIFS and more > to do with the server OS. But that is pure speculation. > > Have you looked at a network trace to see which SMB op caused > the IO Exception? Does truncating rather than removing the > file change the application behavior? > > > > > cheers, jerry > -- > ===================================================================== > http://www.plainjoe.org/ > "What man is a man who does not make the world better?" --Balian > > Hi Jeremy, Yeah.. I tried oplocking thing (btw, is there any set-direct-go howto on oplocking configuration parameters to be used smb.conf?) and checked via the smbstatus that the file is being into the samba lock. But when I rm the file from the Unix terminal, the windows program does not detect the file deletion. >> it may be less to do with CIFS and more to do with the server OS. But that is pure speculation. agreed. I am running Solaris-10 where kernel oplock is not available, so will rule that out. I have linux box with 2.6 kernel and kernel oplocks=yes set in smb.conf; but that still does not help in getting the sync set. >> Does truncating rather than removing the file change the application behavior? Interesting. I do "/bin/cp -f /dev/null /var/tmp/test.log" and I notice that ls -l does not show that the file is truncated at all.... even though I do it multiple times; ls -l still does not show that the file is truncated. Am I missing something that why is rm command or deleting the file behaviour would differ? BTW, this is the output of testparam -s -v | grep -i lock output: Load smb config files from /var/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[tmpdir]" Loaded services file OK. Server role: ROLE_STANDALONE kernel oplocks = Yes lock spin time = 200 oplock break wait time = 0 lock directory = /var/samba/locks usershare path = /var/samba/locks/usershares block size = 1024 veto oplock files = blocking locks = Yes fake oplocks = No locking = Yes oplocks = Yes level2 oplocks = Yes oplock contention limit = 2 posix locking = Yes strict locking = Yes Can you please let me know if any of the parameters need something else/need not put? Thanks again, Jeremy. -- Nikhil -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba