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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx>: >> > 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@xxxxxxxxxxxxx> > > 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 -- 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
