links=tidy inheritance

[Darren]

I've found some behavior in CFEngine that I wasn't expecting and I was
wondering if anyone else has noticed it or if it's meant to be
intentional.

I'm running 2.1.6 and have a few jobs under 'tidy' in multiple imported
config files.  One of these jobs cleans out /etc/rc3.d on solaris or
/etc/rc.d/rc3.d/ on Linux of any dead links using links=tidy.

A separate one from a different imported file using a different (but
sometimes overlapping) class deletes files matching a particular pattern,
let's call it *.FOO, from / .  'links=tidy' isn't specified and neither is
xdev=true.

On both of these platforms (it's actually Sol 7, Sol 8, Red Hat 7.2, Red
Hat 9 and Fedora Core 1) if either of the classes that run these jobs
activate then things happen as I would expect.  That is, symlinks in
/etc/rc3.d that don't point to any existing target are deleted or files in
the root partition name *.FOO are deleted.

If both of these classes are activated and cfagent (or cfexecd) doesn't
find a symlink in /etc/rc3.d to delete, the second job executes as
expected.

If BOTH of these classes are activated AND there are are symlinks to be
deleted in /etc/rc3.d, the second job inherits the links=tidy from the
first one and goes insane, deleting any symlink anywhere on the system
that doesn't point to an existing target, ignoring the default of
xdev=false (the xdev seems like a different discussion, though).

I've checked the changelog for versions since 2.1.6 and this doesn't seem
to have been specifically addressed.  Is it expected behavior?  I tried
adding links=keep, which is in my docs, but that generated an error.

Has anyone else run into and dealt with this?  I test all of my configs
before putting them out across the board, but didn't really anticipate the
activation of these two overlapping classes.  Coming to work to find 150+
messages listing multiple links that had been deleted with no indication
of where they had been pointing was disturbing.

--d