On Fri, 2011-08-12 at 22:09:55 +0200, Raphael Hertzog wrote:
> On Fri, 12 Aug 2011, Jonathan Nieder wrote:
> > --- a/src/archives.c
> > +++ b/src/archives.c
> > @@ -851,7 +851,8 @@ tarobject(void *ctx, struct tar_entry *ti)
> > * in .dpkg-new.
> > */
> >
> > - if (ti->type == tar_filetype_file || ti->type == tar_filetype_symlink) {
> > + if (ti->type == tar_filetype_file || ti->type == tar_filetype_symlink ||
> > + ti->type == tar_filetype_hardlink) {
> > nifd->namenode->flags |= fnnf_deferred_rename;
> >
> > debug(dbg_eachfiledetail, "tarobject done and installation deferred");
That's what I was referring to with my comment of the proper way to
fix this. Which I've pushed now to the master and squeeze branches.
> But from a design point of view, it just seems wrong to not have all files
> treated the same. IMO we should be using deferred rename for all files except
> directories.
None of the other file types really need the deferred renames, and I
actually rather not have deferred renames at all! but oh well. Also
because we need to have the immediate rename code path in any case for
the directories I don't see the point in unneedingly deferring renames
for the other file types.
> Then one can wonder whether we ought to do something to ensure other types
> of files are written on the disk too... and whether adding a fsync() on
> hardlink brings anything. Since the hardlinks all point to the same inode,
> I guess a fsync() on the hardlink doesn't add anything,
Right, doing fsync() on anything other than a tar file or tar directory
is pointless.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
