From: Mo Re Ra <firstname.lastname@example.org> To: Amir Goldstein <email@example.com> Cc: Jan Kara <firstname.lastname@example.org>, linux-fsdevel <email@example.com> Subject: Re: File monitor problem Date: Wed, 4 Dec 2019 17:54:48 +0330 Message-ID: <CADKPpc33UGcuRB9p64QoF8g88emqNQB=Z03f+OnK4MiCoeVZpg@mail.gmail.com> (raw) In-Reply-To: <CAOQ4uxiKqEq9ts4fEq_husQJpus29afVBMq8P1tkeQT-58RBFg@mail.gmail.com> On Wed, Dec 4, 2019 at 4:23 PM Amir Goldstein <firstname.lastname@example.org> wrote: > > On Wed, Dec 4, 2019 at 12:03 PM Mo Re Ra <email@example.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  and > you had some reservations, but I am not sure how strong they were. > Please refresh my memory. > > Thanks, > Amir. > >  https://github.com/amir73il/linux/commit/d3e2fec74f6814cecb91148e6b9984a56132590f Hi Amir, Thanks for your attention. Fanotify project had a big change since Kernel 5.1 but did not meet some primiry needs. For example in my application, I`m watching on a specific directory to sync it (through a socket connection and considering some policies) with a directory in a remote system which a user working on that. Some subdirectoires may contain two milions of files or more. I need these two directoires be synced completely as soon as possible without any missed notification. So, I need a syscall with complete set of flags to help to watch on a directory and all of its subdirectories recuresively without any missed notification. Unfortuantely, in current version of Fanotify, the notification just expresses a change has been occured in a directory but dot not specifiy which file! I could not iterate over millions of file to determine which file was that. That would not be helpful. Inevitably, xxx_SELF would not help me to meets all I need. Just to clarify, I dont mean xxx_SELF flags are useless. I mean Fanotify is a good project but the current version of that is not a project which meets some basic needs. Thanks, Mohammad Reza.
next prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-04 10:02 Mo Re Ra 2019-12-04 12:53 ` Amir Goldstein 2019-12-04 14:24 ` Mo Re Ra [this message] 2019-12-04 17:34 ` Jan Kara 2019-12-04 18:37 ` Amir Goldstein 2019-12-04 19:02 ` Matthew Wilcox 2019-12-04 20:27 ` Amir Goldstein 2019-12-11 10:06 ` Jan Kara 2019-12-11 13:58 ` Amir Goldstein 2019-12-07 12:36 ` Mo Re Ra 2019-12-10 16:55 ` Jan Kara 2019-12-10 20:49 ` Amir Goldstein
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CADKPpc33UGcuRB9p64QoF8g88emqNQB=Z03f+OnK4MiCoeVZpg@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ firstname.lastname@example.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git