Re: File monitor problem

[Amir Goldstein <amir73il@gmail.com>]

On Wed, Dec 11, 2019 at 12:06 PM Jan Kara <jack@suse.cz> wrote:
>
> On Wed 04-12-19 22:27:31, Amir Goldstein wrote:
[...]
> > The way to frame this correctly IMO is that fsnotify events let application
> > know that "something has changed", without any ordering guaranty
> > beyond "sometime before the event was read".
> >
> > So far, that "something" can be a file (by fd), an inode (by fid),
> > more specifically a directory inode (by fid) where in an entry has
> > changed.
> >
> > Adding filename info extends that concept to "something has changed
> > in the namespace at" (by parent fid+name).
> > All it means is that application should pay attention to that part of
> > the namespace and perform a lookup to find out what has changed.
> >
> > Maybe the way to mitigate wrong assumptions about ordering and
> > existence of the filename in the namespace is to omit the event type
> > for "filename events", for example: { FAN_CHANGE, pfid, name }.
>
> So this event would effectively mean: In directory pfid, some filename
> event has happened with name "name" - i.e. "name" was created (could mean
> also mkdir), deleted, moved. Am I right?

Exactly.

> And the application would then
> open_by_handle(2) + open_at(2) + fstat(2) the object pointed to by

open_by_handle(2) + fstatat(2) to be exact.

> (pfid, name) pair and copy whatever it finds to the other end (or delete on
> the other end in case of ENOENT)?

Basically, yes.
Although a modern sync tool may also keep some local map of
remote name -> local fid, to detect a local rename and try to perform a
remote rename.

>
> After some thought, yes, I think this is difficult to misuse (or infer some
> false guarantees out of it). As far as I was thinking it also seems good
> enough to implement more efficient syncing of directories.

Great, so I will work on the patches.

> Mohammad, would
> this kind of event be enough for your needs? Frankly, I'd like to see a
> sample program (say dir-tree-sync) that uses this event before merging the
> kernel change so that we can verify that indeed this event is usable for
> practical purposes in a race-free way...
>

I will prepare demo code for the new API based on inotifywatch.
Mohammad, if you like you could use the demo code to present a sync tool.
I am hoping to be able to integrate the new API with Watchman as a demo.

Thanks,
Amir.