[PATCH] cifs/smb3: directory sync should not return an error

ronnie sahlberg ronniesahlberg at gmail.com
Thu May 10 22:08:46 UTC 2018


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.

I would wait until MS-SMB2 is updated before we start sending FLUSH on
directory handles.


On Fri, May 11, 2018 at 7:56 AM, Steve French via samba-technical
<samba-technical at lists.samba.org> wrote:
> checking various Linux file systems - looks like most of those I
> checked end up with the default "EINVAL" so basically not a very
> useful call to check the return code on - safer to ignore.   If others
> prefer, I don't mind sending the call over the wire and ignoring the
> return code - but presumably some server is going to error unusually
> if we pass it over the wire and expect particularly return codes (and
> thus break apps that check for rc==EINVAL or rc==0).
>
> On Thu, May 10, 2018 at 3:28 PM, Steve French <smfrench at gmail.com> wrote:
>> It wasn't sent to Samba - the error was returned by the VFS before it
>> comes to cifs.ko because we don't implement this call.    NFS
>> (correctly presumably) implements the syscall by ignoring it
>> (returning 0 - rather than the default which is an error), because
>> once an entry in the directory is created it is in the namespace, and
>> they are never cached on the client.
>>
>> On Thu, May 10, 2018 at 1:48 PM, Jeremy Allison <jra at samba.org> wrote:
>>> On Thu, May 10, 2018 at 10:11:43AM -0700, Pavel Shilovsky via samba-technical wrote:
>>>> 2018-05-10 9:04 GMT-07:00 Steve French via samba-technical
>>>> <samba-technical at lists.samba.org>:
>>>> > As with NFS, which ignores sync on directory handles,
>>>> > fsync on a directory handle is a noop for CIFS/SMB3.
>>>> > Do not return an error on it.  It breaks some database
>>>> > apps otherwise.
>>>>
>>>> Reviewed-by: Pavel Shilovsky <pshilov at microsoft.com>
>>>
>>> NAK on this patch. It's due to a specific Samba server
>>> bug, which I've just fixed.
>>>
>>> Look at the man page for fsync() on directory handles
>>> - in SMB2+ as well this is a useful thing for an
>>> application to do.
>>>
>>> The broken Samba server returns NT_STATUS_ACCESS_DENIED
>>> here. What you need to do is test the popular servers
>>> (Windows, NetApp, EMC, Samba, OSX) and see which of
>>> them are broken (not Windows obviously) and if so
>>> what errors they return.
>>>
>>> Best case scenario it's just Samba that was broken,
>>> so check for the specific NT_STATUS_ACCESS_DENIED
>>> error and ignore, otherwise return the error to
>>> the caller - they *NEED* it :-).
>>>
>>> Jeremy.
>>
>>
>>
>> --
>> Thanks,
>>
>> Steve
>
>
>
> --
> Thanks,
>
> Steve
>



More information about the samba-technical mailing list