Samba VFS: Is it really a Virtual File System API?

[Richard Sharpe]

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>
>>  wrote:
>>>
>>> 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
>>> are
>>> 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
>>> went
>>> 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
>> (vfs_default.c).
>>
>> 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.

-- 
Regards,
Richard Sharpe