Re: [PATCH 2/7] Conffile database handling functions
sean finney wrote:
> I think pkg:arch would suffice instead of pkg, right?
Yes, probably. I'm not sure whether arch:all packages are currently
tied to a specific arch.
> Yeah, I think previous versions of the patch series had "new", "old",
> "tmp", "cur" or similarly named directories, and various tricks were
> done to try and move the files between them
[...]
> I'm not 100% but believe that the current approach:
>
>> <admindir>/conffiles/<pkg>/<version>/<hash>
>
> avoids that by relying on the fact that we already know this
> information implicitly with the struct pkginfo version info, which
> would make things simpler
Yes, I agree --- it is saner. Thanks for a reminder.
[...]
>> What happens if ..._register_new_conffile is called and the conffile
>> was already registered?
>
> Then I think it just replaces the old version. Looking at the code the
> tmpfn is opened without O_EXCL and then is juse rename()'d to the dest.
Sounds good (to be idempotent). When upgrading to the "same" version,
this case would come up for every conffile. What's missing is a way
to unlink removed conffiles from the db and to deal with error unwind.
Probably makes sense to use O_TRUNC or unlink stale temporaries so
they can't cause harm.
OTOH I was hoping there would be some simple way to detect hash
collisions when they happen. Will be thinking more about this.
Reply to: