On Wed 16-03-22 15:42:44, Amir Goldstein wrote: > > > 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. My idea was that with FAN_IGNORED_MASK we did the mistake that passed arguments (mask in particular) are not properly checked because we let userspace set bits which are not really used in the ignore mask. So let's fix this by properly checking the arguments and to do that safely we need a new variant of FAN_IGNORED_MASK, hence FAN_IGNORED_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. Well, yes, you are speaking about effectively the same flag just under a different name :) I agree my name is poor so I'm happy if we pick another one. The only small reservation I have against the name FAN_IGNORE_MARK is that we would now have to explain in the manpage a new concept of ignore mark and tell this is just a new name for ignore mask which looks a bit silly and perhaps confusing to developers used to the old naming. > 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, ... Certainly. > 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. Well, but FAN_IGNORE_MARK is not just for watching children. You can still ignore a single file with FAN_IGNORE_MARK. As much as I understand that FAN_MARK_IGNORED_SURV_MODIFY complicates our life, I don't think we'll ever be able to get rid of it completely so I don't see any value in disallowing it with FAN_IGNORE_MARK. > > > > 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. Yeah, I actually like the consistency here - the ordinary mask causes the event to be generated IFF the same ignore mask/mark causes the event to be discarded. It would mean that without ONDIR events from directories are not ignored so that's a difference to current meaning of ignore masks but we can do that modification with the new flag. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
