> > > Overall I guess the functionality makes sense to me (in fact it is somewhat > > > surprising it is not working like that from the beginning), API-wise it is > > > not outright horrible, and technically it seems doable. What do you think? > > > > I think that having ONDIR and ON_CHILD in ignored mask is source for > > confusion. Imagine a mount mark with FAN_ONDIR and ignored mark (on dir > > inode) without FAN_ONDIR. What should the outcome be? > > Don't ignore the events on dir because ignore mask does not have ONDIR? > > That is not the obvious behavior that people will expect. > > > > ON_CHILD may be a different case, but I also prefer not to deviate it from > > ONDIR. > > > > The only thing I can think of to add clarification is FAN_MARK_PARENT. > > > > man page already says: > > "The flag has no effect when marking mounts and filesystems." > > It can also say: > > "The flag has no effect when set in the ignored mask..." > > "The flag is implied for both mask and ignored mask when marking > > directories with FAN_MARK_PARENT". > > > > Implementation wise, this would be very simple, because we already > > force set FAN_EVENT_ON_CHILD for FAN_MARK_MOUNT > > and FAN_MARK_FILESYSTEM with REPORT_DIR_FID, se we can > > also force set it for FAN_MARK_PARENT. > > > > But maybe it's just me that thinks this would be more clear?? > > Yeah, I'm not sure if adding another flag that iteracts with ON_CHILD or > ONDIR adds any clarity to this mess. In my opinion defining that ON_CHILD > flag in the ignore mask means "apply this ignore mask to events from > immediate children" has an intuitive meaning as it is exactly matching the > semantics of ON_CHILD in the normal mark mask. > Ok. 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? 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. > 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. > Another concern is that currently fanotify_mark() ignores both ONDIR and > ON_CHILD flags in the ignore mask. So there is a chance someone happens to > set them by accident. For the ON_CHILD flag I would be willing to take a > chance and assign the meaning to this flag because I think chances for > real world breakage are really low. But for ONDIR, given it is unclear > whether ignore masks should apply for directory events without that flag, I > think the chances someone sets it "just to be sure" are high enough that I > would be reluctant to take that chance. So for ONDIR I think we are more or > less stuck with keeping it unused in the ignore mask. > I agree with your risk assessment, so no hard objection to ON_CHILD on ignored mask. If we go with FAN_MARK_IGNORED_ON_CHILD it will not be a concern at all. I should be able to find some time to fix this one way or the other when we decide on the design. Thanks, Amir.
