Re: [RFC PATCH v2 0/3] fanotify HSM events for directories

[Amir Goldstein <amir73il@gmail.com>]

On Tue, Jun 10, 2025 at 5:25 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Tue, Jun 10, 2025 at 3:49 PM Jan Kara <jack@suse.cz> 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.