Re: FAN_REPORT_CHILD_FID

[Jan Kara <jack@suse.cz>]

On Fri 16-07-21 09:53:15, Matthew Bobrowski wrote:
> On Wed, Jul 14, 2021 at 03:09:56PM +0300, Amir Goldstein wrote:
> > I am still debating with myself between adding a new event type
> > (FAN_RENAME), adding a new report flag (FAN_REPORT_TARGET_FID)
> > that adds info records to existing MOVE_ events or some combination.
> 
> Well, if we went with adding a new event FAN_RENAME and specifying that
> resulted in the generation of additional
> FAN_EVENT_INFO_TYPE_DFID_NAME_{FROM,TO} information record types for an
> event, wouldn't it be weird as it doesn't follow the conventional mechanism
> of a listener asking for additional information records? As in,
> traditionally we'd intialize the notification group with a flag and then
> that flag controls whether or not one is permitted to receive events of a
> particular type that may or may not include information records?
> 
> Maybe a combination approach is needed in this instance, but this doesn't
> necessarily simplify things when attempting to document the API semantics
> IMO.

So there are couple of ways how to approach this I guess. One is that we
add a flag like FAN_REPORT_SECONDARY_DFID and FAN_REPORT_SECONDARY_NAME
which would add another DFID(+NAME) record of new type to rename event. In
principle these could be added to MOVED_FROM and/or MOVED_TO events
(probably both are useful). But I'd find the naming somewhat confusing and
difficult to sensibly describe.

That's why I think it may be clearer to go with new FAN_RENAME event that
will be triggered when the directory is on either end of rename(2) (source
or target). If DFID(+NAME) is enabled for the group, the event would report
both source and target DFIDs (and names if enabled) instead of one. I don't
think special FAN_REPORT_? flag to enable the second DFID would be useful
in this case (either for clarity or enabling some functionality).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR