Re: File monitor problem

From: Amir Goldstein <amir73il@gmail.com>
To: Mo Re Ra <more7.rev@gmail.com>, Jan Kara <jack@suse.cz>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: File monitor problem
Date: Wed, 4 Dec 2019 14:53:33 +0200	[thread overview]
Message-ID: <CAOQ4uxiKqEq9ts4fEq_husQJpus29afVBMq8P1tkeQT-58RBFg@mail.gmail.com> (raw)
In-Reply-To: <CADKPpc2RuncyN+ZONkwBqtW7iBb5ep_3yQN7PKe7ASn8DpNvBw@mail.gmail.com>

On Wed, Dec 4, 2019 at 12:03 PM Mo Re Ra <more7.rev@gmail.com> wrote:
>
> Hi,
>
> I don`t know if this is the correct place to express my issue or not.
> I have a big problem. For my project, a Directory Monitor, I`ve
> researched about dnotify, inotify and fanotify.
> dnotify is the worst choice.
> inotify is a good choice but has a problem. It does not work
> recursively. When you implement this feature by inotify, you would
> miss immediately events after subdir creation.
> fanotify is the last choice. It has a big change since Kernel 5.1. But
> It does not meet my requirement.
>
> I need to monitor a directory with CREATE, DELETE, MOVE_TO, MOVE_FROM
> and CLOSE_WRITE events would be happened in its subdirectories.
> Filename of the events happened on that (without any miss) is
> mandatory for me.
>
> I`ve searched and found a contribution from @amiril73 which
> unfortunately has not been merged. Here is the link:
> https://github.com/amir73il/fsnotify-utils/issues/1
>
> I`d really appreciate it If you could resolve this issue.
>

Hi Mohammad,

Thanks for taking an interest in fanotify.

Can you please elaborate about why filename in events are mandatory
for your application.

Could your application use the FID in FAN_DELETE_SELF and
FAN_MOVE_SELF events to act on file deletion/rename instead of filename
information in FAN_DELETE/FAN_MOVED_xxx events?

Will it help if you could get a FAN_CREATE_SELF event with FID information
of created file?

Note that it is NOT guarantied that your application will be able to resolve
those FID to file path, for example if file was already deleted and no open
handles for this file exist or if file has a hardlink, you may resolve the path
of that hardlink instead.

Jan,

I remember we discussed the optional FAN_REPORT_FILENAME [1] and
you had some reservations, but I am not sure how strong they were.
Please refresh my memory.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commit/d3e2fec74f6814cecb91148e6b9984a56132590f