On Wed, Dec 11, 2019 at 12:06 PM Jan Kara <jack@xxxxxxx> 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.