[jcifs] Davenport Locking

[Michael B Allen]

Chris McEniry said:
> And by watching part of it, it appears that the SmbFile is opening and
> getting a lock on the SMB server(samba 3.0.2 fyi), but after about 30
> seconds or a minute, the lock disappears.  Davenport is none the wiser
> to this and goes along it's merry way, but I am able to open and get a
> lock on the file when accessing it directly(by mapping to the samba
> server from my desktop).
>
> So, my questions are: Does jCIFS close connections on a regular basis or

Yes. JCIFS closes any connection if it has been idle for longer than
jcifs.smb.client.soTimeout milliseconds. The default value is 15000.

> and, when using shareAccess for locking, does
> the SmbFile object hold the lock or only the real file access
> objects(SmbFileRandomAccess, SmbFileInputStream, SmbFileOutputStream,
> etc)?

JCIFS just passes the shareAccess parameter in the SmbComNtCreateAndX
command to the SMB server. This is how SMS clients are supposed to operate
and is fully functional with respect to other clients. There's no fudging
going on.

So the problem is clearly that the SmbTransport is closing which provokes
the server to close any files the client had open which releases any
locks.

Another similar problem with NetworkExplorer (and thus Davenport) is that
cached NtlmPasswordAuthentication objects are rendered invalid when the
SmbTransport closes. NetworkExplorer is "none the wiser to this" and will
proceed to attempt to use those credentials only to find they fail.
Fortunately do to the timing of things and failover capability users
normally do not see the effects of this.

The solution will likely involve destroying objects cached in the HTTP
session when the SmbTransport closes but until I util I determine how that
will be done precisely I recommend that you simply set
jcifs.smb.client.soTimeout to a value that is larger than the largest
possible HTTP session time limit (such as 0 which will be interpreted as
infinate).

Mike