byte range locking

Andrew Tridgell tridge at
Wed Jan 12 23:33:27 GMT 2000

> 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.

- 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.

- 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.

- at the moment I've left in place our current blocking locks code. I
  will look at that after the main stuff is committed.

More information about the samba-technical mailing list