Even so ... we shouldn't ask for open/query/close or open/setinfo/close if just a query-info or set-info (no open/close) is possible - it will make server's lives much easier ... On Wed, Sep 11, 2019 at 3:06 PM Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > > чт, 29 авг. 2019 г. в 15:26, Ronnie Sahlberg <lsahlber@xxxxxxxxxx>: > > > > rename() takes a path for old_file and in SMB2 we used to just create > > a compound for create(old_path)/rename/close(). > > If we already have a writable handle we can avoid the create() and close() > > altogether and just use the existing handle. > > > > For this situation, as we avoid doing the create() > > we also avoid triggering an oplock break for the existing handle. > > Hi Ronnie, > > Another SMB2_CREATE from the same client shouldn't cause a lease break > if we ask for a lease with the same lease key. The lease key is > associated with the inode, all opens that can cause a break should ask > for the lease with the lease key. > > Currently smb2_compound_op doesn't ask for a lease: see at the > beginning of the function: > > oplock = SMB2_OPLOCK_LEVEL_NONE > > What we need to do is to change this to SMB2_OPLOCK_LEVEL_BATCH for > operation that modifies the file like SET_EOF and SET_INFO. In this > case the lower layer will map it to the appropriate lease state. Note > that parms->fid->lease_key should be populated. > > -- > Best regards, > Pavel Shilovsky -- Thanks, Steve