samba - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author	Files	Lines
2007-10-10	r3312: in the brlock code, we prevent lock stampedes by attempting to not	Andrew Tridgell	1	-1/+3
	wakeup all pending locks at once. This change means that we only trigger this anti-stampede code for write locks, as for pending read locks the correct behaviour is to stampede (as they will all succeed) (This used to be commit 8021d1d74207db1204139309592b9d2f80f2bd0e)
2007-10-10	r3271: use "struct messaging_context " instead of "void " in messaging API	Andrew Tridgell	1	-2/+2
	(This used to be commit cc93813e4a09c538ad485dc2b3cb4c9be34f3d18)
2007-10-10	r3126: in the brlock code I had used a void* for the brl context as I didn't	Andrew Tridgell	1	-14/+9
	want to expose the brl context structure outside the brlock.c code. Instead, I now use "struct brl_context *" and rely on C being happy to pass around pointers to unknown structures as long as they are not dereferenced. I will be interested to see how the build farm likes this. (This used to be commit cb155c8ad837285c5a7f5b104968239df0b65fd2)
2007-10-10	r3031: added support for lock cancelation, which effectively just triggers ↵	Andrew Tridgell	1	-5/+14
	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-10	r3029: implemented byte range lock timeouts.	Andrew Tridgell	1	-28/+244
	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-10	r3012: added initial support for byte range locking in the posix vfs. This is	Andrew Tridgell	1	-0/+418
	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)