vfs_fruit: Time Machine/FULLSYNC: add mDNS/DNS-SD advertisement

[Omri Mor]

> On Jul 19, 2017, at 00:25, Ralph Böhme <slow at samba.org> wrote:
> 
>> On Wed, Jul 19, 2017 at 12:04:42AM -0700, Omri Mor wrote:
>> They can be changed, but it’s more difficult (particularly with Avahi, it
>> seems). Since there really isn’t a reason for announcements to change as long
>> as share options aren’t changed, it’s probably best to stay simple and *not*
>> modify them.
>> 
>> I’m parsing through the code to figure out at what point VFS modules are
>> initialized. From my understanding, a module aren’t loaded and initialized
>> until there is a connection to a share that requires the module (i.e. lazy
>> loading): make_connection_snum() => smbd_vfs_init() => vfs_init_custom()
>> vfs_init_custom() => vfs_find_backend_entry(); if the module is already
>> loaded, this finds it and sets up the connection to use it, else =>
>> smb_load_module() => ... => load_module() => dlsym(), MODULE_init() =>
>> vfs_find_backend_entry(); loads the module, initializes it, and then sets up
>> the connection
> 
> afair: correct.
> 
> Setting "preload modules" should work, requires an absolute path to the
> module. Would that be good enough?
> 
> Cheerio!
> -slow

That seems like it would work, but we get somewhat of a chicken-and-egg problem: if a share sets fruit:time machine, then vfs_fruit would need to be preloaded, but ideally, module-specific options are ignored outside of that module.
Unless there are already instances of special core Samba behavior depending on module options?
If so, we could just implement the Time Machine advertisement directly in avahi_register.c / dnsregister.c for shares that set fruit:time machine. That would be dead-simple, I think, but encourages ‘bad’ module behavior.

Omri