Hello Matthew!
On Thu 05-05-22 20:25:31, Matthew Bobrowski wrote:
> I was having a brief chat with Amir the other day about an idea/use
> case that I have which at present don't believe is robustly supported
> by the fanotify API. I was wondering whether you could share some
> thoughts on supporting the following idea.
>
> I have a need to track file movement across a filesystem without
> necessarily burdening the system by having to watch the entire
> filesystem for such movements. That is, knowing when file /dir1/a had
> been moved from /dir1/a to /dir2/a and then from /dir2/a to /dir3/a
> and so on. Or more simply, knowing the destination/new path of the
> file once it has moved.
OK, and the places the file moves to can be arbitrary? That seems like a
bit narrow usecase :)
> Initially, I was thinking of using FAN_MOVE_SELF, but it doesn't quite
> cut it. For such events, you only know the target location or path of
> a file had been modified once it has subsequently been moved
> elsewhere. Not to mention that path resolution using the file
> identifier from such an event may not always work. Then there's
> FAN_RENAME which could arguably work. This would include setting up a
> watch on the parent directory of the file of interest and then using
> the information record of type FAN_EVENT_INFO_TYPE_NEW_DFID_NAME to
> figure out the new target location of the file once it has been moved
> and then resetting the mark on the next parent directory once the new
> target location is known. But, as Amir rightfully mentioned, this
> rinse and repeat mark approach is suboptimal as it can lead to certain
> race conditions.
It seems to me you really want FAN_MOVE_SELF but you'd need more
information coming with it like the new parent dir, wouldn't you? It would
be relatively easy to add that info but it would kind of suck that it would
be difficult to discover in advance whether the directory info will arrive
with the event or not. But that actually would seem to be the case for
FAN_RENAME as well because we didn't seem to bother to refuse FAN_RENAME on
a file. Amir?
> Having briefly mentioned all this, what is your stance on maybe
> extending out FAN_RENAME to also cover files? Or, maybe you have
> another approach/idea in mind to cover such cases i.e. introducing a
> new flag FAN_{TRACK,TRACE}.
So extending FAN_MOVE_SELF or FAN_RENAME looks OK to me, not much thoughts
beyond that :).
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
