Hello

[Andrew Tridgell]

> Hello everyone.  Following a chat with tridge I've taken on the task of
> writing a VFS interface to samba.  Basically, this will allow someone to
> write a set of open/read/write etc routines that will dereference all the
> filesystem calls smbd makes to actually read and write files.  Loadable
> module support is planned.

yep, this will be very nice. One of the reasons I like it is that it
will force a cleanup in Samba of a distinction between file operations
in response to an SMB request and file operations internal to Samba. 

What I discussed with Tim was the creation of a vfs_operations
structure containing functions pointers for all the different file
operations (open, read, write, stat etc) and then having a pointer to
this structure in the connection structure. Then we would have changes
like:

  if (n > 0) {
    readret = read(fsp->fd_ptr->fd,data,n);
    if (readret > 0) ret += readret;
  }

becoming:

  if (n > 0) {
    readret = fsp->conn->vfs_ops->read(fsp->fd_ptr->fd,data,n);
    if (readret > 0) ret += readret;
  }

in read_file().

> The goal is to write a SMB interface to a tape storage robot so we can
> stream data from a mpeg-2 encoder (an "embedded" nt box) straight onto
> tape without having to muck around with disks.

I also imagine it being used for:

1) cleaner handling of read/write on pipes. The vfs_ops structure
   would be different on a IPC$ connection and would point at pipe
   specific IO routines.

2) cleaner handling of printers. For example the auto-postscript
   conversion would be much cleaner.

3) a clean way of finally doing CR/LF translation 

4) interfaces to things like SQL databases 

If we get really ambitious we could even present remote smb.conf
editing as filesystem operations. A directory per share and a file per
option. Creating a share would be done with mkdir. That's probably
just a crazy idea :-)

I've given Tim CVS write access but I don't expect any of this stuff
will go into the 2.0 release. Maybe 2.1?