On Wed, Jul 14, 2021 at 4:16 AM Matthew Bobrowski <repnop@xxxxxxxxxx> wrote:
>
> On Mon, Jul 12, 2021 at 09:08:18PM +0300, Amir Goldstein wrote:
> > On Mon, Jul 12, 2021 at 7:26 PM Jan Kara <jack@xxxxxxx> wrote:
> > > On Mon 12-07-21 16:00:54, Amir Goldstein wrote:
> > > Just a brainstorming idea: How about creating new event FAN_RENAME that
> > > would report two DFIDs (if it is cross directory rename)?
> >
> > I like the idea, but it would have to be two DFID_NAME is case of
> > FAN_REPORT_DFID_NAME and also for same parent rename
> > to be consistent.
>
> I don't have much to add to this conversation, but I'm just curious here.
>
> If we do require two separate DFID_NAME record objects in the case of cross
> directory rename operations, how does an event listener distinguish the
> difference between which is which i.e. moved_{from/to}? To me, this
> implies that the event listener is expected to rely on specific
> supplemental information object ordering, which to my knowledge is a
> contract that we had always wanted to avoid drawing.
>
I think the records should not rely on ordering, but on self describing types,
such as FAN_EVENT_INFO_TYPE_DFID_NAME_{FROM,TO}
but I am trying to think of better names.
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.
My goal is to minimize the man page size and complexity.
Thanks,
Amir.
