1
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�10.�VFS Modules</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="SAMBA Developers Guide"><link rel="up" href="pt03.html" title="Part�III.�Samba Subsystems"><link rel="prev" href="rpc-plugin.html" title="Chapter�9.�RPC Pluggable Modules"><link rel="next" href="parsing.html" title="Chapter�11.�The smb.conf file"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�10.�VFS Modules</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="rpc-plugin.html">Prev</a>�</td><th width="60%" align="center">Part�III.�Samba Subsystems</th><td width="20%" align="right">�<a accesskey="n" href="parsing.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="vfs"></a>Chapter�10.�VFS Modules</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Alexander</span> <span class="surname">Bokovoy</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:ab@samba.org">ab@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Stefan</span> <span class="surname">Metzmacher</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:metze@samba.org">metze@samba.org</a>></code></p></div></div></div></div><div><p class="pubdate"> 27 May 2003 </p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="vfs.html#id2559076">The Samba (Posix) VFS layer</a></span></dt><dd><dl><dt><span class="sect2"><a href="vfs.html#id2559117">The general interface</a></span></dt><dt><span class="sect2"><a href="vfs.html#id2559428">Possible VFS operation layers</a></span></dt></dl></dd><dt><span class="sect1"><a href="vfs.html#id2559489">The Interaction between the Samba VFS subsystem and the modules</a></span></dt><dd><dl><dt><span class="sect2"><a href="vfs.html#id2559495">Initialization and registration</a></span></dt><dt><span class="sect2"><a href="vfs.html#id2559640">How the Modules handle per connection data</a></span></dt></dl></dd><dt><span class="sect1"><a href="vfs.html#id2559841">Upgrading to the New VFS Interface</a></span></dt><dd><dl><dt><span class="sect2"><a href="vfs.html#id2559847">Upgrading from 2.2.* and 3.0alpha modules</a></span></dt></dl></dd><dt><span class="sect1"><a href="vfs.html#id2560251">Some Notes</a></span></dt><dd><dl><dt><span class="sect2"><a href="vfs.html#id2560257">Implement TRANSPARENT functions</a></span></dt><dt><span class="sect2"><a href="vfs.html#id2560276">Implement OPAQUE functions</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2559076"></a>The Samba (Posix) VFS layer</h2></div></div></div><p>While most of Samba deployments are done using POSIX-compatible
2
operating systems, there is clearly more to a file system than what is
3
required by POSIX when it comes to adopting semantics of NT file
4
system. Since Samba 2.2 all file-system related operations go through
5
an abstraction layer for virtual file system (VFS) that is modelled
6
after both POSIX and additional functions needed to transform NTFS
9
This abstraction layer now provides more features than a regular POSIX
10
file system could fill in. It is not required that all of them should
11
be implemented by your particular file system. However, when those
12
features are available, Samba would advertize them to a CIFS client
13
and they might be used by an application and in case of Windows client
14
that might mean a client expects even more additional functionality
15
when it encounters those features. There is a practical reason to
16
allow handling of this snowfall without modifying the Samba core and
17
it is fulfilled by providing an infrastructure to dynamically load VFS
19
</p><p>Each VFS module could implement a number of VFS operations. The
20
way it does it is irrelevant, only two things actually matter: whether
21
specific implementation wants to cooperate with other modules'
22
implementations or not, and whether module needs to store additional
23
information that is specific to a context it is operating in. Multiple
24
VFS modules could be loaded at the same time and it is even possible
25
to load several instances of the same VFS module with different
27
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2559117"></a>The general interface</h3></div></div></div><p>A VFS module has three major components:
28
</p><div class="itemizedlist"><ul type="disc"><li><span class="emphasis"><em>An initialization function</em></span> that is
29
called during the module load to register implemented
30
operations.</li><li><span class="emphasis"><em>An operations table</em></span> representing a
31
mapping between statically defined module functions and VFS layer
32
operations.</li><li><span class="emphasis"><em>Module functions</em></span> that do actual
33
work.</li></ul></div><p>
34
</p><p>While this structure has been first applied to the VFS
35
subsystem, it is now commonly used across all Samba 3 subsystems that
36
support loadable modules. In fact, one module could provide a number
37
of interfaces to different subsystems by exposing different
38
<span class="emphasis"><em>operation tables</em></span> through separate
39
<span class="emphasis"><em>initialization functions</em></span>.</p><p><span class="emphasis"><em>An initialization function</em></span> is used to
40
register module with Samba run-time. As Samba internal structures and
41
API are changed over lifetime, each released version has a VFS
42
interface version that is increased as VFS development progresses or
43
any of underlying Samba structures are changed in binary-incompatible
44
way. When VFS module is compiled in, VFS interface version of that
45
Samba environment is embedded into the module's binary object and is
46
checked by the Samba core upon module load. If VFS interface number
47
reported by the module isn't the same Samba core knows about, version
48
conflict is detected and module dropped to avoid any potential memory
49
corruption when accessing (changed) Samba structures.
50
</p><p>Therefore, initialization function passes three parameters to the
51
VFS registration function, <code class="literal">smb_register_vfs()</code>
52
</p><div class="itemizedlist"><ul type="disc"><li><span class="emphasis"><em>interface version number</em></span>, as constant
53
<code class="literal">SMB_VFS_INTERFACE_VERSION</code>, </li><li><span class="emphasis"><em>module name</em></span>, under which Samba core
54
will know it, and</li><li><span class="emphasis"><em>an operations' table</em></span>.</li></ul></div><p>
55
</p><p>The <span class="emphasis"><em>operations' table</em></span> defines which
56
functions in the module would correspond to specific VFS operations
57
and how those functions would co-operate with the rest of VFS
58
subsystem. Each operation could perform in a following ways:
59
</p><div class="itemizedlist"><ul type="disc"><li><span class="emphasis"><em>transparent</em></span>, meaning that while
60
operation is overriden, the module will still call a previous
61
implementation, before or after its own action. This mode is
62
indicated by the constant
63
<code class="literal">SMB_VFS_LAYER_TRANSPARENT</code>;
64
</li><li><span class="emphasis"><em>opaque</em></span>, for the implementations that
65
are terminating sequence of actions. For example, it is used to
66
implement POSIX operation on top of non-POSIX file system or even
67
not a file system at all, like a database for a personal audio
68
collection. Use constant <code class="literal">SMB_VFS_LAYER_OPAQUE</code> for
69
this mode;</li><li><span class="emphasis"><em>splitter</em></span>, a way when some file system
70
activity is done in addition to the transparently calling previous
71
implentation. This usually involves mangling the result of that call
72
before returning it back to the caller. This mode is selected by
73
<code class="literal">SMB_VFS_LAYER_SPLITTER</code> constant;</li><li><span class="emphasis"><em>logger</em></span> does not change anything or
74
performs any additional VFS operations. When
75
<span class="emphasis"><em>logger</em></span> module acts, information about
76
operations is logged somewhere using an external facility (or
77
Samba's own debugging tools) but not the VFS layer. In order to
78
describe this type of activity use constant
79
<code class="literal">SMB_VFS_LAYER_LOGGER</code>;
80
</li><li>On contrary, <span class="emphasis"><em>scanner</em></span> module does call
81
other VFS operations while processing the data that goes through the
82
system. This type of operation is indicated by the
83
<code class="literal">SMB_VFS_LAYER_SCANNER</code> constant.</li></ul></div><p>
84
</p><p>Fundamentally, there are three types:
85
<span class="emphasis"><em>transparent</em></span>, <span class="emphasis"><em>opaque</em></span>, and
86
<span class="emphasis"><em>logger</em></span>. <span class="emphasis"><em>Splitter</em></span> and
87
<span class="emphasis"><em>scanner</em></span> may confuse developers (and indeed they
88
are confused as our experience has shown) but this separation is to
89
better expose the nature of a module's actions. Most of modules
90
developed so far are either one of those three fundamental types with
91
transparent and opaque being prevalent.
93
Each VFS operation has a vfs_op_type, a function pointer and a handle
94
pointer in the struct vfs_ops and tree macros to make it easier to
95
call the operations. (Take a look at
96
<code class="filename">include/vfs.h</code> and
97
<code class="filename">include/vfs_macros.h</code>.)
98
</p><pre class="programlisting">
99
typedef enum _vfs_op_type {
100
SMB_VFS_OP_NOOP = -1,
104
/* File operations */
117
</pre><p>This struct contains the function and handle pointers for all operations.</p><pre class="programlisting">
119
struct vfs_fn_pointers {
122
/* File operations */
124
int (*open)(struct vfs_handle_struct *handle,
125
struct connection_struct *conn,
126
const char *fname, int flags, mode_t mode);
127
int (*close)(struct vfs_handle_struct *handle,
128
struct files_struct *fsp, int fd);
129
ssize_t (*read)(struct vfs_handle_struct *handle,
130
struct files_struct *fsp, int fd, void *data, size_t n);
131
ssize_t (*write)(struct vfs_handle_struct *handle,
132
struct files_struct *fsp, int fd,
133
const void *data, size_t n);
134
SMB_OFF_T (*lseek)(struct vfs_handle_struct *handle,
135
struct files_struct *fsp, int fd,
136
SMB_OFF_T offset, int whence);
137
ssize_t (*sendfile)(struct vfs_handle_struct *handle,
138
int tofd, files_struct *fsp, int fromfd,
139
const DATA_BLOB *header, SMB_OFF_T offset, size_t count);
144
struct vfs_handles_pointers {
147
/* File operations */
149
struct vfs_handle_struct *open;
150
struct vfs_handle_struct *close;
151
struct vfs_handle_struct *read;
152
struct vfs_handle_struct *write;
153
struct vfs_handle_struct *lseek;
154
struct vfs_handle_struct *sendfile;
160
This macros SHOULD be used to call any vfs operation.
161
DO NOT ACCESS conn->vfs.ops.* directly !!!
162
</p><pre class="programlisting">
165
/* File operations */
166
#define SMB_VFS_OPEN(conn, fname, flags, mode) \
167
((conn)->vfs.ops.open((conn)->vfs.handles.open,\
168
(conn), (fname), (flags), (mode)))
169
#define SMB_VFS_CLOSE(fsp, fd) \
170
((fsp)->conn->vfs.ops.close(\
171
(fsp)->conn->vfs.handles.close, (fsp), (fd)))
172
#define SMB_VFS_READ(fsp, fd, data, n) \
173
((fsp)->conn->vfs.ops.read(\
174
(fsp)->conn->vfs.handles.read,\
175
(fsp), (fd), (data), (n)))
176
#define SMB_VFS_WRITE(fsp, fd, data, n) \
177
((fsp)->conn->vfs.ops.write(\
178
(fsp)->conn->vfs.handles.write,\
179
(fsp), (fd), (data), (n)))
180
#define SMB_VFS_LSEEK(fsp, fd, offset, whence) \
181
((fsp)->conn->vfs.ops.lseek(\
182
(fsp)->conn->vfs.handles.lseek,\
183
(fsp), (fd), (offset), (whence)))
184
#define SMB_VFS_SENDFILE(tofd, fsp, fromfd, header, offset, count) \
185
((fsp)->conn->vfs.ops.sendfile(\
186
(fsp)->conn->vfs.handles.sendfile,\
187
(tofd), (fsp), (fromfd), (header), (offset), (count)))
190
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2559428"></a>Possible VFS operation layers</h3></div></div></div><p>
191
These values are used by the VFS subsystem when building the conn->vfs
192
and conn->vfs_opaque structs for a connection with multiple VFS modules.
193
Internally, Samba differentiates only opaque and transparent layers at this process.
194
Other types are used for providing better diagnosing facilities.
196
Most modules will provide transparent layers. Opaque layer is for modules
197
which implement actual file system calls (like DB-based VFS). For example,
198
default POSIX VFS which is built in into Samba is an opaque VFS module.
200
Other layer types (logger, splitter, scanner) were designed to provide different
201
degree of transparency and for diagnosing VFS module behaviour.
203
Each module can implement several layers at the same time provided that only
204
one layer is used per each operation.
205
</p><pre class="programlisting">
206
typedef enum _vfs_op_layer {
207
SMB_VFS_LAYER_NOOP = -1, /* - For using in VFS module to indicate end of array */
208
/* of operations description */
209
SMB_VFS_LAYER_OPAQUE = 0, /* - Final level, does not call anything beyond itself */
210
SMB_VFS_LAYER_TRANSPARENT, /* - Normal operation, calls underlying layer after */
211
/* possibly changing passed data */
212
SMB_VFS_LAYER_LOGGER, /* - Logs data, calls underlying layer, logging may not */
214
SMB_VFS_LAYER_SPLITTER, /* - Splits operation, calls underlying layer _and_ own facility, */
215
/* then combines result */
216
SMB_VFS_LAYER_SCANNER /* - Checks data and possibly initiates additional */
217
/* file activity like logging to files _inside_ samba VFS */
219
</pre></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2559489"></a>The Interaction between the Samba VFS subsystem and the modules</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2559495"></a>Initialization and registration</h3></div></div></div><p>
220
As each Samba module a VFS module should have a
221
</p><pre class="programlisting">NTSTATUS vfs_example_init(void);</pre><p> function if it's staticly linked to samba or
222
</p><pre class="programlisting">NTSTATUS init_module(void);</pre><p> function if it's a shared module.
224
This should be the only non static function inside the module.
225
Global variables should also be static!
227
The module should register its functions via the
228
</p><pre class="programlisting">
229
NTSTATUS smb_register_vfs(int version, const char *name, vfs_op_tuple *vfs_op_tuples);
231
</p><div class="variablelist"><dl><dt><span class="term">version</span></dt><dd><p>should be filled with SMB_VFS_INTERFACE_VERSION</p></dd><dt><span class="term">name</span></dt><dd><p>this is the name witch can be listed in the
232
<code class="literal">vfs objects</code> parameter to use this module.</p></dd><dt><span class="term">vfs_op_tuples</span></dt><dd><p>
233
this is an array of vfs_op_tuple's.
234
(vfs_op_tuples is descripted in details below.)
235
</p></dd></dl></div><p>
236
For each operation the module wants to provide it has a entry in the
238
</p><pre class="programlisting">
239
typedef struct _vfs_op_tuple {
244
</pre><div class="variablelist"><dl><dt><span class="term">op</span></dt><dd><p>the function pointer to the specified function.</p></dd><dt><span class="term">type</span></dt><dd><p>the vfs_op_type of the function to specified witch operation the function provides.</p></dd><dt><span class="term">layer</span></dt><dd><p>the vfs_op_layer in whitch the function operates.</p></dd></dl></div><p>A simple example:</p><pre class="programlisting">
245
static vfs_op_tuple example_op_tuples[] = {
246
{SMB_VFS_OP(example_connect), SMB_VFS_OP_CONNECT, SMB_VFS_LAYER_TRANSPARENT},
247
{SMB_VFS_OP(example_disconnect), SMB_VFS_OP_DISCONNECT, SMB_VFS_LAYER_TRANSPARENT},
249
{SMB_VFS_OP(example_rename), SMB_VFS_OP_RENAME, SMB_VFS_LAYER_OPAQUE},
251
/* This indicates the end of the array */
252
{SMB_VFS_OP(NULL), SMB_VFS_OP_NOOP, SMB_VFS_LAYER_NOOP}
255
NTSTATUS init_module(void)
257
return smb_register_vfs(SMB_VFS_INTERFACE_VERSION, "example", example_op_tuples);
259
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2559640"></a>How the Modules handle per connection data</h3></div></div></div><p>Each VFS function has as first parameter a pointer to the modules vfs_handle_struct.
260
</p><pre class="programlisting">
261
typedef struct vfs_handle_struct {
262
struct vfs_handle_struct *next, *prev;
264
struct vfs_ops vfs_next;
265
struct connection_struct *conn;
267
void (*free_data)(void **data);
269
</pre><div class="variablelist"><dl><dt><span class="term">param</span></dt><dd><p>this is the module parameter specified in the <code class="literal">vfs objects</code> parameter.</p><p>e.g. for 'vfs objects = example:test' param would be "test".</p></dd><dt><span class="term">vfs_next</span></dt><dd><p>This vfs_ops struct contains the information for calling the next module operations.
270
Use the SMB_VFS_NEXT_* macros to call a next module operations and
271
don't access handle->vfs_next.ops.* directly!</p></dd><dt><span class="term">conn</span></dt><dd><p>This is a pointer back to the connection_struct to witch the handle belongs.</p></dd><dt><span class="term">data</span></dt><dd><p>This is a pointer for holding module private data.
272
You can alloc data with connection life time on the handle->conn->mem_ctx TALLOC_CTX.
273
But you can also manage the memory allocation yourself.</p></dd><dt><span class="term">free_data</span></dt><dd><p>This is a function pointer to a function that free's the module private data.
274
If you talloc your private data on the TALLOC_CTX handle->conn->mem_ctx,
275
you can set this function pointer to NULL.</p></dd></dl></div><p>Some useful MACROS for handle private data.
276
</p><pre class="programlisting">
277
#define SMB_VFS_HANDLE_GET_DATA(handle, datap, type, ret) { \
278
if (!(handle)||((datap=(type *)(handle)->data)==NULL)) { \
279
DEBUG(0,("%s() failed to get vfs_handle->data!\n",FUNCTION_MACRO)); \
284
#define SMB_VFS_HANDLE_SET_DATA(handle, datap, free_fn, type, ret) { \
286
DEBUG(0,("%s() failed to set handle->data!\n",FUNCTION_MACRO)); \
289
if ((handle)->free_data) { \
290
(handle)->free_data(&(handle)->data); \
292
(handle)->data = (void *)datap; \
293
(handle)->free_data = free_fn; \
297
#define SMB_VFS_HANDLE_FREE_DATA(handle) { \
298
if ((handle) && (handle)->free_data) { \
299
(handle)->free_data(&(handle)->data); \
302
</pre><p>How SMB_VFS_LAYER_TRANSPARENT functions can call the SMB_VFS_LAYER_OPAQUE functions.</p><p>The easiest way to do this is to use the SMB_VFS_OPAQUE_* macros.
303
</p><pre class="programlisting">
305
/* File operations */
306
#define SMB_VFS_OPAQUE_OPEN(conn, fname, flags, mode) \
307
((conn)->vfs_opaque.ops.open(\
308
(conn)->vfs_opaque.handles.open,\
309
(conn), (fname), (flags), (mode)))
310
#define SMB_VFS_OPAQUE_CLOSE(fsp, fd) \
311
((fsp)->conn->vfs_opaque.ops.close(\
312
(fsp)->conn->vfs_opaque.handles.close,\
314
#define SMB_VFS_OPAQUE_READ(fsp, fd, data, n) \
315
((fsp)->conn->vfs_opaque.ops.read(\
316
(fsp)->conn->vfs_opaque.handles.read,\
317
(fsp), (fd), (data), (n)))
318
#define SMB_VFS_OPAQUE_WRITE(fsp, fd, data, n) \
319
((fsp)->conn->vfs_opaque.ops.write(\
320
(fsp)->conn->vfs_opaque.handles.write,\
321
(fsp), (fd), (data), (n)))
322
#define SMB_VFS_OPAQUE_LSEEK(fsp, fd, offset, whence) \
323
((fsp)->conn->vfs_opaque.ops.lseek(\
324
(fsp)->conn->vfs_opaque.handles.lseek,\
325
(fsp), (fd), (offset), (whence)))
326
#define SMB_VFS_OPAQUE_SENDFILE(tofd, fsp, fromfd, header, offset, count) \
327
((fsp)->conn->vfs_opaque.ops.sendfile(\
328
(fsp)->conn->vfs_opaque.handles.sendfile,\
329
(tofd), (fsp), (fromfd), (header), (offset), (count)))
331
</pre><p>How SMB_VFS_LAYER_TRANSPARENT functions can call the next modules functions.</p><p>The easiest way to do this is to use the SMB_VFS_NEXT_* macros.
332
</p><pre class="programlisting">
334
/* File operations */
335
#define SMB_VFS_NEXT_OPEN(handle, conn, fname, flags, mode) \
336
((handle)->vfs_next.ops.open(\
337
(handle)->vfs_next.handles.open,\
338
(conn), (fname), (flags), (mode)))
339
#define SMB_VFS_NEXT_CLOSE(handle, fsp, fd) \
340
((handle)->vfs_next.ops.close(\
341
(handle)->vfs_next.handles.close,\
343
#define SMB_VFS_NEXT_READ(handle, fsp, fd, data, n) \
344
((handle)->vfs_next.ops.read(\
345
(handle)->vfs_next.handles.read,\
346
(fsp), (fd), (data), (n)))
347
#define SMB_VFS_NEXT_WRITE(handle, fsp, fd, data, n) \
348
((handle)->vfs_next.ops.write(\
349
(handle)->vfs_next.handles.write,\
350
(fsp), (fd), (data), (n)))
351
#define SMB_VFS_NEXT_LSEEK(handle, fsp, fd, offset, whence) \
352
((handle)->vfs_next.ops.lseek(\
353
(handle)->vfs_next.handles.lseek,\
354
(fsp), (fd), (offset), (whence)))
355
#define SMB_VFS_NEXT_SENDFILE(handle, tofd, fsp, fromfd, header, offset, count) \
356
((handle)->vfs_next.ops.sendfile(\
357
(handle)->vfs_next.handles.sendfile,\
358
(tofd), (fsp), (fromfd), (header), (offset), (count)))
360
</pre></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2559841"></a>Upgrading to the New VFS Interface</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2559847"></a>Upgrading from 2.2.* and 3.0alpha modules</h3></div></div></div><div class="orderedlist"><ol type="1"><li><p>
361
Add "vfs_handle_struct *handle, " as first parameter to all vfs operation functions.
362
e.g. example_connect(connection_struct *conn, const char *service, const char *user);
363
-> example_connect(vfs_handle_struct *handle, connection_struct *conn, const char *service, const char *user);
365
Replace "default_vfs_ops." with "smb_vfs_next_".
366
e.g. default_vfs_ops.connect(conn, service, user);
367
-> smb_vfs_next_connect(conn, service, user);
369
Uppercase all "smb_vfs_next_*" functions.
370
e.g. smb_vfs_next_connect(conn, service, user);
371
-> SMB_VFS_NEXT_CONNECT(conn, service, user);
373
Add "handle, " as first parameter to all SMB_VFS_NEXT_*() calls.
374
e.g. SMB_VFS_NEXT_CONNECT(conn, service, user);
375
-> SMB_VFS_NEXT_CONNECT(handle, conn, service, user);
377
(Only for 2.2.* modules)
378
Convert the old struct vfs_ops example_ops to
379
a vfs_op_tuple example_op_tuples[] array.
381
</p><pre class="programlisting">
382
struct vfs_ops example_ops = {
383
/* Disk operations */
384
example_connect, /* connect */
385
example_disconnect, /* disconnect */
387
/* Directory operations */
393
/* File operations */
402
example_stat, /* stat */
403
example_fstat, /* fstat */
404
example_lstat, /* lstat */
413
NULL, /* ftruncate */
420
NULL, /* fget_nt_acl */
421
NULL, /* get_nt_acl */
422
NULL, /* fset_nt_acl */
423
NULL, /* set_nt_acl */
425
NULL, /* chmod_acl */
426
NULL, /* fchmod_acl */
428
NULL, /* sys_acl_get_entry */
429
NULL, /* sys_acl_get_tag_type */
430
NULL, /* sys_acl_get_permset */
431
NULL, /* sys_acl_get_qualifier */
432
NULL, /* sys_acl_get_file */
433
NULL, /* sys_acl_get_fd */
434
NULL, /* sys_acl_clear_perms */
435
NULL, /* sys_acl_add_perm */
436
NULL, /* sys_acl_to_text */
437
NULL, /* sys_acl_init */
438
NULL, /* sys_acl_create_entry */
439
NULL, /* sys_acl_set_tag_type */
440
NULL, /* sys_acl_set_qualifier */
441
NULL, /* sys_acl_set_permset */
442
NULL, /* sys_acl_valid */
443
NULL, /* sys_acl_set_file */
444
NULL, /* sys_acl_set_fd */
445
NULL, /* sys_acl_delete_def_file */
446
NULL, /* sys_acl_get_perm */
447
NULL, /* sys_acl_free_text */
448
NULL, /* sys_acl_free_acl */
449
NULL /* sys_acl_free_qualifier */
453
</p><pre class="programlisting">
454
static vfs_op_tuple example_op_tuples[] = {
455
{SMB_VFS_OP(example_connect), SMB_VFS_OP_CONNECT, SMB_VFS_LAYER_TRANSPARENT},
456
{SMB_VFS_OP(example_disconnect), SMB_VFS_OP_DISCONNECT, SMB_VFS_LAYER_TRANSPARENT},
458
{SMB_VFS_OP(example_fstat), SMB_VFS_OP_FSTAT, SMB_VFS_LAYER_TRANSPARENT},
459
{SMB_VFS_OP(example_stat), SMB_VFS_OP_STAT, SMB_VFS_LAYER_TRANSPARENT},
460
{SMB_VFS_OP(example_lstat), SMB_VFS_OP_LSTAT, SMB_VFS_LAYER_TRANSPARENT},
462
{SMB_VFS_OP(NULL), SMB_VFS_OP_NOOP, SMB_VFS_LAYER_NOOP}
466
Move the example_op_tuples[] array to the end of the file.
468
Add the init_module() function at the end of the file.
470
</p><pre class="programlisting">
471
NTSTATUS init_module(void)
473
return smb_register_vfs(SMB_VFS_INTERFACE_VERSION,"example",example_op_tuples);
477
Check if your vfs_init() function does more then just prepare the vfs_ops structs or
478
remember the struct smb_vfs_handle_struct.
479
</p><table class="simplelist" border="0" summary="Simple list"><tr><td>If NOT you can remove the vfs_init() function.</td></tr><tr><td>If YES decide if you want to move the code to the example_connect() operation or to the init_module(). And then remove vfs_init().
480
e.g. a debug class registration should go into init_module() and the allocation of private data should go to example_connect().</td></tr></table><p>
482
(Only for 3.0alpha* modules)
483
Check if your vfs_done() function contains needed code.
484
</p><table class="simplelist" border="0" summary="Simple list"><tr><td>If NOT you can remove the vfs_done() function.</td></tr><tr><td>If YES decide if you can move the code to the example_disconnect() operation. Otherwise register a SMB_EXIT_EVENT with smb_register_exit_event(); (Described in the <a class="link" href="modules.html" title="Chapter�8.�Modules">modules section</a>) And then remove vfs_done(). e.g. the freeing of private data should go to example_disconnect().
485
</td></tr></table><p>
487
Check if you have any global variables left.
488
Decide if it wouldn't be better to have this data on a connection basis.
489
</p><table class="simplelist" border="0" summary="Simple list"><tr><td>If NOT leave them as they are. (e.g. this could be the variable for the private debug class.)</td></tr><tr><td>If YES pack all this data into a struct. You can use handle->data to point to such a struct on a per connection basis.</td></tr></table><p>
491
e.g. if you have such a struct:
492
</p><pre class="programlisting">
493
struct example_privates {
498
first way of doing it:
499
</p><pre class="programlisting">
500
static int example_connect(vfs_handle_struct *handle,
501
connection_struct *conn, const char *service,
504
struct example_privates *data = NULL;
506
/* alloc our private data */
507
data = (struct example_privates *)talloc_zero(conn->mem_ctx, sizeof(struct example_privates));
509
DEBUG(0,("talloc_zero() failed\n"));
513
/* init out private data */
514
data->some_string = talloc_strdup(conn->mem_ctx,"test");
515
if (!data->some_string) {
516
DEBUG(0,("talloc_strdup() failed\n"));
520
data->db_connection = open_db_conn();
522
/* and now store the private data pointer in handle->data
523
* we don't need to specify a free_function here because
524
* we use the connection TALLOC context.
525
* (return -1 if something failed.)
527
VFS_HANDLE_SET_DATA(handle, data, NULL, struct example_privates, return -1);
529
return SMB_VFS_NEXT_CONNECT(handle,conn,service,user);
532
static int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd)
534
struct example_privates *data = NULL;
536
/* get the pointer to our private data
537
* return -1 if something failed
539
SMB_VFS_HANDLE_GET_DATA(handle, data, struct example_privates, return -1);
541
/* do something here...*/
542
DEBUG(0,("some_string: %s\n",data->some_string));
544
return SMB_VFS_NEXT_CLOSE(handle, fsp, fd);
547
second way of doing it:
548
</p><pre class="programlisting">
549
static void free_example_privates(void **datap)
551
struct example_privates *data = (struct example_privates *)*datap;
553
SAFE_FREE(data->some_string);
561
static int example_connect(vfs_handle_struct *handle,
562
connection_struct *conn, const char *service,
565
struct example_privates *data = NULL;
567
/* alloc our private data */
568
data = (struct example_privates *)malloc(sizeof(struct example_privates));
570
DEBUG(0,("malloc() failed\n"));
574
/* init out private data */
575
data->some_string = strdup("test");
576
if (!data->some_string) {
577
DEBUG(0,("strdup() failed\n"));
581
data->db_connection = open_db_conn();
583
/* and now store the private data pointer in handle->data
584
* we need to specify a free_function because we used malloc() and strdup().
585
* (return -1 if something failed.)
587
SMB_VFS_HANDLE_SET_DATA(handle, data, free_example_privates, struct example_privates, return -1);
589
return SMB_VFS_NEXT_CONNECT(handle,conn,service,user);
592
static int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd)
594
struct example_privates *data = NULL;
596
/* get the pointer to our private data
597
* return -1 if something failed
599
SMB_VFS_HANDLE_GET_DATA(handle, data, struct example_privates, return -1);
601
/* do something here...*/
602
DEBUG(0,("some_string: %s\n",data->some_string));
604
return SMB_VFS_NEXT_CLOSE(handle, fsp, fd);
608
To make it easy to build 3rd party modules it would be useful to provide
609
configure.in, (configure), install.sh and Makefile.in with the module.
610
(Take a look at the example in <code class="filename">examples/VFS</code>.)
612
The configure script accepts <code class="option">--with-samba-source</code> to specify
613
the path to the samba source tree.
614
It also accept <code class="option">--enable-developer</code> which lets the compiler
615
give you more warnings.
617
The idea is that you can extend this
618
<code class="filename">configure.in</code> and <code class="filename">Makefile.in</code> scripts
621
Compiling & Testing...
622
</p><table class="simplelist" border="0" summary="Simple list"><tr><td><strong class="userinput"><code>./configure <code class="option">--enable-developer</code></code></strong> ...</td></tr><tr><td><strong class="userinput"><code>make</code></strong></td></tr><tr><td>Try to fix all compiler warnings</td></tr><tr><td><strong class="userinput"><code>make</code></strong></td></tr><tr><td>Testing, Testing, Testing ...</td></tr></table><p>
623
</p></li></ol></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2560251"></a>Some Notes</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2560257"></a>Implement TRANSPARENT functions</h3></div></div></div><p>
624
Avoid writing functions like this:
626
</p><pre class="programlisting">
627
static int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd)
629
return SMB_VFS_NEXT_CLOSE(handle, fsp, fd);
633
Overload only the functions you really need to!
634
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2560276"></a>Implement OPAQUE functions</h3></div></div></div><p>
635
If you want to just implement a better version of a
636
default samba opaque function
637
(e.g. like a disk_free() function for a special filesystem)
638
it's ok to just overload that specific function.
640
If you want to implement a database filesystem or
641
something different from a posix filesystem.
642
Make sure that you overload every vfs operation!!!
644
Functions your FS does not support should be overloaded by something like this:
645
e.g. for a readonly filesystem.
646
</p><pre class="programlisting">
647
static int example_rename(vfs_handle_struct *handle, connection_struct *conn,
648
char *oldname, char *newname)
650
DEBUG(10,("function rename() not allowed on vfs 'example'\n"));
654
</pre></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="rpc-plugin.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="pt03.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="parsing.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter�9.�RPC Pluggable Modules�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Chapter�11.�The smb.conf file</td></tr></table></div></body></html>
added
removed
docs/htmldocs/Samba3-Developers-Guide/vfs.html
