Debian Bug report logs - #567089
Intercept ENOEXEC on empty/broken configuration scripts to mark package as half-installed

version graph

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg.

Reported by: Raphaël Hertzog <hertzog@debian.org>

Date: Wed, 27 Jan 2010 08:18:02 UTC

Severity: normal

Tags: patch

Merged with 430958

Found in versions dpkg/1.13.25, dpkg/1.15.5.6

Fixed in version dpkg/1.15.6

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Wed, 27 Jan 2010 08:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <raphael@ouaza.com>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 27 Jan 2010 08:18:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <raphael@ouaza.com>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
Cc: Chow Loong Jin <hyperair@ubuntu.com>, Ubuntu Bugsquad <ubuntu-bugsquad@lists.ubuntu.com>, ubuntu-devel@lists.ubuntu.com, debian-dpkg@lists.debian.org
Subject: Re: [LONG] Re: "Exec format error" bugs
Date: Wed, 27 Jan 2010 09:15:52 +0100
Package: dpkg
Version: 1.15.5.6
Severity: important

[ For debian-dpkg, see
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/512096 for a
description of the problem, basically a configuration script is empty
/broken due to data loss and the recovery needs manual intervention ]

Le mardi 26 janvier 2010, Jean-Baptiste Lallement a écrit :
> What could be done ? Some suggestions:
>  - package manager : try to unpack the archive again in order to
> overwrite the faulty files, if it's not found fetch then unpack the
> archive, and try performing the requested operation again. If that
> fails, then really cancel the installation. But the package manager
> need to know it's an "exec format error" and that's not easy due to
> the comments above. Another option could be to ask to the user if he
> wants to try the workaround.
>  - dpkg : add a 'force' option to 'vanish' the package if the removal
> script fails during a removal and/or configuration purging ( with a
> BIG RED warning that it can seriously damage the user's installation)
> instead of running abort-remove or leaving the package half-installed.
> But I don't know the dpkg internals to know if it's a valid option.

I would suggest that dpkg detects the error and brings back the
package state to half-installed forcing the package manager to
unpack it again.

It seems to me that the error code ENOEXEC is sufficiently specific (and it
could be associated to a check of the file length if needed) for this to
be reasonable.

BTW, I think it would have been wise to include the upstream dpkg
maintainers in the discussion from the start, you're lucky that I'm
following ubuntu-devel...

We would also be glad if some people could volunteer to triage dpkg bugs
on launchpad and make sure we have everything filed in the Debian BTS.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com

Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com




Changed Bug submitter to 'Raphaël Hertzog <hertzog@debian.org>' from 'Raphael Hertzog <raphael@ouaza.com>' Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Wed, 27 Jan 2010 08:30:02 GMT) Full text and rfc822 format available.

Changed Bug title to 'Intercept ENOEXEC on empty/broken configuration scripts to mark package as half-installed' from '[LONG] Re: "Exec format error" bugs' Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Wed, 27 Jan 2010 08:33:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Tue, 09 Feb 2010 06:57:03 GMT) Full text and rfc822 format available.

Message #12 received at 567089@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, Chow Loong Jin <hyperair@ubuntu.com>, Ubuntu Bugsquad <ubuntu-bugsquad@lists.ubuntu.com>, ubuntu-devel@lists.ubuntu.com, debian-dpkg@lists.debian.org
Subject: Re: [LONG] Re: "Exec format error" bugs
Date: Mon, 8 Feb 2010 05:09:10 +0100
Hi!

On Wed, 2010-01-27 at 09:15:52 +0100, Raphael Hertzog wrote:
> Package: dpkg
> Version: 1.15.5.6
> Severity: important

> [ For debian-dpkg, see
> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/512096 for a
> description of the problem, basically a configuration script is empty
> /broken due to data loss and the recovery needs manual intervention ]

Ugh, that page is scary, there's a ton of duplicate bugs.

> I would suggest that dpkg detects the error and brings back the
> package state to half-installed forcing the package manager to
> unpack it again.
> 
> It seems to me that the error code ENOEXEC is sufficiently specific (and it
> could be associated to a check of the file length if needed) for this to
> be reasonable.

I'd rather fix the problem that's causing those files to be 0 length.
That should generally never happen, I'm assuming they might just need an
fsync on the directory, which we are not doing at all in general, there
might be some fsyncs on files missing too. What's the difference in
Ubuntu that causes all these reporters to suffer such error, I had never
seen that one before, and it's not been reported in our BTS either. Are
all those reporters using ext4 or ubifs? Anything else different from
Debian you might be aware of?

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Tue, 09 Feb 2010 06:57:05 GMT) Full text and rfc822 format available.

Message #15 received at 567089@bugs.debian.org (full text, mbox):

From: Robert Collins <robertc@robertcollins.net>
To: Guillem Jover <guillem@debian.org>
Cc: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, Chow Loong Jin <hyperair@ubuntu.com>, Ubuntu Bugsquad <ubuntu-bugsquad@lists.ubuntu.com>, ubuntu-devel@lists.ubuntu.com, debian-dpkg@lists.debian.org
Subject: Re: [LONG] Re: "Exec format error" bugs
Date: Mon, 08 Feb 2010 17:49:26 +1100
[Message part 1 (text/plain, inline)]
On Mon, 2010-02-08 at 05:09 +0100, Guillem Jover wrote:

> I'd rather fix the problem that's causing those files to be 0 length.
> That should generally never happen, I'm assuming they might just need an
> fsync on the directory, which we are not doing at all in general, there
> might be some fsyncs on files missing too. What's the difference in
> Ubuntu that causes all these reporters to suffer such error, I had never
> seen that one before, and it's not been reported in our BTS either. Are
> all those reporters using ext4 or ubifs? Anything else different from
> Debian you might be aware of?

ext4 is the default filesystem in Ubuntu.

-Rob
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Tue, 09 Feb 2010 06:57:06 GMT) Full text and rfc822 format available.

Message #18 received at 567089@bugs.debian.org (full text, mbox):

From: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
To: Benjamin Root <ben.v.root@gmail.com>
Cc: Robert Collins <robertc@robertcollins.net>, debian-dpkg@lists.debian.org, Guillem Jover <guillem@debian.org>, Chow Loong Jin <hyperair@ubuntu.com>, ubuntu-devel@lists.ubuntu.com, Ubuntu Bugsquad <ubuntu-bugsquad@lists.ubuntu.com>
Subject: Re: [LONG] Re: "Exec format error" bugs
Date: Tue, 9 Feb 2010 00:15:18 +0100
2010/2/8 Benjamin Root <ben.v.root@gmail.com>:
> ext4 is default only if you are doing a fresh install.  If you are upgrading
> from Jaunty, you will still have ext3, I believe.
>
>From duplicates the problem appeared in 9.04 with slightly more
reports in 9.10. Only 4 reports are filed against an earlier release.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Tue, 09 Feb 2010 06:57:08 GMT) Full text and rfc822 format available.

Message #21 received at 567089@bugs.debian.org (full text, mbox):

From: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, Chow Loong Jin <hyperair@ubuntu.com>, Ubuntu Bugsquad <ubuntu-bugsquad@lists.ubuntu.com>, ubuntu-devel@lists.ubuntu.com, debian-dpkg@lists.debian.org
Subject: Re: [LONG] Re: "Exec format error" bugs
Date: Tue, 9 Feb 2010 01:11:49 +0100
2010/2/8 Guillem Jover <guillem@debian.org>:
> I'd rather fix the problem that's causing those files to be 0 length.
> That should generally never happen, I'm assuming they might just need an
> fsync on the directory, which we are not doing at all in general, there
> might be some fsyncs on files missing too. What's the difference in
> Ubuntu that causes all these reporters to suffer such error, I had never
> seen that one before, and it's not been reported in our BTS either. Are
> all those reporters using ext4 or ubifs? Anything else different from
> Debian you might be aware of?
>

This is a problem with ext4 and some missing fsync.
I'm able to reproduce it on a VM with an ext4 fs and the following test:

# apt-get install hello; sleep 20; echo b > /proc/sysrq-trigger
[simulates a system crash]
After reboot both installation and removal scripts are 0 bytes. You
will notice that hello.list was correctly written to disk.
$ ls -l /var/lib/dpkg/info/hello.*
-rw-r--r-- 1 root root 323 2010-02-09 00:42 /var/lib/dpkg/info/hello.list
-rwxr-xr-x 1 root root   0 2009-08-15 19:17 /var/lib/dpkg/info/hello.postinst
-rwxr-xr-x 1 root root   0 2009-08-15 19:17 /var/lib/dpkg/info/hello.prerm

If you replay the test but adding a sync before the system crash:
# apt-get install hello; sync;  echo b > /proc/sysrq-trigger
After reboot the files are fine:
$ ls -l  /var/lib/dpkg/info/hello.*
-rw-r--r-- 1 root root 323 2010-02-09 00:46 /var/lib/dpkg/info/hello.list
-rwxr-xr-x 1 root root 103 2009-08-15 19:17 /var/lib/dpkg/info/hello.postinst
-rwxr-xr-x 1 root root  74 2009-08-15 19:17 /var/lib/dpkg/info/hello.prerm

If I adjust /proc/sys/vm/dirty_expire_centisecs to be below the sleep
time, ( for exemple 1000 in the test above ) then data are correctly
written to disk.

So, some fsyncs should fix it.

--
Sincerely,

- JB


-- 
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Tue, 09 Feb 2010 06:57:10 GMT) Full text and rfc822 format available.

Message #24 received at 567089@bugs.debian.org (full text, mbox):

From: Benjamin Root <ben.v.root@gmail.com>
To: Robert Collins <robertc@robertcollins.net>
Cc: Guillem Jover <guillem@debian.org>, ubuntu-devel@lists.ubuntu.com, debian-dpkg@lists.debian.org, Chow Loong Jin <hyperair@ubuntu.com>, Ubuntu Bugsquad <ubuntu-bugsquad@lists.ubuntu.com>
Subject: Re: [LONG] Re: "Exec format error" bugs
Date: Mon, 8 Feb 2010 09:50:12 -0600
[Message part 1 (text/plain, inline)]
ext4 is default only if you are doing a fresh install.  If you are upgrading
from Jaunty, you will still have ext3, I believe.

WeatherGod

On Mon, Feb 8, 2010 at 12:49 AM, Robert Collins
<robertc@robertcollins.net>wrote:

> On Mon, 2010-02-08 at 05:09 +0100, Guillem Jover wrote:
>
> > I'd rather fix the problem that's causing those files to be 0 length.
> > That should generally never happen, I'm assuming they might just need an
> > fsync on the directory, which we are not doing at all in general, there
> > might be some fsyncs on files missing too. What's the difference in
> > Ubuntu that causes all these reporters to suffer such error, I had never
> > seen that one before, and it's not been reported in our BTS either. Are
> > all those reporters using ext4 or ubifs? Anything else different from
> > Debian you might be aware of?
>
> ext4 is the default filesystem in Ubuntu.
>
> -Rob
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Sun, 14 Feb 2010 12:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 14 Feb 2010 12:30:03 GMT) Full text and rfc822 format available.

Message #29 received at 567089@bugs.debian.org (full text, mbox):

From: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
To: 567089@bugs.debian.org
Subject: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Sun, 14 Feb 2010 13:27:07 +0100
[Message part 1 (text/plain, inline)]
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu lucid ubuntu-patch

Here is a patch which adds some fsync on files and directories to
prevent delayed allocation and the zero-length file problem on ext4
filesystem.

This patch is build against dpkg 1.15.5.6ubuntu1, I'll try to provide a
version for debian soon.

Don't hesitate to comment this patch and I'll update it if needed.

Thanks.
[dpkg_1.15.5.6ubuntu2.debdiff (text/plain, inline)]
diff -Nru dpkg-1.15.5.6ubuntu1/debian/changelog dpkg-1.15.5.6ubuntu2/debian/changelog
--- dpkg-1.15.5.6ubuntu1/debian/changelog	2010-02-14 02:40:26.000000000 +0100
+++ dpkg-1.15.5.6ubuntu2/debian/changelog	2010-02-14 12:56:27.000000000 +0100
@@ -1,3 +1,14 @@
+dpkg (1.15.5.6ubuntu2) lucid; urgency=low
+
+  * Add fsync on files and directories to prevent delayed allocation and the
+    zero-length file problem after a system crash LP: #512096 (Debian #567089) 
+    - dpkg-deb/extract.c: fsync control files
+    - src/archive.c: fsync newly extracted files
+    - lib/dpkg/cleanup.c: fsync directory before closing
+    - lib/dpkg/dump.c: fsync db directory
+
+ -- Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>  Sun, 14 Feb 2010 12:44:38 +0100
+
 dpkg (1.15.5.6ubuntu1) lucid; urgency=low
 
   * Resynchronise with Debian.  Remaining changes:
diff -Nru dpkg-1.15.5.6ubuntu1/dpkg-deb/extract.c dpkg-1.15.5.6ubuntu2/dpkg-deb/extract.c
--- dpkg-1.15.5.6ubuntu1/dpkg-deb/extract.c	2010-02-14 02:40:26.000000000 +0100
+++ dpkg-1.15.5.6ubuntu2/dpkg-deb/extract.c	2010-02-14 12:19:16.000000000 +0100
@@ -36,6 +36,7 @@
 #include <ar.h>
 #include <stdlib.h>
 #include <stdio.h>
+#include <fcntl.h>
 #ifdef WITH_ZLIB
 #include <zlib.h>
 #endif
@@ -337,6 +338,30 @@
       movecontrolfiles(OLDDEBDIR);
     }
   }
+
+  /* fsync extracted files to prevent delayed allocation and the zero-length
+   * file problem */
+  if (taroption && directory) {
+    DIR *dsd;
+    struct dirent *de;
+    int fd;
+
+    dsd= opendir(directory); 
+    if (!dsd) ohshite(_("cannot read directory `%.250s'"),directory);
+    if (chdir(directory)) 
+        ohshite(_("failed to chdir to `%.255s'"), directory);
+
+    while ((de = readdir(dsd)) != NULL){
+      if (strchr(de->d_name,'.'))
+        continue;
+
+      if ((fd = open( de->d_name, O_RDONLY )) != -1) {
+        fsync(fd);
+        close(fd);
+      }
+    }
+    closedir( dsd );
+  }
 }
 
 static void controlextractvextract(int admin,
diff -Nru dpkg-1.15.5.6ubuntu1/lib/dpkg/cleanup.c dpkg-1.15.5.6ubuntu2/lib/dpkg/cleanup.c
--- dpkg-1.15.5.6ubuntu1/lib/dpkg/cleanup.c	2010-02-14 02:40:26.000000000 +0100
+++ dpkg-1.15.5.6ubuntu2/lib/dpkg/cleanup.c	2010-02-14 12:30:21.000000000 +0100
@@ -51,8 +51,10 @@
 {
 	DIR *d = (DIR *)(argv[0]);
 
-	if (d)
+	if (d) {
+		fsync(dirfd(d));
 		closedir(d);
+	}
 }
 
 void
diff -Nru dpkg-1.15.5.6ubuntu1/lib/dpkg/dump.c dpkg-1.15.5.6ubuntu2/lib/dpkg/dump.c
--- dpkg-1.15.5.6ubuntu1/lib/dpkg/dump.c	2010-02-14 02:40:26.000000000 +0100
+++ dpkg-1.15.5.6ubuntu2/lib/dpkg/dump.c	2010-02-14 12:08:08.000000000 +0100
@@ -33,6 +33,7 @@
 #include <unistd.h>
 #include <stdio.h>
 #include <stdlib.h>
+#include <dirent.h>
 
 #include <dpkg/i18n.h>
 #include <dpkg/dpkg.h>
@@ -362,6 +363,8 @@
   FILE *file;
   struct varbuf vb = VARBUF_INIT;
   int old_umask;
+  char *fname, *dname;
+  DIR *dirp;
 
   which= available ? "available" : "status";
   oldfn= m_malloc(strlen(filename)+sizeof(OLDDBEXT));
@@ -409,4 +412,17 @@
             newfn, filename, which);
   free(newfn);
   free(oldfn);
+
+  /* We need to sync the directory */
+  fname = strdup( filename );
+  dname = strrchr( fname, '/' );
+  if ( dname && *dname )
+    *dname = '\0';
+
+  if ( (dirp = opendir(fname))==NULL) 
+    ohshite(_("failed to opendir `%.250s'"), fname );
+  if ( fsync(dirfd(dirp)) == -1 ) 
+    ohshite(_("failed to fsync `%.250s'"), fname );
+  closedir( dirp );
+  free( fname );
 }
diff -Nru dpkg-1.15.5.6ubuntu1/src/archives.c dpkg-1.15.5.6ubuntu2/src/archives.c
--- dpkg-1.15.5.6ubuntu1/src/archives.c	2010-02-14 02:40:27.000000000 +0100
+++ dpkg-1.15.5.6ubuntu2/src/archives.c	2010-02-14 12:14:20.000000000 +0100
@@ -655,6 +655,8 @@
     if (fchmod(fd,am))
       ohshite(_("error setting permissions of `%.255s'"),ti->Name);
     pop_cleanup(ehflag_normaltidy); /* fd= open(fnamenewvb.buf) */
+    if (fsync(fd))
+      ohshite(_("unable to fsync new file `%.250s'"), fnamenewvb.buf );
     if (close(fd))
       ohshite(_("error closing/writing `%.255s'"),ti->Name);
     newtarobject_utime(fnamenewvb.buf,ti);

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Sun, 14 Feb 2010 16:54:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 14 Feb 2010 16:54:08 GMT) Full text and rfc822 format available.

Message #34 received at 567089@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Sun, 14 Feb 2010 17:50:32 +0100
tag 567089 + patch
thanks

Hi,

On Sun, 14 Feb 2010, Jean-Baptiste Lallement wrote:
> Here is a patch which adds some fsync on files and directories to
> prevent delayed allocation and the zero-length file problem on ext4
> filesystem.

Great, thanks for this!

> This patch is build against dpkg 1.15.5.6ubuntu1, I'll try to provide a
> version for debian soon.

Please make it conform the coding style (see doc/coding-style.txt in git
repo), I saw several stylistic problems:
- missing space before comma, operator, or =
- unwanted spaces after ( or before )
- invalid indenting (be consistent with the rest of the file)
- use "" or '' quotes in new strings (and not `')

On question though, is that the minimal set of fsync needed to get the
right result? I fear that we loose lots of performance in particular for
the change in src/archive.c (fsync newly extracted files). Maybe it's best
to not do it at this point but add a generic sync() somewhere when the
database is synced to disk. Not sure though. Also even ext4 implicitely
sync files on rename() IIRC so it's not strictly needed AFAIK.

Can you explain your changes in more details, because I'm not sure I
understand it completely:

> +  * Add fsync on files and directories to prevent delayed allocation and the
> +    zero-length file problem after a system crash LP: #512096 (Debian #567089) 
> +    - dpkg-deb/extract.c: fsync control files

You modify extracthalf() which is used for extracting control files but
also the main files of the package itself (depending on whether admin is
true or not). You call fsync on all files of the directory indicated.

In the case of the control archives (control.tar.gz), it's fine we only
have files at the root directory but in the case of data.tar.gz you
definitely won't fsync all installed files.

This lead me to believe that it's not the proper place for this code.
Instead I think (but I would want Guillem's opinion) that it should
be in process_archive() just after the call to dpkg-deb --control.

And you probably want a separate function to sync all files of a
directory.

> +    - src/archive.c: fsync newly extracted files

See comment in first para.

> +    - lib/dpkg/cleanup.c: fsync directory before closing

I doubt that this is the proper place. What directory needs to be
fsynced() and at what time of the installation/upgrade process ?

Probably only the pop_cleanup() calls in src/processarc.c and not the others
so it really needs to be moved there directly.

> +    - lib/dpkg/dump.c: fsync db directory

This one looks okay.


Code review:

> +    while ((de = readdir(dsd)) != NULL){
> +      if (strchr(de->d_name,'.'))
> +        continue;

Why skipping files containing a dot? Maybe you wanted to skip "." and ".."
but that's not what this code does.

> diff -Nru dpkg-1.15.5.6ubuntu1/lib/dpkg/dump.c dpkg-1.15.5.6ubuntu2/lib/dpkg/dump.c
> --- dpkg-1.15.5.6ubuntu1/lib/dpkg/dump.c	2010-02-14 02:40:26.000000000 +0100
> +++ dpkg-1.15.5.6ubuntu2/lib/dpkg/dump.c	2010-02-14 12:08:08.000000000 +0100
> +  /* We need to sync the directory */
> +  fname = strdup( filename );
> +  dname = strrchr( fname, '/' );
> +  if ( dname && *dname )
> +    *dname = '\0';
> +
> +  if ( (dirp = opendir(fname))==NULL) 
> +    ohshite(_("failed to opendir `%.250s'"), fname );
> +  if ( fsync(dirfd(dirp)) == -1 ) 
> +    ohshite(_("failed to fsync `%.250s'"), fname );
> +  closedir( dirp );
> +  free( fname );

Can't we open the directory directly instead of using opendir + dirfd? Or
is that non-portable (I don't know)?

Cheers,
-- 
Raphaël Hertzog




Added tag(s) patch. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sun, 14 Feb 2010 16:54:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Mon, 15 Feb 2010 01:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 15 Feb 2010 01:33:05 GMT) Full text and rfc822 format available.

Message #41 received at 567089@bugs.debian.org (full text, mbox):

From: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Mon, 15 Feb 2010 02:32:32 +0100
On 02/14/2010 05:50 PM, Raphael Hertzog wrote:
> tag 567089 + patch
> thanks
>
>
> Please make it conform the coding style (see doc/coding-style.txt in git
> repo), I saw several stylistic problems:
> - missing space before comma, operator, or =
> - unwanted spaces after ( or before )
> - invalid indenting (be consistent with the rest of the file)
> - use "" or '' quotes in new strings (and not `')
Thanks for the reference, I'll provide a more stylish patch then.

>
> On question though, is that the minimal set of fsync needed to get the
> right result? I fear that we loose lots of performance in particular for
> the change in src/archive.c (fsync newly extracted files). Maybe it's best
> to not do it at this point but add a generic sync() somewhere when the
> database is synced to disk. Not sure though. Also even ext4 implicitely
> sync files on rename() IIRC so it's not strictly needed AFAIK.
We need to fsync all extracted files, info directory and database
directory. I've made extensive crash tests, and I think this is the
minimal set of fsync to ensure that control files and archive files are
there and renaming is done correctly.

I did some profiling and the perfomance hit is less than 10%. Installing
4 packages/1601 files takes an average of 10.04s over 10 runs with the
current version of dpkg and 10.931s with the `fsync' version (9.27%) (on
a laptop with an ATA 5400rpm hard drive)
Initially, I didn't synced the files extracted from the data area but
they were all 0 bytes in case of crash. The situation would be the
same as today.
Using sync instead of fsync won't make a big difference I guess, sooner
or later we need do pages need to be flushed to disk and it will have an
effect on system's performance. On the other hand, calling fsync on each
file makes operation atomic and prevent data loss if the crash occurs
during the installation.
The call to rename doesn't fsync files nor guarantees which file will be
visible after a crash so we need to call fsync on the directory.

>
> Can you explain your changes in more details, because I'm not sure I
> understand it completely:
>
>> +  * Add fsync on files and directories to prevent delayed allocation
and the
>> +    zero-length file problem after a system crash LP: #512096
(Debian #567089)
>> +    - dpkg-deb/extract.c: fsync control files
>
> You modify extracthalf() which is used for extracting control files but
> also the main files of the package itself (depending on whether admin is
> true or not). You call fsync on all files of the directory indicated.
>
> In the case of the control archives (control.tar.gz), it's fine we only
> have files at the root directory but in the case of data.tar.gz you
> definitely won't fsync all installed files.
>
> This lead me to believe that it's not the proper place for this code.
> Instead I think (but I would want Guillem's opinion) that it should
> be in process_archive() just after the call to dpkg-deb --control.
>
The idea was to fsync the files as soon as they're extracted. That's why
I've put it there instead of inside dpkg's code. In fact the problem is
more with tar than dpkg.

From what I've understood of the behavior of dpkg, when called from
dpkg, the argument `directory' is not null only when we extract the
control files. When dpkg-deb is run directly with the extract or
vextract command we want to fsync files.
I was unsure where to fsync the control file so I will clearly follow
your advice here.

> And you probably want a separate function to sync all files of a
> directory.
>
>> +    - src/archive.c: fsync newly extracted files
>
> See comment in first para.
>
>> +    - lib/dpkg/cleanup.c: fsync directory before closing
>
> I doubt that this is the proper place. What directory needs to be
> fsynced() and at what time of the installation/upgrade process ?
We need to fsync INFODIR after the rename operations to ensure that the
entries in that directory are flushed to disk.

>
> Probably only the pop_cleanup() calls in src/processarc.c and not the
others
> so it really needs to be moved there directly.
OK. just before the last call to "pop_cleanup(ehflag_normaltidy); /*
closedir */" should be fine.

>
>> +    - lib/dpkg/dump.c: fsync db directory
>
> This one looks okay.
>
Great :)

>
> Code review:
>
>> +    while ((de = readdir(dsd)) != NULL){
>> +      if (strchr(de->d_name,'.'))
>> +        continue;
>
> Why skipping files containing a dot? Maybe you wanted to skip "." and ".."
> but that's not what this code does.
>
Right, I will change it.

>> +
>> +  if ( (dirp = opendir(fname))==NULL)
>> +    ohshite(_("failed to opendir `%.250s'"), fname );
>> +  if ( fsync(dirfd(dirp)) == -1 )
>> +    ohshite(_("failed to fsync `%.250s'"), fname );
>> +  closedir( dirp );
>> +  free( fname );
>
> Can't we open the directory directly instead of using opendir + dirfd? Or
> is that non-portable (I don't know)?
>
That's fine. I'll correct that too.

Thanks for reviewing the code. I'll submit a corrected patch for debian
within a week.





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Mon, 15 Feb 2010 08:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 15 Feb 2010 08:45:04 GMT) Full text and rfc822 format available.

Message #46 received at 567089@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
Cc: 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Mon, 15 Feb 2010 09:44:05 +0100
Hi,

On Mon, 15 Feb 2010, Jean-Baptiste Lallement wrote:
> Initially, I didn't synced the files extracted from the data area but
> they were all 0 bytes in case of crash. The situation would be the
> same as today.

I understand that but what matters is that they are not 0 bytes if the
package is marked as "unpacked", they could end up 0 bytes if the package
is marked "half-installed", it would not matter much since the unpack
would have to be redone.

That's why I why suggesting to call sync() when we switch from
half-installed to unpacked instead of calling fsync() individually.

> Using sync instead of fsync won't make a big difference I guess, sooner
> or later we need do pages need to be flushed to disk and it will have an
> effect on system's performance. On the other hand, calling fsync on each
> file makes operation atomic and prevent data loss if the crash occurs
> during the installation.

I understand that.

> The call to rename doesn't fsync files nor guarantees which file will be
> visible after a crash so we need to call fsync on the directory.

I was referring to http://lwn.net/Articles/322823/: "Finally, this patch
forces block allocation when one file is renamed on top of another."

So it's only true if the rename overwrites a file.

But we should not rely on the behaviour of a specific filesystem and we
should rather err on the side of caution, I agree and we should not assume
this.

> > This lead me to believe that it's not the proper place for this code.
> > Instead I think (but I would want Guillem's opinion) that it should
> > be in process_archive() just after the call to dpkg-deb --control.
> >
> The idea was to fsync the files as soon as they're extracted. That's why
> I've put it there instead of inside dpkg's code. In fact the problem is
> more with tar than dpkg.

Indeed.

> From what I've understood of the behavior of dpkg, when called from
> dpkg, the argument `directory' is not null only when we extract the
> control files.

The parameter is always given AFAIK.

> When dpkg-deb is run directly with the extract or vextract command we
> want to fsync files.

Those commands are not used internally by dpkg AFAIK. So it's not so
important as it looks like.

> I was unsure where to fsync the control file so I will clearly follow
> your advice here.

It's my suggestion, but I'm not an expert on the C part of dpkg, if
Guillem says something else, please follow his advice.

> Thanks for reviewing the code. I'll submit a corrected patch for debian
> within a week.

Great!

Cheers,
-- 
Raphaël Hertzog




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Wed, 17 Feb 2010 20:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 17 Feb 2010 20:12:03 GMT) Full text and rfc822 format available.

Message #51 received at 567089@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Wed, 17 Feb 2010 21:09:36 +0100
[Message part 1 (text/plain, inline)]
forcemerge 430958 567089
thanks

Hi!

On Sun, 2010-02-14 at 13:27:07 +0100, Jean-Baptiste Lallement wrote:
> Here is a patch which adds some fsync on files and directories to
> prevent delayed allocation and the zero-length file problem on ext4
> filesystem.

Thanks! As commented on IRC I started to review and consider all code
paths in the source tree that might need fsync()s, it ended up being
easier to cook a patch in-place than just comment on what would need
to be done. Hope I didn't make you waste time by having done much more
work already!

The patch (attached) is completely untested, it builds though :), and
there's still few things to polish, but I think it handles most of the
problematic cases now (except for syncing dirs on removal), it is also
doing too many fsync()s on directories, and I'll probably switch that
to mark them as dirty and only fsync() them then.

I think I'll split it in few pieces, one for the missing fsync()/fflush()
on files, another one for dir fsync()s on db paths, and a last one to
be worked on for fsync()s on the installed directories. This way we get
incremental improvements, also I've not yet checked the impact of the
additional fsync()s, which might be notibable for the installed files.

I've left here some of the comments I initially had anyway.

> diff -Nru dpkg-1.15.5.6ubuntu1/dpkg-deb/extract.c dpkg-1.15.5.6ubuntu2/dpkg-deb/extract.c
> --- dpkg-1.15.5.6ubuntu1/dpkg-deb/extract.c	2010-02-14 02:40:26.000000000 +0100
> +++ dpkg-1.15.5.6ubuntu2/dpkg-deb/extract.c	2010-02-14 12:19:16.000000000 +0100
> @@ -337,6 +338,30 @@
>        movecontrolfiles(OLDDEBDIR);
>      }
>    }
> +
> +  /* fsync extracted files to prevent delayed allocation and the zero-length
> +   * file problem */
> +  if (taroption && directory) {
> +    DIR *dsd;
> +    struct dirent *de;
> +    int fd;
> +
> +    dsd= opendir(directory); 
> +    if (!dsd) ohshite(_("cannot read directory `%.250s'"),directory);
> +    if (chdir(directory)) 
> +        ohshite(_("failed to chdir to `%.255s'"), directory);
> +
> +    while ((de = readdir(dsd)) != NULL){
> +      if (strchr(de->d_name,'.'))
> +        continue;
> +
> +      if ((fd = open( de->d_name, O_RDONLY )) != -1) {
> +        fsync(fd);
> +        close(fd);
> +      }
> +    }
> +    closedir( dsd );
> +  }
>  }

As Raphaël said, this is missleading as it only fsync()s the top
directory. And directory might be set even in other cases than the
--control one. I've done it just after the dpkg-deb invokation in
dpkg.

> diff -Nru dpkg-1.15.5.6ubuntu1/src/archives.c dpkg-1.15.5.6ubuntu2/src/archives.c
> --- dpkg-1.15.5.6ubuntu1/src/archives.c	2010-02-14 02:40:27.000000000 +0100
> +++ dpkg-1.15.5.6ubuntu2/src/archives.c	2010-02-14 12:14:20.000000000 +0100
> @@ -655,6 +655,8 @@
>      if (fchmod(fd,am))
>        ohshite(_("error setting permissions of `%.255s'"),ti->Name);
>      pop_cleanup(ehflag_normaltidy); /* fd= open(fnamenewvb.buf) */
> +    if (fsync(fd))
> +      ohshite(_("unable to fsync new file `%.250s'"), fnamenewvb.buf );

This should go before the pop_cleanup, or an error in fsync would make
it leak the file descriptor.

And this call looks fine here, as we want to guarantee the
foo.dpkg-new has the proper contents, which is important for the
conffile case which only gets processed later on at the --configure
stage.

thanks,
guillem
[0001-Sync-files-and-directories-to-avoid-zero-length-or-d.patch (text/x-diff, attachment)]

Forcibly Merged 430958 567089. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Wed, 17 Feb 2010 20:12:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Fri, 26 Feb 2010 20:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 26 Feb 2010 20:57:07 GMT) Full text and rfc822 format available.

Message #58 received at 567089@bugs.debian.org (full text, mbox):

From: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
To: Guillem Jover <guillem@debian.org>
Cc: 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Fri, 26 Feb 2010 21:55:41 +0100
[Message part 1 (text/plain, inline)]
Hi,

On 02/17/2010 09:09 PM, Guillem Jover wrote:
>
> The patch (attached) is completely untested, it builds though :), and
> there's still few things to polish, but I think it handles most of the
> problematic cases now (except for syncing dirs on removal), it is also
I tested the fsync patch. There is one issue in processarc.c. The call 
to dir_sync_contents fails because at this point 'cidir' is the full 
path of the control file, not the name of the directory containing the 
control file.

Following your work, I added a dir_sync_contents_parent in 
lib/dpkg/dir.{c,h} and replaced the call to dir_sync_contents in 
process_archive. I'm not sure if it's done the way you're expecting, but 
it builds and run fine. The patch is attached.

I tested the following cases: install, upgrade, removal and purge. Then 
ran a sha256sum on the files (archive, control files, and dpkg db) and 
compared to the expected checksum. All the files are correctly synced or 
removed without residual files left behind (some .dpkg-new or status-new)

> doing too many fsync()s on directories, and I'll probably switch that
> to mark them as dirty and only fsync() them then.
I confirm that there are too many syncs on directories. Some directories 
are sync as many times as the number of files it contains. Marking them 
as dirty when the status of the package is set 'unpacked' should fix it. 
You'll find the number of sync/file for bsdgames at 
http://www.pastebin.Com/NdHNWsyQ

>
> I think I'll split it in few pieces, one for the missing fsync()/fflush()
> on files, another one for dir fsync()s on db paths, and a last one to
> be worked on for fsync()s on the installed directories. This way we get
> incremental improvements, also I've not yet checked the impact of the
> additional fsync()s, which might be notibable for the installed files.
>
The major issue seems to be the performance. I tested 
texlive-latex-extra-doc (more than 8000 files) some directories are sync 
around 500 times. I've only tested on a VM up to now, but the 
performance loss is a factor 3. Take this number with caution, it's a VM 
with a virtual disk, not a raw device hence disk access does not means 
much. I'll do some profiling on a real machine this week end.

Don't hesitate to tell me if you need few more tests.

Thanks.

-- 
-JB
[dir_sync_contents_parent.diff (text/x-diff, attachment)]

Added tag(s) pending. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sat, 06 Mar 2010 09:54:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Mon, 08 Mar 2010 14:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 08 Mar 2010 14:51:02 GMT) Full text and rfc822 format available.

Message #65 received at 567089@bugs.debian.org (full text, mbox):

From: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
To: Guillem Jover <guillem@debian.org>
Cc: 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Mon, 08 Mar 2010 15:48:27 +0100
Results from the tests against git rev. 
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=62668eb

Test cases: crash after install/upgrade/removal/purge of a package.
The status file is not synced, the previous version is kept and the 
directory /var/lib/dpkg/ contains the file status-new.
This is due to a missing fsync on the directory.

This is a minor annoyance, since running 'dpkg --configure -a' fix it.

On the performance side, the installation of a package is a factor 2 
slower (1.8 to 2.2 depending on the number of files) than without the 
fsyncs.
Test done with packages from 200 files up to 8200 files with an ATA Disk 
@5400rpm

Thanks for your work, guillem.

--
:JB




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Fri, 12 Mar 2010 03:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 12 Mar 2010 03:27:03 GMT) Full text and rfc822 format available.

Message #70 received at 567089@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, 567089@bugs.debian.org
Subject: Re: Bug#567089: patch proposal to prevent delayed allocation and the zero-length file problem
Date: Fri, 12 Mar 2010 04:24:54 +0100
Hi!

On Fri, 2010-02-26 at 21:55:41 +0100, Jean-Baptiste Lallement wrote:
> I tested the fsync patch. There is one issue in processarc.c. The
> call to dir_sync_contents fails because at this point 'cidir' is the
> full path of the control file, not the name of the directory
> containing the control file.

Nice catch!

> Following your work, I added a dir_sync_contents_parent in
> lib/dpkg/dir.{c,h} and replaced the call to dir_sync_contents in
> process_archive. I'm not sure if it's done the way you're expecting,
> but it builds and run fine. The patch is attached.

Actually there was an easier fix for this, just moving the
dir_sync_contents call before the “strcpy(cidirrest,CONTROLFILE);”
call, whichs is appending the control file name to the directory name.

> I tested the following cases: install, upgrade, removal and purge.
> Then ran a sha256sum on the files (archive, control files, and dpkg
> db) and compared to the expected checksum. All the files are
> correctly synced or removed without residual files left behind (some
> .dpkg-new or status-new)

Ah, perftect.

> On 02/17/2010 09:09 PM, Guillem Jover wrote:
> > doing too many fsync()s on directories, and I'll probably switch that
> > to mark them as dirty and only fsync() them then.

> I confirm that there are too many syncs on directories. Some
> directories are sync as many times as the number of files it
> contains. Marking them as dirty when the status of the package is
> set 'unpacked' should fix it. You'll find the number of sync/file
> for bsdgames at http://www.pastebin.Com/NdHNWsyQ

Yeah, after reviewing the patch one more time, I've seen that too.
I've committed the database dir sync part for now, and have a
preliminary patch for the dir sync on all file system dirty
directories. But that one can still wait a bit.

> > I think I'll split it in few pieces, one for the missing fsync()/fflush()
> > on files, another one for dir fsync()s on db paths, and a last one to
> > be worked on for fsync()s on the installed directories. This way we get
> > incremental improvements, also I've not yet checked the impact of the
> > additional fsync()s, which might be notibable for the installed files.

> The major issue seems to be the performance. I tested
> texlive-latex-extra-doc (more than 8000 files) some directories are
> sync around 500 times. I've only tested on a VM up to now, but the
> performance loss is a factor 3. Take this number with caution, it's
> a VM with a virtual disk, not a raw device hence disk access does
> not means much. I'll do some profiling on a real machine this week
> end.

Right, I think we'd need to test the impact of the fsync on all dirty
directories on the file system before applying it. It might be too
much.

And thanks so much for all the testing!

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#567089; Package dpkg. (Fri, 12 Mar 2010 03:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 12 Mar 2010 03:36:03 GMT) Full text and rfc822 format available.

Message #75 received at 567089@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>, 567089@bugs.debian.org
Subject: Re: [PATCH] Use FIEMAP to sort .list files before scanning
Date: Fri, 12 Mar 2010 04:31:34 +0100
Hi!

On Mon, 2010-03-08 at 15:48:27 +0100, Jean-Baptiste Lallement wrote:
> Results from the tests against git rev.
> http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=62668eb
> 
> Test cases: crash after install/upgrade/removal/purge of a package.
> The status file is not synced, the previous version is kept and the
> directory /var/lib/dpkg/ contains the file status-new.
> This is due to a missing fsync on the directory.
> 
> This is a minor annoyance, since running 'dpkg --configure -a' fix it.

This should be fixed now with the database dir sync patch.

> On the performance side, the installation of a package is a factor 2
> slower (1.8 to 2.2 depending on the number of files) than without
> the fsyncs.
> Test done with packages from 200 files up to 8200 files with an ATA
> Disk @5400rpm

That's a bit sad, but better to behave correctly than the possibility
of data loss or inconsistent installation states. And with the newer
file system types around I'm guessing this kind of problem is going to
be seen more often. We can always try to optimize it later on.

> Thanks for your work, guillem.

Thank you for the continuous testing, much appreciated.

regards,
guillem




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 20 May 2010 07:37:49 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 23:16:41 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.