On Thu, May 10, 2018 at 05:25:55PM -0500, Steve French wrote: > > 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). In the meantime I'm going to fix the smbd server to act the same way that Windows Does (TM). That's what real clients expect :-). -- 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
