> > What I like about the fact that users don't need to choose between
> > 'parent fid' and 'object fid' is that it makes some hard questions go away:
> > 1. How are "self" events reported? simple - just with 'object id'
> > 2. How are events on disconnected dentries reported? simple - just
> > with 'object id'
> > 3. How are events on the root of the watch reported? same answer
> >
> > Did you write 'directory fid' as opposed to 'parent fid' for a reason?
> > Was it your intention to imply that events on directories (e.g.
> > open/close/attrib) are
> > never reported with 'parent fid' , 'name in directory'?
>
> Yes, that was what I thought.
>
> > I see no functional problem with making that distinction between directory and
> > non-directory, but I have a feeling that 'parent fid', 'name in
> > directory', 'object id',
> > regardless of dir/non-dir is going to be easier to document and less confusing
> > for users to understand, so this is my preference.
>
> Understood. The reason why I decided like this is that for a directory,
> the parent may be actually on a different filesystem (so generating fid
> will be more difficult) and also that what you get from dentry->d_parent
> need not be the dir through which you actually reached the directory (think
> of bind mounts) which could be a bit confusing. So I have no problem with
> always providing 'parent fid' if we can give good answers to these
> questions...
>
Actually, my current code in branch fanotify_name already takes care of
some of those cases and it is rather easy to deal with the bind mount case
if path is available:
if (path && path->mnt->mnt_root != dentry)
mnt = real_mount(path->mnt);
/* Not reporting parent fid + name for fs root, bind mount root and
disconnected dentry */
if (!IS_ROOT(dentry) && (!path || mnt))
marks_mask |= fsnotify_watches_children(
dentry->d_sb->s_fsnotify_mask);
if (mnt)
marks_mask |= fsnotify_watches_children(
mnt->mnt_fsnotify_mask);
Note that a non-dir can also be bind mounted, so the concern you raised is
actually not limited to directories.
It is true that with the code above, FAN_ATTRIB and FAN_MODIFY (w/o path)
could still be reported to sb mark with the parent/name under the bind mount,
but that is not wrong at all IMO - I would say that is the expected behavior for
a filesystem mark.
IOW, the answer to your question, phrased in man page terminology is:
(parent fid + name) information is not guarantied to be available except for
FAN_DIR_MODIFY, but it may be available as extra info in addition to object fid
for events that are possible on child.
For example, an application relying on (parent fid + name) information for
FAN_MODIFY (e.g. for remote mirror) simply cannot get this information when
nfsd opens a file with a disconnected dentry and writes to it.
TBH, I am not convinced myself that reporting (parent fid + name) for
directories
is indeed easier to document/implement than treating directories different that
non-directories, but I am going to try and implement it this way and prepare a
draft man page update to see how it looks - I may yet change my mind after
going through this process...
Thanks,
Amir.
