Samba VFS: Is it really a Virtual File System API?
realrichardsharpe at gmail.com
Mon Oct 3 08:43:01 MDT 2011
On Mon, Oct 3, 2011 at 7:31 AM, Sergio Conde <sconde at dilmun.ls.fi.upm.es> wrote:
> On 03/10/11 16:19, Richard Sharpe wrote:
>> On Mon, Oct 3, 2011 at 6:53 AM, Sergio Conde<sconde at dilmun.ls.fi.upm.es>
>>> I have some questions to begin with (and considering I have not started
>>> designing my module):
>>> Using opaque, should I make functional all the functions? Because there
>>> some of them that I can't implement due provider API restriction (Such as
>>> all acl related functions, symlinks, chmod, maybe lseek. Other problem is
>>> that open/close are nonsense because I can only read and write).
>>> If I should implement all functions, will do the trick returning "OK it
>>> well" and doing nothing?
>> The OPAQUE and TRANSPARENT notion seems to have gone out of use, at
>> least in the current code.
>> If you are synthesizing file descriptors, perhaps because your file
>> system is in user space (no, not a FUSE-based file system, which has
>> kernel-visible FDs) then you *must* implement all the VFS routines
>> because you cannot let your FDs get into the backstop module
>> If, however, you are simply augmenting the functionality provided by
>> an underlying file system, then you only have to implement those VFS
>> routines that are of interest to you.
> The point is what I commented in the first message of the thread: The files
> are not in user space, the module must access them through HTTPs APIs (this
> part is solved) that only allows list, read and writte. So I'm not
> augmenting an underlying file system and I'm not using kernel FDs.
> I fact I don't have FDs (perhaps I should implement one kind of FDs table in
> my module?), and thats why I'm asking about some things such as open/close.
> In the otrer hand I have the problem about using symlinks, chmod, lseek,
> acl... the provider API don't support any kind of this functions.
When Samba calls SMB_VFS_OPEN or SMB_VFS_CREATE_FILE* you must return an FD:
source3/smbd/open.c: fsp->fh->fd = SMB_VFS_OPEN(conn, smb_fname,
fsp, flags, mode);
Thus, you will have to synthesize FDs and therefore you will have to
implement all of the VFS routines.
* Actually SMB_VFS_CREATE_FILE returns an FSP that should have an FD in it.
For those functions that do not make sense you can return ENOSYS if
the VFS routine returns a UNIX error code or NT_STATUS_NOT_IMPLEMENTED
if the routine returns an NTSTATUS. However, doing so might confuse
Windows in some cases.
More information about the samba-technical