Your message dated Thu, 27 Mar 2008 23:08:38 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Copying same destination file twice fails - fixed in April 2007
has caused the Debian Bug report #232512,
regarding cfengine2: Copying same destination file twice fails
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
232512: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232512
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: cfengine2
Version: 2.0.9+2.1.0b5-1
Severity: normal
Tags: patch
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 */
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (999, 'unstable'), (999, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.0+juhaj+v1.0.2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Versions of packages cfengine2 depends on:
ii debconf 1.4.8 Debian configuration management sy
ii debianutils 2.6.2 Miscellaneous utilities specific t
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libdb4.1 4.1.25-16 Berkeley v4.1 Database Libraries [
ii libssl0.9.7 0.9.7c-5 SSL shared libraries
ii perl 5.8.3-1 Larry Wall's Practical Extraction
-- debconf information excluded
--- End Message ---
--- Begin Message ---
Hi,
Mark Burgess fixed this bug in April 2007, and I've doublechecked the
code now. Closing the bug.
- Werner
--- End Message ---
