mirror of
https://github.com/samba-team/samba.git
synced 2025-02-28 01:58:17 +03:00
66b8ee1e64
This means locks are associated with the SMB handle they were created on, not the inode. In all other ways they behave like UNIX extensions fcntl (process-associated) locks. Torture test to follow. When a handle is closed all locks attached to that handle are closed, not all locks on the underlying inode. In this respect they now behave like Windows locks. The key to this in the UNIX extensions locking codepath is modifying the reference count only when a new locking context is seen on any lock request, and decrementing the reference count when the last instance of a locking context is seen on any unlock request. For SMB2+ the persistent part of a file handle is used as the locking context so this behavior becomes natural. This is a behavior change but after consultation with Jeff Layton and Steve French the only client that implements UNIX extensions POSIX locks - the cifsfs client - already expects these locks to behave like open file description (ofd) locks. With our previous behavior Linux ofd-locks fail against smbd. Signed-off-by: Jeremy Allison <jra@samba.org> Reviewed-by: Jeff Layton <jlayton@samba.org>