From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hr2.samba.org ([144.76.82.148]:50384 "EHLO hr2.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746AbeEJXG5 (ORCPT ); Thu, 10 May 2018 19:06:57 -0400 Date: Thu, 10 May 2018 16:06:52 -0700 From: Jeremy Allison To: Steve French Cc: ronnie sahlberg , linux-fsdevel , CIFS , Pavel Shilovsky , samba-technical Subject: Re: [PATCH] cifs/smb3: directory sync should not return an error Message-ID: <20180510230652.GB203322@jra3> Reply-To: Jeremy Allison References: <20180510184817.GG23039@jra3> <20180510221248.GA203322@jra3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 :-).