Removing OPLOCK check in sendfile processing (source/smbd/reply.c) increases speed

[Henrik Nordstrom]

On Mon, 3 May 2004, Christoph Lameter wrote:

> > The reason for the oplock check is that the way sendfile operates, we
> > fill in the smb header, before we read the file.  Therefore, we must
> > 'know' that the file is not going to change underneath us (in
> > particular, will not be shorter).
> 
> Why is it then possible to do read() followed by write() without holding
> the oplock? The file could be truncated after read() is complete.

Because then the smb header is created based on the results of the read()
making it reflect what the write will send and there is no problem dealing 
with the case that the file was truncated under our feets.

Regards
Henrik