On Tue 15-03-22 15:07:24, Amir Goldstein wrote: > > > > 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? 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? > > 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... > > 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! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
