On Thu, 2009-08-13 at 09:42:04 +0200, Raphael Hertzog wrote: > On Thu, 13 Aug 2009, Guillem Jover wrote: > > dpkg does not directly extract the control files, it uses dpkg-deb and > > that ones uses tar to extract those files. So either filesystem or tar > > related, but very improvable to be dpkg itself. > > Doesn't dpkg do some renames afterwards? IIRC renames must also be > protected by fsync() calls on the directory file descriptor (although that > part has been mostly fixed again in recent kernels by new heuristics).
One of the problems is for example ending up with an empty file, but that should not happen as long as one does the fflush, fsync, fclose dance just before the rename, on a crash you should either get the new file or whatever was there previously (nothing or the old file). In this case with the control files we are also doing atomic moves (as long as tar does the fsync dance) the new file gets renamed on top of the new one, so there should not be a time where the file is not there. I cannot see how this is a problem with dpkg, given that there does not seem to be any crash involved in this bug report. About doing fsyncs on directories, that's something I've been considering to fix once I do another overall review of the current atomic write and rename usage. For the particular control files case doing it once just before we mark the package with eflag_ok should make it pretty safe against crashes ending up with an inconsistent db. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
