byte range locking
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Fri Jan 14 16:28:53 GMT 2000
> -----Original Message-----
> From: Steve Langasek [SMTP:vorlon at netexpress.net]
> Sent: Friday, January 14, 2000 11:23
> To: Cole, Timothy D.
> Cc: Multiple recipients of list SAMBA-TECHNICAL
> Subject: RE: byte range locking
> On Sat, 15 Jan 2000, Cole, Timothy D. wrote:
> > > 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
> > disk, but that's a LOT more acceptable than introducing a race condition
> > that invites data corruption.
> That wouldn't even be a consequence, would it? The inode is going to hang
> around as long as there are any references to it, and we're already
> in this scenario about having multiple file descriptors open on the same
> So the inode can't go away either way until we're done with it.
Oh yeah, good point :P
So, yes, Andrew ... PLEASE just keep the file descriptor around,
rather than introducing races.
More information about the samba-technical