byte range locking

Cole, Timothy D. timothy_d_cole at
Fri Jan 14 15:47:40 GMT 2000

> -----Original Message-----
> From:	Andrew Tridgell [SMTP:tridge at]
> Sent:	Thursday, January 13, 2000 19:50
> To:	Cole, Timothy D.
> Cc:	samba-technical at
> Subject:	Re: byte range locking
> > 	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 might even make that the default - hopefully those old lock daemons
> are getting less common.
> > 	Hmm... if something else wins the race, is there a way to signal the
> > broken lock to the client?
> no, the client hasn't done a lock operation. 
> the only alternative I can think of is to not close the file at all if
> any mapped locks are present and instead defer the close until all
> locks are gone or all copies of the file are closed in this smbd.
	Hmm.. maybe you'd better do that.  The only adverse consequence is
that an unlinked inode might hang around longer than it normally would on
disk, but that's a LOT more acceptable than introducing a race condition
that invites data corruption.

> it should be a pretty rare situation anyway.
	Yeah, but it's still better to be as correct as possible.

More information about the samba-technical mailing list