byte range locking

Andrew Tridgell tridge at linuxcare.com
Wed Jan 12 13:53:32 GMT 2000


This is just to let people know that I have finished an initial
implementation of a new byte range locking system in Samba 3.0. It
seems to work. I'm doing a bit more testing and cleanup before
committing it to the head branch for Samba 3.0.

The new sytem is needed because for a long time we have relied on
posix locking semantics yet these don't match well with SMB locking
semantics. In particular the following doesn't match:

- a close() on posix clears all locks on that file for the process. In
  SMB it clears only the locks on that file descriptor. Thats why we
  have the ugly file descrriptor multiplexing in samba.

- posix locks have 31 bit ranges as they are signed. SMB locks can be
  64 bit. This matters a lot as SMB clients use high lock ranges as
  semaphores. We use a kludge to get around this.

- posix and SMB locks have quite different rules for lock contexts,
  coalescing locks and overlapping locks.

we have survived up till now with posix locks due to some ugly hacks
and reliance on the client redirector not passing some locking
combinations over the wire. The new system fixes it properly.

The new lock system is based on a tdb database shared between all smbd
processes. Once its in place I can start on removing some of those
ugly hacks we needed with posix locks.

Most of the changes are in locking/locking.c and in the new
locking/brlock.c, but some changes are needed in reply.c and open.c in
order to pass through the smbpid for all lock ops as that is important
for the locking context with SMB semantics.

Cheers, Tridge


More information about the samba-technical mailing list