Batch OpLocks: Are they used much these days ...

David Collier-Brown davecb at
Thu Jan 10 04:49:05 GMT 2002

Urban Widmark wrote:
> Batch oplocks allow a lot more caching on the client side. smbfs can read
> pages into memory and does not have to invalidate them even when the file
> is closed, because the batch oplock allows the close to be cached. If the
> file is opened again the pages remain valid.
> The smbfs code doesn't actually do that, but it could.
> Why would anyone want just an exclusive oplock?

	Arguably for sharing: if the file needs
	to be single-writer multiple-reader an
	exclusive write lock is appropriate.

	If the file is read-only, caching a close
	is harmless if and only if doing so does
	not leave the file locked against writers!

	It's not actually that clean: batch oplocks
	exist because early batch processors would
	open a file, read one line,  close, execute
	the line, reopen, seek to the next time and 
	repeat.  The discussion of caching content
	from a server on the client then motivated
	oplocks, and sure enough, support for the
	close-and-reread semantics of the old batch	

	But without, it seems, considering the
	correctness of holding an implicit
	write lock on a file that is treated as

David Collier-Brown,           | Always do right. This will gratify 
Americas Customer Engineering, | some people and astonish the rest.
SunPS Integration Services.    |                      -- Mark Twain
(905) 415-2849                 | davecb at

More information about the samba-technical mailing list