On Thu, May 10, 2018 at 5:12 PM, Jeremy Allison <jra@xxxxxxxxx> wrote: > On Fri, May 11, 2018 at 08:08:46AM +1000, ronnie sahlberg wrote: >> SMB2 FLUSH ? >> >> MS-SMB2.pdf is pretty clear that FLUSH can only be used on files or pipes. >> If we start using it for directory handles we would need some >> clarifications about this use in the spec. > > Yes. MS-SMB2 is also wrong :-). > > I have test code that proves FLUSH works against any directory > handle opened with FILE_ADD|DIRECTORY_ADD access mask granted. > > (Steve thought this might be special cased to just the root > directory handle on a share, this turns out not to be the > case - any directory handle with the required access works > OK). > >> I would wait until MS-SMB2 is updated before we start sending FLUSH on >> directory handles. > > We need to deal with the protocol as it really is, > not as the documentation would like it to be :-). Current behavior seems to be that (for SMB2/SMB3 as with NFS) servers are not expected to cache file creates. If we send a flush over the wire without a lot more testing we could break even more apps - unless we simply send the request and ignore the return code which I would prefer not to do until we get feedback from more servers and clarification from MS-SMB2). What we don't want to do is pass EINVAL back which breaks some. Ronnie said it well: " If/once ms-smb2.pdf is updated to describe the semantics for flush on a directory, then we can think about using flush here. Not before. Otherwise we just revert back to chasing implementation specific behavior" (as we did with SMB1) (so fix the current behavior - then think about whether we can safely send this as a flush if there are any valid cases which MS-SMB2 exposes in the future). -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
