Hey Jan,
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.
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.
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}.
Eager to hear your thoughts on this.
/M
