On Tue, Jun 10, 2025 at 5:25 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Tue, Jun 10, 2025 at 3:49 PM Jan Kara <jack@xxxxxxx> wrote: > > > > Hi Amir! > > > > Hi Jan! > > Thanks for taking the time to read my long email ;) > > > On Wed 04-06-25 18:09:15, Amir Goldstein wrote: > > > In v1 there was only patch 1 [1] to allow FAN_PRE_ACCESS events > > > on readdir (with FAN_ONDIR). > > > > > > Following your feedback on v1, v2 adds support for FAN_PATH_ACCESS > > > event so that a non-populated directory could be populted either on > > > first readdir or on first lookup. > > > > OK, it's good that now we have a bit more wider context for the discussion > > :). First, when reading this I've started wondering whether we need both > > FAN_PRE_ACCESS on directories and FAN_PATH_ACCESS (only on directories). > > Firstly, I don't love adding more use to the FAN_ONDIR flag when creating > > marks because you can only specify you want FAN_PRE_ACCESS on files, > > FAN_PRE_ACCESS on files & dirs but there's no way to tell you care only > > about FAN_PRE_ACCESS on dirs. You have to filter that when receiving > > events. Secondly, the distinction between FAN_PRE_ACCESS and > > FAN_PATH_ACCESS is somewhat weak - it's kind of similar to the situation > > with regular files when we notify about access to the whole file vs only to > > a specific range. So what if we had an event like FAN_PRE_DIR_ACCESS that > > would report looked up name on lookup and nothing on readdir meaning you > > need to fetch everything? > > > > This makes a lot of sense to me. and I also like the suggested event name. > Another advantage is that FAN_PRE_ACCESS can always expect a range > (as documented) > Hi Jan, I started looking at combining readdir() and lookup() to generate FAN_PRE_DIR_ACCESS and I hit this problem: Currently, FAN_PRE_ACCESS is an event that is FS_EVENTS_POSS_ON_CHILD, so watching a parent with FAN_EVENT_ON_CHILD can report this event on files. The same is true for FAN_OPEN, FAN_ACCESS and FAN_OPEN_PERM events, but in that case, also true for an opened/access directory. I do not think it is right to generate pre-content lookup events in subdir when watching a parent directory. I don't think that generating pre-content readdir events on subdir when watching a parent dir is very useful, but if you do not allow that, we deviate from the behavior of the event FAN_ACCESS | FAN_ONDIR which also happens on readdir. Honestly, I always found it a bit confusing that when reporting DFID_NAME of events FAN_OPEN | FAN_ONDIR and FAN_ACCESS | FAN_ONDIR, when watching the parent, we do not report the name of the subdir (like inotify does), but I still think it was the right thing to do. Do you understand my dilemma? Do you think it is fine for FAN_PRE_DIR_ACCESS to break out of this confusing pattern and not be reported for subdirs on a watches parent? Do you think we should report pre-content lookup events in subdir with a watched parent? Do you have an idea how to make this less confusing to users? Or should we drop the idea of unifying the readdir/lookup events and keep the legacy semantics for pre-readdir. Thanks, Amir.
