Het real path of a share.

[Stef Bon]

2013/2/14 Andrew Bartlett <abartlet at samba.org>:
> On Wed, 2013-02-13 at 22:45 +0100, Stef Bon wrote:
>> 2013/2/13 simo <idra at samba.org>:

>> Why not. I think you are not aware what I mean here. It's an url for
>> internal use only. I'm not suggesting anything generic for common use.
>
> We still strongly discourage the creating of new url schemes, as once
> started these things are really, really hard to stop.
>

Ok, you're right. I will think about other sollutions.

>>
>> You say there is no need. This is not true. Maybe Samba handles change
>> notify request like they should, but the filesystem for linux, cifs ,
>> do not.
>
> Shouldn't that be handled as a bug against cifsfs?
>

Well, cifs does support the NT_TRANSACT_NOTIFY_CHANGE call
see: kernelsource/fs/cifs/cifssmb.c, latest function (+- line 6300)

but it is commented out since it does not work with inotify.
I've contacted kernel developers about this, but they have something against
inotify: a "don't use it" attitude.

So I decided to write a userspace daemon clients can connect to, and
this daemon (notifyfs) has to connect to filesystems to forward
watches to.

To be complete, when dealing with a networkfilesystem or a fuse fs, it
still sets a inotify watch. (but that does not catch the changes in
the backend made by others as you may understand)

So a connection to forward the watches and to send a fsevent when a
change is detected by the backend is required. This is simple with
fuse fs's, but gets complicated with filesystems like nfs and cifs,
since they are in kernelspace.

I'm thinking about adding an fd at mount, simular to autofs, or netlink.
It's a bit strange, using such a connection from userspace to
kernelspace, while the filesystems and the fsevent subsystems like
inotify are in kernelspace, but I'm afraid that is just the way it is.

>> I'm developing a service which can provide some simple fsevent
>> notification, bypassing the network filesystems. This is not how it
>> should work, I know, but I will be very happy whenI get this working.
>
> This sounds like something heading for a correctness, authentication and
> authorization disaster, and I strongly urge you to reconsider.  How will
> you tie a particular file descriptor between the two channels,
> particularly across renames?

A client can only set a watch when she/he has read permissions.

If not enough permissions, it is not forwarded to the remote notifyfs server.

I know this bypassing the whole authentication and authorization used
by the filesystem, but I leave it for now to the "having read
permissions" on the specific filesystem object.

And yes when I've got this working, it can only get better. It's not
my intention to have this construction as the endgoal. My endgoal is
the ability for notifyfs is to connect to filesystems like cifs an
nfs, and forward a watch and receive fsevents from them.

About rename, what do you mean exactly with
"How will you tie a particular file descriptor between the two
channels, particularly across renames?"

Earlier I've contacted Steve French, developer of cifs, and he noted
that we should already be very happy when basic things are working
like a remove or create.

Stef Bon