Re: [PATCH 2/7] Conffile database handling functions
On Fri, May 06, 2011 at 02:59:52AM -0500, Jonathan Nieder wrote:
> Ah, memories. The main piece to revisit might be what sort of
> identifier to use for <pkg> in these modern days of multiarch. I also
I think pkg:arch would suffice instead of pkg, right?
> think there was some talk about atomic renames across directories
> versus renaming symlinks to commit to a choice of directory ---
> perhaps someone can remind me?
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 without having to move
every file, and then something similar was done with symlinks for
a while.
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 since then every package puts files into
a uniform place and no special handwaving is required.
So I *think* we dropped that fairly contentious stuff.
> The ..._register_new_conffile API seems a bit odd to me. Would it
> make sense to return a pathname and let the caller do the
> write/fsync/rename work? That way it could do a batch of writes
> followed by a batch of renames if wanted.
I think the idea was to slip in as clean as possible with the
existing codebase--where the tar/archive stuff was the, code
was reading from a pipe fd, so this made for the least footprint
there. Not saying it's the best design for general use, but that was
the motivation anyway.
> 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.
sean
Reply to: