Re: incron vs. files of uncertain existence

Hello,
I will try to answer.

> I've got two related issues here, really. :)
>
> I) Currently, if a path defined in an incrontab doesn't exist, it's just
> ignored. Would it be possible to have a flag (X_IN_MIGHT_NOT_EXIST) which
> would cause the following behavior?
>
> 1) if path to watch exists, act normally
> 2) if it doesn't exist, set up a watch for the parent directory
> (recursively up to /, if necessary) which would look for the original
> path to be created and at that point
> a) delete the impled parent-directory watches
> b) add the original watch as given in the config file.
>
>
> I can think of a rather complicated scheme using the existing system and
> some scripting to recreate this behavior (basically, self-modifying
> incrontabs -- ugh), but it seems like a common enough use case that having
> it dealt with in the main program would be more graceful.
>

You aren't the first who requests such feature. But I think your idea
might lead to relatively complicated implementation and high overhead in
some cases. I have considered some different solution: to place
non-existing paths into a queue and examine them periodically (e.g. each
15 secs by default). The discussion is still open and the final solution
should comply the most wanted requirements.

>
> II) I was trying to make a script which acted on changes to /etc/group. To
> my initial puzzlement, the watch would fire once and then be lost. I quickly
> realised: oh yeah, the origial file is being backed up, then a whole new one
> overwrites it. This is causing the watch to get silently lost.
>
> I worked around this by using "IN_CLOSE_WRITE,IN_ONESHOT" and then touching
> my incrontab (it's in /etc/incron.d; could use --reload for personal
> incrontabs, of course), forcing it to reload.
>
> This works, but it seems like there's got to be a more elegant way. Would it
> be possible to encapsulate a similar behavior into incrond itself? Again,
> this seems like a pretty common case.
>
>
> As a note to the above: if I don't use IN_ONESHOT, this results in
>
> incrond[19715]: system table rootalias-manager.incron changed, reloading
> incrond[19715]: *** unhandled exception occurred ***
> incrond[19715]: void Inotify::Remove(InotifyWatch*): removing watch failed
> incrond[19715]: error: (22) Invalid argument
>
> and incrond dies. Oops.
>
>

I will copy you report into the BTS and try to analyze it. But please be
patient. I'm currently really busy and can't dedicate much time to incron.

Regards,

Lukas
Received on Sun Jul 01 2007 - 18:42:27 CEST