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

[Sergio Conde]

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.