Remove spurious leftover .dpkg-tmp files after unpacking failure

Renaming the backup copy to the old name is a no-op if these are
hard links to the same file. So we need to remove the backup copy
afterwards to make sure it is gone.

Closes: #591993

Signed-off-by: Guillem Jover <guillem@debian.org>

debian/changelog

@@ -19,6 +19,11 @@ dpkg (1.15.8.4) UNRELEASED; urgency=low
   * When analyzing the ELF format of a binary in dpkg-shlibdeps, fallback on
     usual objdump when the cross objdump failed. Closes: #591522
 
+  [ Sven Joachim ]
+  * Ensure removal of leftover backup .dpkg-tmp files after unpacking
+    failures, when the backup is still a hard link to the original file.
+    Closes: #591993
+
  -- Guillem Jover <guillem@debian.org>  Thu, 05 Aug 2010 17:42:51 +0200
 
 dpkg (1.15.8.3) unstable; urgency=low

src/cleanup.c

@@ -90,6 +90,10 @@ void cu_installnew(int argc, void **argv) {
     /* Either we can do an atomic restore, or we've made room: */
     if (rename(fnametmpvb.buf,fnamevb.buf))
       ohshite(_("unable to restore backup version of `%.250s'"),namenode->name);
+    /* If <foo>.dpkg-tmp was still a hard link to <foo>, then the atomic
+     * rename did nothing, so we make sure to remove the backup. */
+    else if (unlink(fnametmpvb.buf) && errno != ENOENT)
+      ohshite(_("unable to remove backup copy of '%.250s'"), namenode->name);
   } else if (namenode->flags & fnnf_placed_on_disk) {
     debug(dbg_eachfiledetail,"cu_installnew removing new file");
     if (unlinkorrmdir(fnamevb.buf) && errno != ENOENT && errno != ENOTDIR)