Thanks for explaining. I am using an internally developed, Python-based
backup system. It makes backups from Btrfs snapshots and regularly
verifies the integrity of the entire restore process. The verification
shows discrepancies such as the one above.
As most backup systems rely on mtime to detect changes for performance,
I suppose this is really a widespread problem. It probably goes
undetected in the majority of cases as backup systems usually don't do
100% integrity verification lacking file system snapshots.
My backup system uses regexp-based filtering to switch from mtime to
content change detection. In this case the relevant line in its YAML
configuration file is:
- { pattern: '^usr/share/doc/[^/]*/changelog[^/]*$', filter:
compare-contents }
The problem is not just limited to package installation files as this
excerpt shows:
- { pattern: '^var/lib/sudo/', filter: compare-contents }
- { pattern: '^var/lib/machines$', filter: compare-contents }
- { pattern: '^var/cache/man/(.*/)?index\.db$', filter: compare-contents }
And there are even more entries in my list. I wonder whether tinkering
with mtime is really such a good idea...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1816045
Title:
secureboot-db: release upgrade from 16.04 to 18.04 modifies
changelog.gz but resets mtime
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/secureboot-db/+bug/1816045/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
