mergemaster -U overwriting modified files

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Mel Flynn wrote:
> On Sunday 26 April 2009 11:12:12 Frederique Rijsdijk wrote:
>> Bruce Cran wrote:
>>> On Sat, 25 Apr 2009 12:10:42 +0200
>>>
>>> Peter Schuller <peter.schuller at infidyne.com> wrote:
>>>> I recently began testing mergemaster -U since the perpetual "review
>>>> diff of file I never touched" grows annoying real quick.
>>>>
>>>> Unfortunately I recently discovered that it does not seem to do what
>>>> you might expect. For example it nuked my mailer.conf on one machine,
>>>> and my /etc/namedb/named.conf (!!!) on another machine.
>>>>
>>>> Is this a bug or intended? What is the intended functionality of -U?
>>> I noticed this recently too: after using mergemaster -U without
>>> problems for a long time it suddenly went and overwrote named.conf on
>>> a recently upgrade of 7-STABLE.
>> I've seen this happen as well with named.conf.
> 
> I think I know the cause, not entirely the problem yet, as I just got hit by 
> this too and right at the point where I upgraded source tree from cvs to svn 
> so *all* files had different idents.
> 
> Before running mergemaster -iU I checked /var/db/mergemaster.mtree and it was 
> zero-sized. Why, is not entirely clear, (hence, I don't know the real problem) 
> but I thought I noticed mergemaster saving mtree database on the pre-world 
> run. Looking at the code though, this should be impossible, so the more I 
> think about it, the more I start to doubt. At the time I was thinking why is 
> mergemaster saving the mtree and that's when I checked it's size.
> 
> Whatever the cause, this is where mergemaster fails:
> CHANGED=
> if [ -n "${AUTO_UPGRADE}" -a -f "${DESTDIR}${MTREEFILE}" ]; then
>         for file in `mtree -eq -f ${DESTDIR}${MTREEFILE} -p ${DESTDIR}/ \
>                 2>/dev/null | awk '($2 == "changed") {print $1}'`; do
>                 if [ -f "${DESTDIR}/$file" ]; then
>                         CHANGED="${CHANGED} ${DESTDIR}/$file"
>                 fi
>         done
> fi
> 
> Because ${MTREEFILE} is empty, the mtree command will not produce output and 
> CHANGED will not be populated. For things like this, it would be nice if mtree 
> supported a 'lint' mode to check syntax, but at the very least could 
> mergemaster test for -s rather then or in addition to -f?

Thank you for your analysis Mel. This problem has come up on other
lists as well, and while I don't have an answer for why the mtree file
is getting reduced down to zero size (which shouldn't actually be
possible) I had pretty much come to the same conclusion as you did
that this must be the cause of the problem.

I just committed r192230 which changes -f to -s in several places, and
also adds some new safety belts to the way that mergemaster creates
and uses the list of changed files in the comparison process. I think
that these changes will solve the effects of the problem (an empty
CHANGED list as a result of an empty mtree file). I also changed a -f
to a -s on the routine that saves the new mtree file, so hopefully
whatever the bug is that created this problem in the first place will
no longer be able to wreak havoc.

If you're interested in trying the new version you can just grab the
one from HEAD via the cvs or svn interfaces and run it on RELENG_[67]
without any problems.


hope this helps,

Doug

- --

    This .signature sanitized for your protection

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEAREDAAYFAkoPRdcACgkQyIakK9Wy8PvTqACg1Lw8ICzT7XyicSeOA9K+8834
lwYAn3g7bmuM4YeGMDyYYjKYClHvLohb
=9JuD
-----END PGP SIGNATURE-----