On Wed, Dec 04, 2019 at 08:37:09PM +0200, Amir Goldstein wrote: > On Wed, Dec 4, 2019 at 7:34 PM Jan Kara <jack@xxxxxxx> wrote: > > The problem is there's no better reliable way. For example even if fanotify > > event provided a name as in the Amir's commit you reference, this name is > > not very useful. Because by the time your application gets to processing > > that fanotify event, the file under that name need not exist anymore, or > > For DELETE event, file is not expected to exist, the filename in event is > always "reliable" (i.e. this name was unlinked). Jan already pointed out that events may be reordered. So a CREATE event and DELETE event may arrive out of order for the same file. This will confuse any agent. > > there may be a different file under that name already. That is my main > > objection to providing file names with fanotify events - they are not > > reliable but they are reliable enough that application developers will use > > them as a reliable thing which then leads to hard to debug bugs. Also > > fanotify was never designed to guarantee event ordering so it is impossible > > to reconstruct exact state of a directory in userspace just by knowing some > > past directory state and then "replaying" changes as reported by fanotify.
