Best practice in building custom vfs modules

[Giampaolo Tomassoni]

> From: samba-technical-bounces at lists.samba.org [mailto:samba-technical-
> bounces at lists.samba.org] On Behalf Of Holger Hetterich
> 
> Beware, vscan is currently not in a compile able state against the
> current VFS api, and probably will never be, as Rainer Link and me are
> working on a new implementation, that is as simplified as possible from
> the VFS POV, and should be much easier to maintain in future.

I'm just looking at the aclocal/autoheader/automake/autoconf stuff, in the
hope to steal some knowledge about tracking samba's VFS includes. No need to
have a working vscan here.


> > In my case it would be like shooting to sparrows with a cannon... :)
> 
> That depends. By maintaining a version of your module for the samba
> master tree (be it even upstream or not), it's relativly easy to stay
> on track, once you have the code running based on the newest source.
> And once you have backported a version of the code to the samba version
> you are targetting, it's easy to bring back changes you made,
> down to this version. I then provide my client a completely packaged
> samba containing this module. (e.g. through the openSUSE Buildservice).

The total number of sites actually using this module is: 1. It is a really
trivial module: a virtual directory tree made by specific rows in a
postgresql db, each containing "real" files identified again by rows in the
db. The problem is that nobody else would probably have any need of this
very custom module, after all.

I like to keep my client's systems up-to-date, this is the problem. I
probably have to quit my habits in this case... ;)

Anyway, if this thing gets too complicated to handle, I have the option to
switch to a os-level vfs using fuse, then share its content via samba. I
loved the fast response time of the custom samba module solution, but fuse
seems a bit more strong with respect to source and binary
backward-compatibility. Upgrades probably are less complex there.


> > I guess however that we are not the only two persons to develop a
> > custom vfs for samba, so maybe also the samba team may find useful
> > to somehow "externalize" the includes needed to build a vfs. I
> > think it should be possible.
> 
> I think it should be possible, it just isn't in my focus currently.

It's ok: I didn't even mind you mint to do it. :)

I'm used to contribute to OSF projects when I have any clue about how to do
something. Unfortunately, in this case I don't. I don't have any knowledge
about the actual samba include tree, nor about any future direction the
developing team choose to follow, so I can't go too far from stating what I
would like to have. Simply this.


> > What about posting a feature request?
> >
> 
> Do it.

I just placed bug#7440 (https://bugzilla.samba.org/show_bug.cgi?id=7440)
with respect to the 3.4 samba tree: my distro (gentoo) actually ships 3.4.6.
It seems I have no way to place a feature request in a version-independent
manner.

> Maybe I am totally wrong and a nice way to build external
> modules already exists.

I would hope so, but I guess there isn't: the samba source package doesn't
seem to install any needed include to me.

We will see. Thank you again, Holger.

Giampaolo