[Samba] Difference in Samba and CIFS interms of keeping the deleted files opened

[Nikhil]

On Tue, Jul 21, 2009 at 5:06 PM, Gerald Carter <jerry at 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