On Fri 02-11-18 15:43:04, Amir Goldstein wrote:
> 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.
Yeah, I know, it is sitting in my inbox waiting for me to look into in
carefully enough :)
> 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.
Yes, I think separate events for OPEN_PERM and OPEN_WRITE_PERM are fine as
well. So let's go for separate events.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
