[jcifs] Davenport Locking

[Julian Reschke]

Chris McEniry wrote:

> I've been working on getting locking working in Davenport, and I've 

Sounds great.

> gotten it most of the way there for single file lock requests, but I've 
> run into a problem holding the lock that I'm hoping someone here may be 
> able to shed some light on.
> 
> Basically, my methodolgy is this:
> 
> .) Keep a servlet context level object that contain holds Locks(which 
> have the webdav info - token, timeout, etc - and the smb info - a 
> SmbFile and an SmbRandomAccessFile).  Locks are stored in a hash keyed 
> on the token.
> .) When a LOCK request comes in, it attempts to create a SmbFile with 
> shareAccess = FILE_SHARE_READ, and to open a SmbRandomAccessFile, and 
> keeps those around.
> .) When another method comes in with an "If" header, it looks up the 
> lock in the map and returns the SmbFile which is stored in the lock.

This may be not enough, depending on how SMB locks work. If a request 
doesn't have an "If" header, and if it attempts to modify a 
lock-protected, it should fail.

See 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html> 
for a good summary how how WebDAV locks behave.

Also note that creating a WebDAV lock both locks the resource identified 
by the request URI (directly), and the URI itself (indirectly). For 
instance, after having locked "a/b" you are not supposed to be able to 
rename "a" without providing the lock token in the request header. This 
may be possible to enforce in the servlet, but probably not via SMB.

I'm not sure whether the default webdav web application shipping with 
Tomcat 4/5 gets this right, but you may want to check.

> ...

> (I have other questions stemming from the rest of this - permissioning 
> and who to show what locks to etc -, but I'll save those for another 
> email...)

I'll be happy to help with those. Basically, locks and permissions are 
independent concepts. To modify a locked resource, you just need to 
provide the lock token; it doesn't matter where you got it from, and 
whether it has been created on behalf of the same user (servers MAY 
enforce this, but don't have to). Similarily, the server can choose not 
to reveal lock tokens upon PROPFIND (however, I wouldn't recommend doing 
that because it breaks a lot of clients).


Regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760