> > I can see the need for FAN_DIR_MODIFIED_WITH_NAME
> > (stupid name, I know) - generated when something changed with names in a
> > particular directory, reported with FID of the directory and the name
> > inside that directory involved with the change. Directory watching
> > application needs this to keep track of "names to check". Is the name
> > useful with any other type of event? _SELF events cannot even sensibly have
> > it so no discussion there as you mention below. Then we have OPEN, CLOSE,
> > ACCESS, ATTRIB events. Do we have any use for names with those?
> >
>
> The problem is that unlike dir fid, file fid cannot be reliably resolved
> to path, that is the reason that I implemented FAN_WITH_NAME
> for events "possible on child" (see branch fanotify_name-wip).
>
> A filesystem monitor typically needs to be notified on name changes and on
> data/metadata modifications.
>
> So maybe add just two new event types:
> FAN_DIR_MODIFY
> FAN_CHILD_MODIFY
>
> Both those events are reported with name and allowed only with init flag
> FAN_REPORT_FID_NAME.
> User cannot filter FAN_DIR_MODIFY by part of create/delete/move.
> User cannot filter FAN_CHILD_MODIFY by part of attrib/modify/close_write.
Nah, that won't do. I now remember discussing this with out in-house monitor
team and they said they needed to filter out FAN_MODIFY because it was too
noisy and rely on FAN_CLOSE_WRITE. And other may want open/access as
well.
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.
Thanks,
Amir.
