GNOME Bugzilla – Bug 731924
/etc merge prefers empty directory chains over new content
Last modified: 2018-08-17 19:00:27 UTC
Scenario: version 0: /usr/etc/foo is an empty directory in the tree (and gets copied to /etc/foo) version 1: /usr/etc/foo/some-file.txt appears On upgrades, I'm seeing some-file.txt *not* show up, presumably because ostree is assuming that all files in the directory were deleted. I think we need to recognize this case specially.
Created attachment 278802 [details] [review] tests: Add a test for an empty /etc directory gaining content
This turned out to be a different problem: version 0: /usr/etc/foo does not exist At runtime, a program runs mkdir -p on /usr/etc/foo, but doesn't add any files there. This creates a delta versus the default. version 1: /usr/etc/foo/some-file.txt is added Now, because that whole directory counts as modified, we override it and leave it empty. Clearly the correct thing here is to do one or both of: 1) Fix the OS to ship /usr/etc/foo if a program is expected to write to it 2) Fix the app to not mkdir -p on it if it's not actually writing anything There is however also the option to change OSTree's /etc handling to explicitly recognize this situation.
Comment on attachment 278802 [details] [review] tests: Add a test for an empty /etc directory gaining content Just pushing this test, doubt anyone has objections =) Attachment 278802 [details] pushed as b2329cf - tests: Add a test for an empty /etc directory gaining content
OSTree has moved to Github a while ago. Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org. If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you! Closing this report as WONTFIX as part of Bugzilla Housekeeping.