From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f51.google.com ([74.125.83.51]:40736 "EHLO mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbeEJW0Q (ORCPT ); Thu, 10 May 2018 18:26:16 -0400 MIME-Version: 1.0 In-Reply-To: <20180510221248.GA203322@jra3> References: <20180510184817.GG23039@jra3> <20180510221248.GA203322@jra3> From: Steve French Date: Thu, 10 May 2018 17:25:55 -0500 Message-ID: Subject: Re: [PATCH] cifs/smb3: directory sync should not return an error To: Jeremy Allison Cc: ronnie sahlberg , linux-fsdevel , CIFS , Pavel Shilovsky , samba-technical Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, May 10, 2018 at 5:12 PM, Jeremy Allison 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