Re: File monitor problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux