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

[Nikhil]

On Tue, Jul 21, 2009 at 12:12 AM, Jeremy Allison <jra at samba.org> wrote:

>  On Mon, Jul 20, 2009 at 10:14:49PM +0530, Nikhil wrote:
> >  Hi,
> >
> > We have a CIFS server running on a NetApp server and a Solaris host
> running
> > Samba-3.3.2.
> >
> > When we mount both the filesystems to a Drive on a Windows using the net
> use
> > command and then try to run a java program which basically does nothing
> but
> > continuosly writes a data chunk to a file. On a side note, these same
> > filesystems are accessible on a Solaris (unix) host too.
> >
> > When the java program is run and a file is being generated, I go to my
> unix
> > terminal and happen to delete the file generated by the java program.
> > Interestingly, there is an IOexception caught in the java program running
> on
> > the Windows machine, when the file is deleted on the CIFS based
> filesystem
> > (available on Solaris as a NFS filesystems) but there is no exception
> caught
> > when the filesystem happens to be Samba (available on Solaris as /var , a
> > regular partition).
> >
> > I delete the file from Unix as the process demands, but also there is no
> way
> > to delete a in-use-file in Windows.
> >
> > I would like to understand the differences in Samba and CIFS in this
> context
> > especially why is that so there is an IOexception for a CIFS based
> > filesystem but not on the samba filesystem. This is reproducible at will.
> > What could be wrong? What could be made to make samba filesystem also
> behave
> > the same way to throw exceptions (Exceptions are good than that not at
> all
> > knowing there is a file that is deleted but being still written onto.)
>
> Ok, I think the reason that you're having this problem is that
> you're running Samba on Solaris in this case, sad to say.
>
> I don't believe Sun have exposed kernel level oplock (lease) capability
> to user space processes, so Samba on Solaris has no way of knowing
> that a unix user deleted the file.
>
> Samba running on Linux, (or SGI Irix) has kernel level oplocks,
> so can detect access from the local filesystem. As the NetApp
> runs a custom kernel (derived a long time ago from FreeBSD I
> believe) then their CIFS implementation (like Samba on Linux)
> knows when a NFS user has modified the file.
>
> Jeremy.
>


Thanks Jeremy. Appreciate your response.

That actually sounds interesting... do we have this documented or referenced
as a bug somewhere that I can lookup?

What I see from the CIFS protocol:
-----
When client B opens the file, the server must synchronize with client A
in case client A has any buffered locks.  Once it is synchronized,
client B's open request may be completed.  Client B, however, is
informed that he has a level II oplock, rather than an exclusive oplock
to the file.
In this case, no client that has the file open with a level II oplock
may buffer any lock information on the local client machine.  This
allows the server to guarantee that if any write operation is performed,
it need only notify the level II clients that the lock should be broken
without having to synchronize all of the accessors of the file.
The level II oplock may be broken to none, meaning that some client that
had the file opened has now performed a write operation to the file.
----

I do not understand whether Solaris fails to respect the level II oplock or
how does Samba can be made aware of the kernel level oplocks (is there a no
way?).

BTW, to check it myself on what you said I ran samba-3.0.25 on a Linux
machine with kernel version 2.4.21-47.0.1.ELsmp and ran smbd and then did
the same tests.
 - Ran java program on Windows which writes to the file continuously on a
samba exported filesystem from a Linux box
 - on the Linux terminal, I go and delete the file
 - Windows does NOT recognise that there is a opened file deleted and the
Java program does NOT thrown any exception... sadly.

So, I do not have a Linux box with kernel -2.6, so if that means to say that
Linux kernel has introduced kernel level oplocks facility in the 2.6 kernel
then I would have to try that...

Thanks.