> > The only thing is, as you wrote to Srinivas, there is really no practical > > way to make ignore mask with ON_CHILD work on old kernels, so > > what can users do if they want to write a portable program? > > Add this mark and hope for the best? > > OK, this objection probably tipped the balace towards a new flag for me :) > > > If users had FAN_MARK_PARENT, the outcome at least would > > have been predictable. > > Maybe FAN_MARK_PARENT is an overkill. > > Maybe what we need is FAN_MARK_IGNORED_ON_CHILD. > > It's not very pretty, but it is clear. > > Or how about FAN_MARK_IGNORED_MASK_CHECKED which would properly check for > supported bits in the ignore mask and then we can use ON_CHILD as I wanted > and we would regain ONDIR bit for future use as well? > I don't follow the reasoning behind the name MASK_CHECKED. If anything, I would rather introduce FAN_IGNORE_MARK. The reasoning is that users may think of this "ignore mark" as a separate mark from the "inode mark", so on this "mark" the meaning of ON_CHILD flags would be pretty clear. The fact that they are implemented as a single mark with two masks and that each mask also has some flags is an implementation detail. If we go for FAN_IGNORE_MARK, we would disallow the combination fanotify_mark(FAN_IGNORE_MARK, FAN_MARK_IGNORED_MASK, ... and I am also in favor of disallowing FAN_MARK_IGNORED_SURV_MODIFY. I find it completely useless for watching children and if people still need the ignored mask that does not survive modify, they can use the old API. > > > With ONDIR I agree things are not as obvious. Historically we have applied > > > ignore mask even for events coming from directories regardless of ONDIR > > > flag in the ignore mask. So ignore mask without any special flag has the > > > implicit meaning of "apply to all events regardless of type of originating > > > inode". I don't think we can change that meaning at this point. We could > > > define meaning of ONDIR in ignore mask to either "ignore only events from > > > directories" or to "ignore only events from ordinary files". But neither > > > seems particularly natural or useful. > > > > > > > TBH, I always found it annoying that fanotify cannot be used to specify > > a filter to get only mkdirs, which is a pretty common thing to want to be > > notified of (i.e. for recursive watch). > > But I have no intention to propose API changes to fix that. > > I see, so we could repurpose ONDIR bit in ignore mask for EVENT_IGNORE_NONDIR > feature or something like that. But as you say, no pressing need... > Alas, that does not fit nicely with the FAN_IGNORE_MARK abstraction. The inverse does: The "mark" with ONDIR captures all the create events and the "ignore mark" without ONDIR filters out the non-mkdir. Thanks, Amir.
