ar-
[Debian Bug #592691] Incron needs a new symbol to track files by path
This bug report is a copy of https://bugs.debian.org/592691
[Karl O. Pinc]
Incron exhibits somewhat inconsistent behavior in that it tracks files by inode (I assume) but these files are specified by path in the incrontab. So, if you delete a file and re-create it, as some commonly used editors do as part of the editing process, the file is no longer tracked -- until incrond is restarted or (I assume) the incrontab file is modified at which point the (new) file is again tracked. This 'impedance mismatch' is a bit odd.
I assume this is the intended design. It is the behavior I observe.
If nothing else a note of this issue should be made in the documentation.
It would be nice if incron had a new symbol, say IN_TRACK_PATH, that keeps the tracking associated with the pathname given in the config file. I assume this could be done by monitoring the parent directory for changes and watching for the file name to come into existence, the name of the file to change, etc.
I would think that the desire to track changes to a file that exists in a particular filesystem location is rather common. Absent this feature it's up to the user to repeatedly script such things.
Note that such a change alters the meaning of existing symbols, e.g., changing the file name would be equivalent to deleting the file, etc. I don't know whether it makes sense to re-use the existing symbols in this new context or to come up with entirely new ones.
The behaviour of tracking by inode instead of by file name is normla for inotify. The suggestion is this bug report, to observe the parant directory. This bug reports is from 2010. I have alrady added a feaure to abserve files by wildcard patterns like:
/home/user1/Pictures/*.jpg
and that does exactly the suggested reload of all the file observers.
The suggested IN_TRACK_PATH sounds interesting, but (while it might be intended for one user) it might be unexpected behaviour for other users. Especially, for people who use inotify since a longer time. I will think about if this makes sense.
Any feedback, if this problem is solved with the wildcard definitions are welcome.
The wildcard matches don't actually seem to work out in 0.5.12 currently, so no not resolved.
