MantisBT - Issues

0000671: incrond triggers files only once (even when changing by touch, no editors or file replacements)

Sun, 25 Dec 2011 16:19:23 +0100

Hello,

incrond triggers on file change only once after incrontable reload.

0000571: Fwd: Right quotation for incrontab

Fri, 02 Dec 2011 16:12:41 +0100

Email from: "Ing. Lukáš Jelínek - AIKEN"<lukas@aiken.cz>

-------- Pu*vodní zpráva --------
Pr(edme(t: Right quotation for incrontab
Pr(eposláno - Datum: Fri, 23 Sep 2011 18:19:44 +0200 (CEST)
Pr(eposláno - Od: incron@aiken.cz
Datum: Fri, 23 Sep 2011 18:11:24 +0200
Od: Narcis Garcia - GiLUG <informatica@actiu.net>
Pr(eposláno - Komu: incron@aiken.cz
Komu: incron@aiken.cz

Here comes a proposal for next fixes or versions:

There are 2 problems in incrontab tables about spaces: difficult to
automate spaces parsing for the path watched, and bad parameters
grouping to commands. My proposal is to give the opportunity of quotes
to work, in a more consistent way with shell scripting.

1. If quotes were alowwed to specify paths, automated generation of
tables could be easier, because instead of replacing every space by an
escaped one, a script could simply write quoted strings for all:
"/home/mike/Documents/My works"
instead of the current way:
/home/mike/Documents/My\ works

2. I see the current behaviour as a bug. When the command is something like:
/usr/local/bin/myscript.sh "$@/$#"
Then for a watched file as "/home/mike/Documents/My works/first one.odt"
myscript.sh receives (including quotes):
"$1": "/home/mike/Documents/My
"$2": works/first
"$3": one.odt"
"$4": (any next parameter)
This means that the quotes aren't used by incrond nor given right to
shell interpreter/execution. If you run in a normal shell:
myscript.sh "/home/mike/Documents/My works/first one.odt" hello world
The script receives right:
"$1": /home/mike/Documents/My works/first one.odt
"$2": hello
"$3": world

Thanks.

0000338: incron loses track of files edited by vim

Mon, 25 Jul 2011 22:35:02 +0200

When incrond is watching a file in /etc, repeated edits of the file
will cause incrond to lose track of it.

I'm using the following incron entry for testing, where /tmp/test.sh
simple logs `date`.
/etc/test IN_CLOSE_WRITE /tmp/test.sh

I can repeatedly touch /etc/test, and incron triggers.
If I open /etc/test in vim, the first edit triggers incron, but
subsequent edits do not.
After this, touching /etc/test no longer triggers incron either.
Sometimes, reloading the table doesn't work either, and the service
had to be restarted.

I've confirmed this on both centos and ubuntu machines, and with the
latest version of incron.

We're using it to watch some config files, and most people use vim to
edit them, so this has tripped me up a couple times.

0000541: fire event once in X seconds

Fri, 24 Jun 2011 00:18:34 +0200

Sometimes firing an event if something happened in the last second or minute or hour is good enough and it would be easier to have an option right into incron.

0000540: exclude files matching PATTERN

Fri, 24 Jun 2011 00:18:12 +0200

It is sometimes useful to watch directories but exclude some filetypes or just one directory and I didn't find a way to do this elegantly.

0000539: Improper parsing of spaces, quotes and other meta-characters

Mon, 13 Jun 2011 12:20:53 +0200

As mentioned numerous times, incron seems to have a huge problem with handling space parsing:

http://bts.aiken.cz/view.php?id=174 [^] (spaces in filenames)
http://bts.aiken.cz/view.php?id=98 [^] (bis)
http://bts.aiken.cz/view.php?id=528 [^] (spaces in EDITOR environment variable)

I guess the whole parsing approach is the problem here.
Various builtin functions in C are able to handle easily this problem.
For example:
http://linux.die.net/man/3/system [^] + escaping " and ' would be a great start.

From a coding point-of-view, this is quite simple todo.
From a user point-of-view, this is quite a show-stopper.

Various workaround have been in the wild for a while now (e.g. http://bts.aiken.cz/view.php?id=174#c355 [^] ) but are not really acceptable.

An "ugly but acceptable" work-around would be to have a (eventually per-file, although this may be too complicated for a simple/temporary fix) configuration to provide a column delimiter for incrontab files.

For example:

separator=;

would provide incrontab files like this:

path;flag1,flag2,flag3;command;arg1;arg2 with spaces;$@/$#;etc...

This would then allow for easy insertions of spaces in commands.
Moreover this kind of structure is very easy to use with, say, one of the exec(3) family ( http://linux.die.net/man/3/exec [^] ).

0000528: EDITOR with flags fails

Sun, 20 Mar 2011 01:17:37 +0100

When I set my $EDITOR to anything with a space (ie "nano -LSw"), incrontab fails.

0000525: List of supported events

Thu, 24 Feb 2011 16:06:43 +0100

Where can I can find the entire list of events that the INCRON supports? It would be interesting to this list describing what they mean or what they are used for.

TIA

Marcos Nobre

0000512: Makefile improvements

Mon, 31 Jan 2011 22:34:42 +0100

Description of the patch:
Respect DESTDIR.
Don't override CXX/CXXFLAGS/LDFLAGS.
Create all necessary directories during install.
Install the example configuration into $(PREFIX)/share/doc/... instead of /etc.

0000511: Problem with Debian Sqeeze (originally mailed to incron@aiken.cz)

Mon, 31 Jan 2011 22:34:20 +0100

Debian Sqeeze

Installation from repository with apt-get install incron.

incrontab -l
/root IN_CREATE ls

touch /root/test

Extract from syslog:

Jan 26 09:23:55 ns5 incrond[17504]: starting service (version 0.5.9, built on Jan 31 2010 23:16:22)
Jan 26 09:23:55 ns5 incrond[17505]: loading system tables
Jan 26 09:23:55 ns5 incrond[17505]: loading user tables
Jan 26 09:23:55 ns5 incrond[17505]: ready to process filesystem events
Jan 26 09:26:19 ns5 incrond[17505]: table for user root created, loading
Jan 26 09:26:57 ns5 incrond[17505]: (root) CMD (ls)

The ‘ls’ command in the example above is not executed. Other commands or program calls tested are not executed too. We also tested incrontab without success for normal users. It seems it’s not working at all. The same behavior was observed in two different machines with Debian Sqeeze installed.

Is this a Debian Squeeze bug or did we miss some configuration?

0000447: build fixes for gcc4.4

Mon, 31 Jan 2011 21:17:29 +0100

We've been carrying the attached patch for a while now in Fedora, would you mind including it?

0000385: Fail to build with GCC 4.4

Mon, 31 Jan 2011 21:17:16 +0100

Incron failed to build with the upcoming GCC 4.4.

GCC 4.4 cleaned up some more C++ headers. It requires to #include headers directly and cannot rely for things to be included indirectly.

A patch is attached to fix this issue.

0000510: Captcha problems (originally mailed to incron@aiken.cz)

Mon, 31 Jan 2011 17:35:11 +0100

Hey guys,

please fix the captcha image because I'd like to register a new account :)

-- Regards, Christian Ruppert

0000456: Mailing list subscription fails

Mon, 31 Jan 2011 16:20:00 +0100

When I tried to subscribe to the mailing list, my message was rejected as SPAM.

Below is the error message (I've removed my domain name since this issue will be public).

I used the email address associated with this Mantis account.

0000492: Problem with user groups

Sat, 04 Dec 2010 16:37:05 +0100

We are using incron to manage replication of files between two web
servers. The files are created by Apache, and are in the Apache group.
The user who runs the incron script is in the Apache group.

If I run 'groups' from the command line as the incron user, I get:

wps apache

If I run 'groups' from a normal cronjob, I get:

wps apache

But if I run groups from a script called by incron, I get:

wps root bin daemon sys adm disk wheel

Is incron loading the user's groups incorrectly?

0000491: IN_DELETE_SELF doesn't work

Fri, 03 Dec 2010 00:21:22 +0100

i'm using Debian Testing and have noticed that incron doesn't seem to process
IN_DELETE_SELF action properly. shortly, i create a sample dir/file and add line
like "/path IN_DELETE_SELF some_action", but when i delete watched file/dir
(using rm or rmdir) nothing happens. other things i've tried seem to work right.
please see attached file for original action log (if /tmp/1 is a file, things go
the same way)

0000470: Root receives undocumented IN_IGNORED event

Sat, 21 Aug 2010 16:37:44 +0200

Root, via /etc/incron.d/foo, received an IN_IGNORED event when monitoring file foo when emacs (I believe) deleted foo~ in a second editing session after, in an initial editing session, changing the name of foo to foo~ and leaving it as a backup file.

The identical incrontab entry in the user's incrontab

/home/kop/tmp/incron/foo IN_MODIFY,IN_ATTRIB,IN_CLOSE_WRITE logger -t rootincrontab "Received event $%"

received no such event. (AFAICT)

In any case IN_IGNORED is not documented in the incrontab(5) man page.

0000469: Incron needs a new symbol to track files by path

Sat, 21 Aug 2010 16:37:21 +0200

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.

0000468: incron logs command to execute but command is not executing

Sat, 21 Aug 2010 16:37:03 +0200

Attaching usage log, for reference.

# empting "log"

andres@terminus:~$ > /tmp/ic.log

# verifying incrontab

andres@terminus:~$ incrontab -l
/home/andres/maps IN_MODIFY /usr/bin/make -C $@ > /tmp/ic.log 2>&1

# modifying file

andres@terminus:~$ cat > maps/all.dot < > digraph
> {
> nod
> }
>

# validating date

andres@terminus:~$ date
Tue Jun 1 10:01:39 COT 2010

# verifying syslog, the commands is "executed"

andres@terminus:~$ su -c "tail -5 /var/log/syslog"
Password:
Jun 1 10:01:33 terminus incrond[5924]: (andres) CMD (/usr/bin/make -C /home/and
res/maps > /tmp/ic.log 2>&1)
Jun 1 10:01:33 terminus incrond[5924]: (andres) CMD (/usr/bin/make -C /home/and
res/maps > /tmp/ic.log 2>&1)

# verifying Makefile

andres@terminus:~$ cat maps/Makefile
all: all.png

all.png: all.dot
dot -Tpng $< > $@

# log is empty

andres@terminus:~$ cat /tmp/ic.log

# outfile is outdated

andres@terminus:~$ ls -l maps/all.png
-rw-r--r-- 1 andres andres 12457 2010-06-01 09:58 maps/all.png

# the command works

andres@terminus:~$ /usr/bin/make -C /home/andres/maps > /tmp/ic.log 2>&1

# outfile is updated

andres@terminus:~$ ls -l maps/all.png
-rw-r--r-- 1 andres andres 133 2010-06-01 10:04 maps/all.png

# "log" is logging

andres@terminus:~$ cat /tmp/ic.log
make: Entering directory `/home/andres/maps'
dot -Tpng all.dot > all.png
make: Leaving directory `/home/andres/maps'

andres@terminus:~$ date
Tue Jun 1 10:05:11 COT 2010

# weird

0000397: duplicate events firing

Fri, 02 Jul 2010 14:23:34 +0200

incrond: 0.5.8
Kernel 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008 i686 i686 i386 GNU/Linux

I cannot explain this one.

incrond is reporting multiple events where events only happened (AFAIK) one time. This has been confounding as, if I trigger file operations against IN_CLOSE_WRITE, sometimes these operations are being launched twice (sometimes three times) and are therefore clobbering one another.

Details below.

0000449: incrontab(1) mangles comments in incrontab(5)

Sat, 05 Jun 2010 23:46:43 +0200

incrontab(1) mangles comments in incrontab(5): it changes the first word on every comment line to "0". For example, if I run incrontab and create a file with the following comment lines:

# Only put 1 space between fields 2 and 3! Additional whitespace will be
# assumed to be part of field 3, causing the command to fail!

then incrontab -l shows that I have the following incrontab file:

# 0 put 1 space between fields 2 and 3! Additional whitespace will be
# 0 to be part of field 3, causing the command to fail!

To clarify, this doesn't just matter because of comments, although they're important. It also means that I can't temporarily disable a line by commenting it out-- if I do, then incrontab will replace the path entry by a 0.

0000461: Allow line wrapping

Sat, 05 Jun 2010 23:43:20 +0200

It would be good to have possibility to wrap lines in incron tables (eg. using the backslash character). Very long lines are poorly readable.

0000459: Get cookie when IN_MOVE* event is thrown

Fri, 21 May 2010 01:02:03 +0200

Hello,

Don't be to cruel, I have never coded in c++ but I made a patch that allow me to get the cookie when an IN_MOVED_TO, IN_MOVED_FROM or IN_MOVE events are thrown.
It replace the $§ parameter on the entry line.
I don't know if it's the best symbol for that and if someone is interested in it, but it's avoid me real pain to track some mv in folders.

Hope you will enjoy it and I am open to remarks

JC Passard

0000457: Inotify maintains list of InotifyWatch objects that could be dead

Mon, 26 Apr 2010 22:05:24 +0200

In the example.cpp, only one watch is added, and remains in-scope during the whole process. However, if I want to add more than one watch, and do so in a for-loop, the watch goes out of scope, and thus Inotify::GetWatch() references a dead object.

Attached is an example of what I'm talking about, with some output for when InotifyWatch is constructed/destructed.

And since InotifyWatch has no default constructor, there's really no way to create an array of InotifyWatch* that will outlast the Inotify object, and thus remain alive.

My thought would be to make a copy of the InotifyWatch* when it is added, and then make sure to clean up when RemoveAll() is executed. However, since this code has been around for a long time, I'm guessing there's a reason you didn't do it that way, and I'd love to hear why.

Also, you've got two Inotify::Add() methods, one for a reference, and one for a pointer, thereby implying that object lifetime is handled differently depending on which method is used.

0000455: Minimizing to the systen tray

Sat, 27 Mar 2010 13:41:47 +0100

Try to find a platform independent way how to implement minimizing to the system tray.