On Sat, Jan 5, 2019 at 2:34 AM Matthew Bobrowski
<mbobrowski@xxxxxxxxxxxxxx> wrote:
>
> On Fri, Jan 04, 2019 at 02:39:06PM +0200, Amir Goldstein wrote:
> > On Fri, Jan 4, 2019 at 2:18 PM Jan Kara <jack@xxxxxxx> wrote:
> > >
> > > On Fri 04-01-19 13:42:33, Amir Goldstein wrote:
> > > > On Fri, Jan 4, 2019 at 12:57 PM Jan Kara <jack@xxxxxxx> wrote:
> > > > > The reporting of FAN_ONDIR when the event was mkdir / rmdir could be useful
> > > > > I guess. E.g. when implementing recursive watching of a directory. Or what
> > > > > is your intended usecase? It should be said explicitely in the changelog.
> > > >
> > > > Recursive watch of directory tree is certainly a use case that could benefit
> > > > from "mkdir" events. I will add that to commit message.
> > >
> > > Hum, so it does not seem like you had any particular usecase in mind? :)
> >
> > Our application does have special handling (scanning) for mkdir events.
> >
> > > Before complicating the interface with reporting FAN_ONDIR in some cases
> > > I'd prefer we considered whether the usecases are worth it. So let me start
> > > that: Reporting FAN_ONDIR can distinguish between file/directory
> > > creation/deletion. That can save userspace some rescans of the changed
> > > directory if it is interested only in subdirectory creation / deletion (if
> > > the application is interested only in file changes it just does not set
> > > FAN_ONDIR and that's it).
> > >
> > > Another motivation is the compatibility with inotify and it's IN_ISDIR flag
> > > I guess.
> > >
> > > Hum, OK, I guess the complication is worth it.
> > >
> >
> > Let's see.
> >
> > The fact that FAN_ONDIR is an "out" flag IFF FAN_REPORT_FID
> > is set, is something that needs to be clarified.
> >
> > The fact that reported FID refers to the modified directory in dirent events
> > but FAN_ONDIR flag refers to the created/removed/renamed child is
> > another thing that needs to be clarified.
> >
> > Sigh! "things that need to be clarified" are things we need to avoid.
> > Therefore, I am going to make another suggestion.
> >
> > How about if we introduced a new flag FAN_DIRENT_ISDIR?
> > Like IN_ISDIR, it is an out-only flag that cannot be requested.
> > As its name suggests, it is only applicable to dirent events, so will always
> > be set when a sub directory entry is created/renamed/removed.
> >
> > FAN_ONDIR has no effect on dirent events, because FAN_ONDIR
> > refers to the "victim" inode and the "victim" is the modified directory.
> > If user specified FAN_CREATE|FAN_DELETE|FAN_MOVE, user
> > wants to get notified when *directories* are modified and specifying
> > FAN_ONDIR explicitly is not needed.
> >
> > How about that?
>
> I think this could work.
>
> However to me, and if I'm understanding this correctly, it looks like we're
> going down the route of adding "bonus" flags to particular events, which I
> thought was something that we wanted to try and avoid in future versions of the
> API? This would be so that users don't get any sudden surprises when processing
> their events. It would also go against the notion of only receiving events that
> were explicitly requested for by the calling process, which was something that
> we discussed and implemented in a previous patch series?
>
This is a bit different case than FAN_OPEN_EXEC, because I wasn't suggesting
to let the user opt-in/out of mkdir events.
There is nothing wrong with "out event flags" as they do exist in inotify.
If we want to take FAN_OPEN_EXEC as an example, we could define
completely new set of events FAN_SUBDIR_{CREATE,DELETE,MOVE}
but IMO that is not needed and not consistent with what users are accustomed
for from inotify. We don't need to stick by inotify always, but if we don't
have a good reason to differentiate from it, we should avoid that IMO.
There is another option that does not sound very alluring to me, but I'll write
it anyway for your consideration:
-#define FAN_ONDIR 0x40000000 /* event occurred against dir */
+#define FAN_ISDIR 0x20000000 /* event occurred against dir */
+#define FAN_ONDIR 0x40000000 /* interested in
events against dir */
#define FAN_EVENT_ON_CHILD 0x08000000 /* interested in child events */
FAN_ONDIR remains in-only flag and keeps the same meaning.
FAN_ISDIR is an in/out flag for all events (not just dirent events)
and preserves the same meaning as it has in inotify (refers to dirent
OR to victim
depending on the event type).
Technically, FAN_ISDIR implies FAN_ONDIR, but *also* carries the
information in out event, like in inotify.
Food for though...
Thanks,
Amir.
