> > This implementation is a compromise for not having clear user mount > > context in all places that call for an event. > > For every person you find that thinks it is intuitive to get an event on /B > > for touch C/bla, you will find another person that thinks it is not intuitive > > And I think here we disagree. The technical implementation currently > requires this since the two mounts are both clearly marked and the first > mount creates objects by going through the other mount and they don't > have a private mount. All I was saying is that the current patchset > can't handle this case and asked whether we are ok with that and if not > what we do to fix it. > My proposal two or three mails ago and then picked up by you is: make > them both use a private clone mount which is - as I said in earlier > mails - the correct solution anyway and falls in line with overlayfs > too. > As long as we agree on the solution ;-) > > to get an event. I think we are way beyond the stage with mount > > namespaces where intuition alone suffice. > > > > w.r.t consistent, you gave a few examples and I suggested how IMO > > they should be fixed to behave consistently. > > If you have other examples of alleged inconsistencies, please list them. > > It feels like I somehow upset you with this. You do not upset me. I just didn't find a better way to address "consistent and intuitive" concern without asking for more concrete examples, after we eliminated the ecryptfs example, which we already agreed(?), is a non issue. My claim about "intuitive" is that there is a limit to how intuitive this could be. I do not see myself explaining in the man page why FAN_DELETE_SELF cannot be requested for a mount mark. It's just too low level. So the best I can do is document the events that are available to inode/sb mark and not available to mount mark. Currently, the fanotify_mark.2 man page reads: "...The events which require that filesystem objects are identified by file handles, such as FAN_CREATE, FAN_ATTRIB, FAN_MOVE, and FAN_DELETE_SELF, cannot be provided as a mask when flags contains FAN_MARK_MOUNT..." I will change that to: "...The events FAN_ATTRIB, FAN_MOVE, and FAN_DELETE_SELF, cannot be provided as a mask when flags contain FAN_MARK_MOUNT..." Without providing a rationale to the list of forbidden events. BTW, there is an undocumented fact about FAN_MODIFY - This event is allowed in a mount mark mask, but it only reports the events generated by fsnotify_modify() on file writes. It does not report to a mount mark, the FAN_MODIFY event generated by fsnotify_change() from truncate() and utimensat(), because of the missing mount context. So yeh, I do understand where the "inconsistent" feeling is coming from... ;-) [...] > > So I would like to know that we really have all the pieces needed for > > a useful solution, before proposing the fanotify patches. > > Sure, if you think that you have your branch in the shape that you want > to. So far it has been evolving quite rapidly as you said yourself. :) > I can probably test this soon early next week seems most likely since I > need to find a timeslot to actually do the work you're asking. Hope that > works. > No plans to make any more changes to those branches and no rush as to when to post tham. This is not v4.13-rc1 material anyway. Thanks, Amir.
