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@xxxxxxxx>
SUSE Labs, CR
