VFS stuff (was Re: need undelete function)

[Tim Potter]

Andy Bakun writes:

> I am in total agreement on the scripting VFS module.  I've been
> getting requests to implement a bunch of things similar to my 'close
> command' patch (http://www.reac.com/samba/samba-closecmd.README),
> but I'm holding out until the VFS layer that was talked about a few
> months ago goes gold, because this is a more 'correct' way to do it,
> in my mind.  I'll use this post as a sounding board for some of my
> ideas. :) I havn't heard much about the VFS layer in a while; is it
> already in the 2.1 series?  Did the developer give up on it?  Who
> was working on it anyway?  I'd be willing to implement it if I
> wasn't duplicating work.  Tim, your post seems to indicate that VFS
> stuff is already written -- am I completely out of the loop?  Is
> there documentation for what's already written?

To answer your questions, the VFS layer has been merged into the head
branch (i.e samba 2.1) and some bugs that I didn't catch have been
found in typical open source (!tm) fashion thanks to Jean-Francois and
Matt Chapman.  If you're looking for documentation, there isn't
terribly much at the moment.  Check out $SAMBA_SRC/examples/VFS for a
skeleton VFS module and a module that audits file access to syslog.

Things that need doing are:

       - some more documentation
       - another layer to hide some of the complexity of working with
         a file descriptor I/O interface
       - vfs parameters
       - stackable VFS modules?

> I'd think that the VFS layer can be bound on a per-share basis, thusly:
> 
> [share]
>   path = /whatever
>   comment = my share
>   vfs link against = /usr/local/samba/lib/my-samba-vfs-layer.so

This is the way it works - the command is actually 'vfs object'.

> A 'execute script' shared lib could be provided for with the samba
> distribution.  In terms of giving the bound vfs layer configuration
> parameters, the conf file parsing code could be modified to take
> things of the form:
>   vfs link against = /path/to/so
>   {
>      vfs option one = x
>      vfs option two = x
>   }
> 

> I believe this would be easy to implement because the conf file
> parsing code could just skip over, and not process, things in
> braces; keeping the things in braces as plain text to pass to the

My idea was to have a token like 'vfs option' which was skipped over
by the option parser but passed to the vfs module as an array of char
* on init.  I think the braces can simply be left out as vfs options
are already easily detactable.

So that's where it's at.  A couple of people have expressed interested
in writing vfs modules.  There should be enough info in the examples
directory and the source code to get started on something if you're
keen.


Regards,

Tim.

>
> Andy.
> 

-- 
Tim Potter, System Admin/Programmer, Head Bee Guy
Advanced Computational Systems CRC, RSISE Bldg Australian National University,
Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602