On Fri, Nov 2, 2018 at 2:50 PM Jan Kara <jack@xxxxxxx> wrote:
> > Permission events cannot
> > be merged, but man page doesn't say anything about that.
> > It might be worth dropping a note about OPEN_EXEC_PERM
> > that it could be expected to appear together in the same permission
> > event with OPEN_PERM and user response will apply to both.
>
> Umm, I'd actually prefer if the OPEN_PERM and OPEN_EXEC_PERM events didn't
> get merged. The overhead is just an additional call to fsnotify() to find
> out one of the events is uninteresting (realistically, 99% of users will be
> looking OPEN_PERM or OPEN_EXEC_PERM but not both) and it just keeps things
> simple in the API. I understand that it may seem somewhat unexpected that
> single file open will generate two different fsnotify permission events
> (again 99% users won't observe this anyway) but if we start "merging"
> permission events I think we open more space for confusion - like when
> event arrives with some bits trimmed due to ignore mask masking bits out or
> what not. What do you think Amir?
>
I have no objections to {fsnotify()/fsnotify_parent()}x2
Speaking of which, just posted a fix patch last week to deal with double events
on sub-directories.
My only concern w.r.t separate event is, if we ever wanted to add
OPEN_WRITE_PERM, would you have made the same decisions as we are
making now for OPEN_EXEC_PERM? If the answer is yes, then separate
events are fine by me.
Thanks,
Amir.
