Morten Werner Olsen wrote:
Hi!
I am trying to clean a bit in the open bugreports against cfengine2 in
the Debian BTS[1]. This mail is about an old bug that noone has
commented on yet, but as I believe still is an issue with 2.1.20.
This is bug #232512 [2]:
I have a cfengine2 configuration, where occassionally (on purpose!)
during a single run of cfexecd, a destination file gets copied from
two different locations on the server. For example:
/foo/file dest=/foo/bar server=host backup=true
/foo2/file dest=/foo/bar server=host backup=true
This results, in /foo:
/foo/bar (identical to /foo/file)
/foo/bar.cfsaved (identical to whatever there was originally)
/foo/bar.cfnew (identical to /foo2/file)
Obviously, the latter copy has failed. During the next run, the first
copy line copies nothing since /foo/bar is already identical to
/foo/file and thus the directory now looks like:
/foo/bar (identical to /foo2/file)
/foo/bar.cfsaved (identical to /foo/bar)
Then we go back to square one and repeat this all over again. The
culprit is lines 1509-1512 in image.c:
if (IsItemIn(VREPOSLIST,backup))
{
return true;
}
This exits the whole CopyReg() and leaves .cfnew in place if AND ONLY
IF, the same file (i.e. /foo/bar) was already in backup
repository. Thus, the quick hack is to change either of the two lines
to NOT create backups. However, it is, in my opinion, the wrong
solution. Correct behaviour should be to either create a backup of a
backup (troublesome), skip backup of a file already backed up (my
choice) or at least print out a warning. The first one may be a little
difficult to implement, but the second one is easy: change "return
true;" to "continue;". This would skip the remainder of the backup
procedure and continue as if it had been backed up. I do not think any
harm would come from this, since the *original* file was already
backed up earlier and now we just skip backing up a file cfengine
previously copied into place. The patch is untested (I only have
production systems at hand at the moment), but should work.
--- image.old.c 2004-02-13 11:45:28.000000000 +0200
+++ image.c 2004-02-13 11:45:57.000000000 +0200
@@ -1508,7 +1508,7 @@
if (IsItemIn(VREPOSLIST,backup))
{
- return true;
+ continue;
}
/* Mainly important if there is a dir in the way */
After looking at the code, this is still an issue, right? So what do
you think? The bugreport can be found at [2].
- Werner
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=cfengine2
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232512
_______________________________________________
Bug-cfengine mailing list
Bug-cfengine@cfengine.org
http://cfengine.org/mailman/listinfo/bug-cfengine
The proposed patch is not correct, since there is no loop to continue.
However the analysis is okay -- I have patched the svn code to that
the behaviour you suggest is honoured. (Previously the user was warned
of this silly request - I believe that was okay, but now you get both
a warning and the multiple copy honoured as suggested.)
--
Mark Burgess
Professor of Network and System Administration
Oslo University College
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272 Email: [EMAIL PROTECTED]
Fax : +47 22453205 WWW : http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
