Shyam Prasad N <nspmangalore@xxxxxxxxx> writes:
> So I don't think we should be changing the logic here.
I would tend to agree.
> If SMB v1 had a different behaviour, we should check if that is as per
> the protocol documentation. If not, change it.
I think the main difference is that SMBv1 doesn't have the concept of
lease keys. I think lease keys were added to handle cases like this:
case a)
client: >> send create+lease (key=XYZ). I don't know the file fid yet
server: local open & concurent open (create response not sent yet!)
server: << send oplockbreak key=XYZ
client: dont know the fid, but i can match the lease key with a request
I made, so it's valid
server: << send create response (fid=123)
client: I know the fid now
case b)
client: >> send create+lease (key=XYZ)
server: << open file, send create response (fid=123)
client: >> close file, release file ressources, send close fid=123
server: before receiving close, concurrent open happens
server: << send oplock break (key=XYZ)
server: << send close
client: depending on the order the response are processed, I might not
process oplock because i don't know this file! I already closed
it. But I know this lease key
Without client-generated lease keys you cannot match things you don't
have an FID for (because you haven't received it yet, or because it was
closed). And FIDs can be reused and point to different files.
Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
