Developing a VFS plugin for inhouse backup solution

Stefan (metze) Metzmacher metze at
Mon Feb 14 07:42:02 GMT 2005

Hash: SHA1

Alexander Bokovoy schrieb:
| 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.
|>>>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.

I know as I wrote this code:-)

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
| infrastructure.
| It simply does not make sense to duplicate infrastructures.

- --

Stefan Metzmacher <metze at>
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird -


More information about the samba-technical mailing list