tag 575891 pending
thanks
Hello,
Bug #575891 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=18b1208
---
commit 18b12083b5fee4e7e26e1382e50321e7956fcdb9
Author: Raphaël Hertzog <hert...@debian.org>
Date: Fri Apr 9 08:35:47 2010 +0200
dpkg: fix metadata installation by not mixing rename() in a readdir() loop
dpkg's process_archive() was doing the improper assumption that a
readdir() loop would not return the same filename twice even when the
scanned directory has files renamed into it (coming from tmp.ci).
The net result of having the same filename returned twice is that the
the second time the updated file to install is no longer there and
thus dpkg removed the current metadata file believing that it was
obsolete. btrfs triggers this bug consistently.
All other readdir() occurrences have been reviewed as well for similar
problems. But they are all safe, they mainly unlink() files rather
than adding new files into the scanned directory.
Thanks to Carey Underwood and Chris Mason for their help in diagnosing
this problem.
Acked-by: Guillem Jover <guil...@debian.org>
diff --git a/debian/changelog b/debian/changelog
index adaa95f..f699fea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,9 @@ dpkg (1.15.6.2) UNRELEASED; urgency=low
do not include that file in the generated source package.
* Improve explanation of --all option in dpkg-parsechangelog(1). Thanks to
Jari Aalto. Closes: #575706
+ * Fix dpkg to not lose package metadata on filesystems where readdir()
+ returns new files added after the opendir() call, btrfs in particular
+ triggered the problematic behaviour. Closes: #575891
[ Updated dpkg translations ]
* German (Sven Joachim).
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
