[Box Backup] I have the fear....

[Chris Wilson]

Hi Ben,

On Wed, 14 Mar 2007, Ben Bennett wrote:

> On Wed, Mar 14, 2007 at 10:44:22PM -0400, Ben Bennett wrote:
>> So it is not dispatch-conf.  It is emerge itself.  I see it changing
>> the timestamp of both the real file in /etc and the new config.
>
> And I think I have the smoking gun.
>
> Line 7190 of /usr/lib/portage/pym/portage.py

I have Portage 2.1.1 and it has no such line. So this looks like a newly 
introduced bug.

>    # whether config protection or not, we merge the new file the
>    # same way.  Unless moveme=0 (blocking directory)
>    if moveme:
>        mymtime=movefile(mysrc,mydest,newmtime=thismtime,sstat=mystat, mysettings=self.settings)
>        if mymtime is None:
>            sys.exit(1)
>        zing=">>>"
>    else:
>        mymtime=thismtime
>        # We need to touch the destination so that on --update the
>        # old package won't yank the file with it. (non-cfgprot related)
>        os.utime(mydest,(thismtime,thismtime))
>        zing="---"

I'm not sure whether this is a bug, because I'm not sure why it touches 
the destination in this case. Probably, rather than playing with the 
mtime, they should just record the fact that the file is needed by another 
package and should not be unmerged in some database somewhere.

> Leads to both the original conf file and the ._cfg... one to have a good 
> chance of having the same mtime if you get unlucky and it can make it 
> from the piece of code that sets the thismtime variable to the 
> subroutine that has the code from line 7190 before time moves on.

Very very likely. Fast processors and caching mean that 99% of the time 
you will not get a clock tick during these operations.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |