does inotify leak when monitored objects are deleted?

[blaenk]

I'm wondering what happens if a monitored object is deleted. I'm wondering if it would remain/leak/linger in the watches map. Perhaps we can watch for the IN_DELETE_SELF event for each watched path, and if triggered, we remove the entries? Not sure if that'd work.

           IN_DELETE_SELF
                  Watched file/directory was itself deleted.  (This event
                  also occurs if an object is moved to another filesystem,
                  since mv(1) in effect copies the file to the other
                  filesystem and then deletes it from the original
                  filesystem.)  In addition, an IN_IGNORED event will
                  subsequently be generated for the watch descriptor.

Also from TLPI:

An IN_IGNORED event is generated when a watch is removed. This can occur for two reasons: the application used an inotify_rm_watch() call to explicitly remove the watch, or the watch was implicitly removed by the kernel because the monitored object was deleted or the file system where it resides was unmounted.

So I think monitoring for IN_IGNORED should be enough. When we receive it, we remove the entries from our own data structures.

[jwilm]

That sounds right

[passcod]

When this happens, should we also notify the user? How?

[jwilm]

@passcod you mean in addition to the REMOVE event? We could deliver and IGNORE event as well.

[blaenk]

The way we'd discover this in rsnotify ourselves is itself a notification. That is, IN_DELETE_SELF or IN_IGNORE. I don't think we currently propagate IN_IGNORE because it probably doesn't have a "generic" equivalent on the other back-ends. My understanding from what I quoted is that first we would get an IN_DELETE_SELF which we propagate to the user as usual, then when we receive an IN_IGNORE we should remove the entries from the structures. I think it's reasonable for them to conclude that if it was deleted, they won't be getting any events for it anymore. Or if we're okay with introducing an IGNORE event then we can just propagate that as well.

[passcod]

Right, no, just sticking to the current events should be fine :)