Re: File monitor problem

[Jan Kara <jack@suse.cz>]

On Tue 07-01-20 20:56:20, Amir Goldstein wrote:
> On Tue, Jan 7, 2020 at 7:10 PM Jan Kara <jack@suse.cz> wrote:
> > > There is another weird way to obfuscate the event type.
> > > I am not sure if users will be less confused about it:
> > > Each event type belongs to a group (i.e. self, dirent, poss_on_child)
> > > User may set any event type in the mask (e.g. create|delete|open|close)
> > > When getting an event from event group A (e.g. create), all event types
> > > of that group will be reported (e.g. create|delete).
> > >
> > > To put it another way:
> > > #define FAN_DIR_MODIFY (FAN_CREATE | FAN_MOVE | FAN_DELETE)
> > >
> > > For example in fanotify_group_event_mask():
> > > if (event_with_name) {
> > >     if (marks_mask & test_mask & FAN_DIR_MODIFY)
> > >         test_mask |= marks_mask & FAN_DIR_MODIFY
> > > ...
> > >
> > > Did somebody say over-engineering? ;)
> > >
> > > TBH, I don't see how we can do event type obfuscation
> > > that is both usable and not confusing, because the concept is
> > > confusing. I understand the reasoning behind it, but I don't think
> > > that many users will.
> > >
> > > I'm hoping that you can prove me wrong and find a way to simplify
> > > the API while retaining fair usability.
> >
> > I was thinking about this. If I understand the problem right, depending on
> > the usecase we may need with each event some subset of 'object fid',
> > 'directory fid', 'name in directory'. So what if we provided all these
> > three things in each event? Events will get somewhat bloated but it may be
> > bearable.
> >
> 
> I agree.
> 
> 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...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR