Re: directory notifications lost after fork?

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

Daniel Phillips wrote:
> On March 12, 2002 01:55 pm, Jamie Lokier wrote:
> >    - dnotify causes files to notify their parent directory (yes it's
> >      ambiguous with hard links).
> 
> That's a bitch, isn't it?  The only way I can think of to deal with it
> is via a hardlink reverse map, and there are lots of worms in that
> can, including where you store it, how much it costs to maintain it,
> how persistent it should be and how to make it perfectly non-racy.

For dnotify purposes this may be solvable without a full reverse map.
Suppose that we have per-inode notifiers as I suggested, and as the imon
patch implements.  Of course, multiple listeners can attach to an
inode's notifier chain -- this is needed to support multiple processes
listening.

Then you can implement dnotify by attaching the parent directory as a
listener to each of its child inodes.  (It's a bit heavy to set up,
though).

Now, when an inode is modifed we don't guarantee to notify all the
parent directories...  but we do guarantee to notify all the ones which
are actually listening at the moment.  So it's a partial reverse map.  I
expect Al Viro would have something to say about dcache races at this
point.

For recursive parent notification, such as monitoring "/usr" to learn
about changes anywhere underneath "/usr", the above is perhaps
impractical.  We're right back to having to do "find -print" equivalent
disk activity.  Or reverse maps in the filesystem.  Ugh.

In practice I'd just give up trying to cache stat() results of hard
linked files, unless I knew I'd found all the paths to those files.
Just don't use hard links ;-)

cheers,
-- Jamie