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

[Omri Mor]

> On Jul 18, 2017, at 23:22, Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> 
>> On Tue, Jul 18, 2017 at 10:43:11PM +0200, Volker Lendecke via samba-technical wrote:
>> I guess that's too late, we need to produce this list when we start and register
>> the services.
> 
> We can never change announcements again once they were done?
> 
> Volker
> 
> -- 
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de

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

This is unfortunate; otherwise we could iterate through all shares in fruit_init() and register the service for each share that has fruit:time machine = yes.
This probably means that we either need to set up the service later, force vfs_fruit to be loaded earlier if it’s used, or parse the fruit:time machine option outside of vfs_fruit, none of which seem to be appealing options.

Omri