byte range locking

[Cole, Timothy D.]

> -----Original Message-----
> From:	Andrew Tridgell [SMTP:tridge at linuxcare.com]
> Sent:	Wednesday, January 12, 2000 18:34
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: byte range locking
> 
> > I don't think you can entirely remove all the hacks as we still
> > need to set POSIX lock ranges on the extents locked in Samba
> > (mangling as neccessary). 
> 
> we can certainly remove most of the hacks. For posix lock
> compatibility I plan the following (that part isn't written yet)
> 
> - posix lock compatibility will be optional. I'm not sure if it should
>   default on or off, I'm still thinking about that.
> 
	Well, you risk data corruption in a mixed environment, if it's off.
OTOH, the same is true of the oplocks setting, which defaults to the unsafe
option for a mixed environment (on) too.

> - we will only try posix locks for byte ranges in 0 -> 2^30. (not 2^31
>   to avoid some bugs in nfs lock daemons). locks above that range will
>   only be represented in the brlocks database.
> 
	Well... maybe 2^31 support should be a compile-time flag.  If the
particular nfs lock daemon WILL permit it, it'd be nice to have.

> - I won't do the fd multiplexing. That means I will need to restore
>   posix locks after a close on a fd that is opened twice. there is a
>   race here, but I think the race is better than the fd multiplexing
>   and the need to always open rw. Our current hack doesn't always work
>   anyway if the same smbd is serving multiple uids.
> 
	Hmm... if something else wins the race, is there a way to signal the
broken lock to the client?