Blame SOURCES/0001-Revert-g_file_set_contents-don-t-fsync-on-ext3-4.patch

1a3b48
From 4829e02c09c9faa5a312bac04bbaaccb82fa7981 Mon Sep 17 00:00:00 2001
1a3b48
From: Colin Walters <walters@verbum.org>
1a3b48
Date: Thu, 20 Jun 2013 13:13:29 -0400
1a3b48
Subject: [PATCH] Revert "g_file_set_contents(): don't fsync on ext3/4"
1a3b48
1a3b48
We didn't actually do any real-world testing of this, and
1a3b48
unsurprisingly it turns out to break in at least one widely-used
1a3b48
configuration (Fedora 19 x86_64, ext4 on LVM).
1a3b48
1a3b48
This reverts commit 9d0c17b50102267a5029b58b1f44efbad82d8f03.
1a3b48
1a3b48
https://bugzilla.gnome.org/show_bug.cgi?id=701560
1a3b48
---
1a3b48
 glib/gfileutils.c |    9 +--------
1a3b48
 1 files changed, 1 insertions(+), 8 deletions(-)
1a3b48
1a3b48
diff --git a/glib/gfileutils.c b/glib/gfileutils.c
1a3b48
index 05a46ee..7e5bedc 100644
1a3b48
--- a/glib/gfileutils.c
1a3b48
+++ b/glib/gfileutils.c
1a3b48
@@ -1088,16 +1088,9 @@ write_to_temp_file (const gchar  *contents,
1a3b48
     /* On Linux, on btrfs, skip the fsync since rename-over-existing is
1a3b48
      * guaranteed to be atomic and this is the only case in which we
1a3b48
      * would fsync() anyway.
1a3b48
-     *
1a3b48
-     * ext3 and ext4 are also safe in this respect under the default
1a3b48
-     * mount options (and if someone picks non-default options to
1a3b48
-     * improve their performance at the cost of reliability, who are we
1a3b48
-     * to argue?)
1a3b48
-     *
1a3b48
-     * Note: EXT[234]_SUPER_MAGIC are equal.
1a3b48
      */
1a3b48
 
1a3b48
-    if (fstatfs (fd, &buf) == 0 && (buf.f_type == BTRFS_SUPER_MAGIC || buf.f_type == EXT3_SUPER_MAGIC))
1a3b48
+    if (fstatfs (fd, &buf) == 0 && buf.f_type == BTRFS_SUPER_MAGIC)
1a3b48
       goto no_fsync;
1a3b48
   }
1a3b48
 #endif
1a3b48
-- 
1a3b48
1.7.1
1a3b48