summaryrefslogtreecommitdiff
path: root/source4/ntvfs/posix/pvfs_lock.c
AgeCommit message (Collapse)AuthorFilesLines
2007-10-10r3035: if the ntvfs layers prior to us have said that we can't perform anAndrew Tridgell1-1/+2
operation asynchronously (such as the nbench module), then ignore lock timeouts, as they would make no sense (This used to be commit 2894dd0ac0ddd0ae5b4d536d5cff0690bbfab1a0)
2007-10-10r3034: - fixed a bug in message dispatch, when the dispatch function called ↵Andrew Tridgell1-13/+33
messaging_deregister() - added a pvfs_lock_close_pending() hook to remove pending locks on file close - fixed the private ptr argument to messaging_deregister() in pvfs_wait - fixed a bug in continuing lock requests after a lock that is blocking a pending lock is removed - removed bogus brl_unlock() call in lock continue - corrected error code for LOCKING_ANDX_CHANGE_LOCKTYPE - expanded the lock cancel test suite to test lock cancel by unlock and by close - added a testsuite for LOCKING_ANDX_CHANGE_LOCKTYPE (This used to be commit 5ef80f034d4aa4dd6810532c63ad041bfc019cb8)
2007-10-10r3031: added support for lock cancelation, which effectively just triggers ↵Andrew Tridgell1-6/+53
an early lock timeout added support for more of the bizarre special lock offset semantics of w2k3 (This used to be commit d5bfc910b1200fb283e26572dc57fcf93652fd32)
2007-10-10r3029: implemented byte range lock timeouts.Andrew Tridgell1-4/+182
This adds a pvfs_wait_message() routine which uses the new messaging system, event timers and talloc destructors to give a nice generic async event handling system with a easy to use interface. The extensions to pvfs_lock.c are based on calls to pvfs_wait_message() routines. We now pass all of our smbtorture locking tests, although while writing this code I have thought of some additonal tests that should be added, particularly for lock cancel operations. I'll work on that soon. This commit also extends the smbtorture lock tests to test the rather weird 0xEEFFFFFF locking semantics that I have discovered in win2003. Win2003 treats the 0xEEFFFFFF boundary as special, and will give different error codes on either side of it. Locks on both sides are allowed, the only difference is which error code is given when a lock is denied. Anyone like to hazard a guess as to why? It has me stumped. (This used to be commit 4395c0557ab175d6a8dd99df03c266325949ffa5)
2007-10-10r3012: added initial support for byte range locking in the posix vfs. This isAndrew Tridgell1-0/+151
enough for us to pass locktest, but does not yet support lock timeouts and some of the other esoteric features. (This used to be commit 58a92abd88f190bc60894a68e0528e95ae33fe39)