If you emerge a package and it needs to write to a config protected directory it correctly makes a ._cfg... version of the file. However, it also updates the time stamp (mtime in particular) of the source file. So when you have finished the emerge you have a pair of files with the same timestamp (e.g. /etc/hosts and /etc/._cfg0000_hosts). The problem arises if a backup occurs between the time the emerge creates those files and when you update the conf files. If you accept the new version of the file then it is moved on top of the original... the contents have changed, but the mtime timestamp is preserved. The next time the backup runs it does not see the change. Reproducible: Sometimes Steps to Reproduce: 1. Run an emerge that makes a ._cfg... file somewhere 2. Look at the new config mtime and the old config mtime (with stat) 3. Run dispatch-conf 4. Accept the new version of the file without edits 5. Look at the mtime on the final file (with stat) Actual Results: The mtimes on the both files from step 2 and the resulting file in step 5 are extremely likely to be the same. There is a slim chance they may not be if more than a second manages to pass between two calls to utime in the code, but on my machine it is always reproducible. Expected Results: Different mtimes, at least between steps 2 and 5. Portage version: sys-apps/portage-2.1.2.2 Architecture: AMD X86 (32 bit) Backup software: app-backup/boxbackup-0.10 I use dispatch-conf to do the config merging The error seems to be around line 7190 of /usr/lib/portage/pym/portage.py (rev 5647) in the isprotected() subroutine. The problem is that it does a utime on the original file, passing in None as the timestamp to update it to the current system time. If it is still the same second that the outer code got its timestamp for the thismtime argument to mergeme (set into the mymtime variable on line 7424) then it will end up with the same value. A possible fix would be to set mymtime to 1 second before the current time thus ensuring that a collision is impossible. The above bug still exists in the current SVN code, but the affected file seems to now be pym/portage/dbapi/vartree.py.
Thanks, this is fixed in svn r6216.
This has been released in 2.1.2.3.
