On Mon, Dec 23, 2019 at 8:20 PM Jan Kara <jack@xxxxxxx> wrote: > > On Thu 19-12-19 09:33:24, Amir Goldstein wrote: > > On Mon, Dec 16, 2019 at 5:00 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > On Wed, Dec 11, 2019 at 3:58 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Hi Jan, > > > > > > I have something working. > > > > > > Patches: > > > https://github.com/amir73il/linux/commits/fanotify_name > > > > > > Simple test: > > > https://github.com/amir73il/ltp/commits/fanotify_name > > > > > > I will post the patches after I have a working demo, but in the mean while here > > > is the gist of the API from the commit log in case you or anyone has comments > > > on the API. > > > > > > Note that in the new event flavor, event mask is given as input > > > (e.g. FAN_CREATE) to filter the type of reported events, but > > > the event types are hidden when event is reported. > > Makes some sense I guess but at the same time won't this be rather > confusing for users of the API? > <shrug/> I guess it will be confusing for users that we obfuscate the event mask in the first place. I though that taking away the ability to filter by event type would be too much, but I can change that if you think otherwise. > Also I've read you proposal and I'm somewhat wondering whether we are not > overengineering this. Possibly. Won't be my first time.. > I can see the need for FAN_DIR_MODIFIED_WITH_NAME > (stupid name, I know) - generated when something changed with names in a > particular directory, reported with FID of the directory and the name > inside that directory involved with the change. Directory watching > application needs this to keep track of "names to check". Is the name > useful with any other type of event? _SELF events cannot even sensibly have > it so no discussion there as you mention below. Then we have OPEN, CLOSE, > ACCESS, ATTRIB events. Do we have any use for names with those? > The problem is that unlike dir fid, file fid cannot be reliably resolved to path, that is the reason that I implemented FAN_WITH_NAME for events "possible on child" (see branch fanotify_name-wip). A filesystem monitor typically needs to be notified on name changes and on data/metadata modifications. So maybe add just two new event types: FAN_DIR_MODIFY FAN_CHILD_MODIFY Both those events are reported with name and allowed only with init flag FAN_REPORT_FID_NAME. User cannot filter FAN_DIR_MODIFY by part of create/delete/move. User cannot filter FAN_CHILD_MODIFY by part of attrib/modify/close_write. FAN_CHILD_MODIFY implies FAN_EVENT_ON_CHILD for directory watch, but also works on sb/mount mark as if all directories are watched. And there is nothing stopping user from requesting also _SELF events and other events without name on the same group. Does that sound better? Thanks, Amir.
