Developing a VFS plugin for inhouse backup solution

Alexander Bokovoy ab at
Sun Feb 13 12:29:41 GMT 2005

On Sun, Feb 13, 2005 at 12:11:15PM +0100, Stefan (metze) Metzmacher wrote:
> > On Sat, Feb 12, 2005 at 10:06:02PM -0800, Jeremy Allison wrote:
> >> On Sat, Feb 12, 2005 at 05:12:46PM -0800, Brian Gunlogson wrote:
> >> > Inside my VFS SMB_VFS_OP_OPEN I want to store per-file data. The data
> >> needs to be accessible when
> >> > SMB_VFS_OP_CLOSE is called. Where (in what structure) should per-file
> >> data be stored?
> >>
> >> This is a bug in Samba really. We should have a "private" data pointer
> >> available in the files_struct and the connection_struct for VFS use.
> >> I'll
> >> fix this for 3.0.12.
> > We do have it already in vfs_handle_struct. Each VFS functions gets a
> > handle specific to particular VFS module and can operate on data stored in
> > handle by SMB_VFS_HANDLE_XXX_DATA() macros.
> per file data can't be a simple void *private_data on the files_struct!
No, you miss my point.

We already provide modules with their own private data in
vfs_handle_struct. It doesn't matter for smbd how it is used by a module
and it is actually up to module to do everything needed. I don't think it
would very usefull to create and maintain in runtime infrastructure for linking 
opened files with a data private to a particular module unless such an
infrastructure is in general need for other smbd subsystems which is not
we are seeing so far except for locking.

However, a general infrastructure for referencing a particular filehandle
and getting a data associated with it in some subsystem would definitely
be good if everything else (like locking code) would re-use the same

It simply does not make sense to duplicate infrastructures.
/ Alexander Bokovoy
Samba Team            
ALT Linux Team        
Midgard Project Ry    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the samba-technical mailing list