Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Ralph Böhme]

On Fri, Apr 07, 2017 at 10:40:00PM +0300, Uri Simchoni via samba-technical wrote:
> On 04/07/2017 09:41 PM, Jeremy Allison via samba-technical wrote:
> > On Fri, Apr 07, 2017 at 09:37:02PM +0300, Uri Simchoni wrote:
> >> On 04/07/2017 09:04 PM, Jeremy Allison via samba-technical wrote:
> >>> Can't we change this to a generic:
> >>>
> >>> bool VFS_QUERY_FEATURE(fsp, const char *vfs_module_name, const char *feature_name);
> >>>
> >>> or
> >>>
> >>> void *VFS_QUERY_FEATURE(fsp, const char *vfs_module_name, const char *feature_name);
> >>>
> >>> that can sweep aapl-specific flags/structs out of the main interfaces
> >>> and back onto the module-specific private data struct where they
> >>> belong ?
> >>>
> >> +1. My thinking of this has been:
> >>
> >> a. It's Apple-specific, let's hide it
> >> b. ...But Macs are important too, let's not hide it (that's where I
> >> submitted the file-id patch which adds an Apple-specific flag to the SMB
> >> server).
> >> c. ...But their version of the protocol is not documented and subject to
> >> change without notice, and Microsoft's version currently is documented
> >> and supported, so let's keep the main SMB code adhering to the
> >> documented protocol version and (try to) hide undocumented dialects.
> >>
> >> Just my 2c...
> > 
> > Yeah, each individual decision made sense at the time,
> > but I don't like where we ended up if you see what I
> > mean.
> > 
> > Wouldn't a:
> > 
> > void *VFS_QUERY_FEATURE(fsp, const char *vfs_module_name, const char *feature_name);
> > 
> > interface allow us to at least clean things up a
> > little, and maybe allow us to isolate some of the
> > state back where it belongs ?
> > 
> 
> I think I'm back to b) with this, as:
> - There's no way to really hide this special flush behavior, as aapl
> mode affects how you parse packets.
> - Even if there was a way, the abstraction is wrong - you don't ask your
> file system how to interpret packets.
> 
> So, with this flush I would have a *global* (smbd_server_connection)
> flag that we're running AAPL, and maybe move AAPL parsing from vfs_fruit
> to smb layer, make it a first citizen. Making it global serves two things:
> 1. Keeps files_struct from bloating
> 2. More correct as AAPL mode is global

I tend to agree.

> For file index, I would *remove* the global aapl_zero_file_id flag, and
> hide *that* in the VFS (SMB_VFS_GET_FILE_ID), because it's a good
> abstraction with potential uses elsewhere.

+1

> So with this, I don't yet see a use case for VFS_QUERY_FEATURE()...

RIP. :)

Cheerio!
-slow