[glib/glib-2-36] Revert "g_file_set_contents(): don't fsync on ext3/4"

[Colin Walters <walters src gnome org>]

commit 05d430065da918051a97e3384c4b2252af47503d
Author: Colin Walters <walters verbum org>
Date:   Thu Jun 20 13:13:29 2013 -0400

    Revert "g_file_set_contents(): don't fsync on ext3/4"
    
    We didn't actually do any real-world testing of this, and
    unsurprisingly it turns out to break in at least one widely-used
    configuration (Fedora 19 x86_64, ext4 on LVM).
    
    This reverts commit 9d0c17b50102267a5029b58b1f44efbad82d8f03.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=701560

 glib/gfileutils.c |    9 +--------
 1 files changed, 1 insertions(+), 8 deletions(-)
---
diff --git a/glib/gfileutils.c b/glib/gfileutils.c
index b6ca3bb..2980098 100644
--- a/glib/gfileutils.c
+++ b/glib/gfileutils.c
@@ -1088,16 +1088,9 @@ write_to_temp_file (const gchar  *contents,
     /* On Linux, on btrfs, skip the fsync since rename-over-existing is
      * guaranteed to be atomic and this is the only case in which we
      * would fsync() anyway.
-     *
-     * ext3 and ext4 are also safe in this respect under the default
-     * mount options (and if someone picks non-default options to
-     * improve their performance at the cost of reliability, who are we
-     * to argue?)
-     *
-     * Note: EXT[234]_SUPER_MAGIC are equal.
      */
 
-    if (fstatfs (fd, &buf) == 0 && (buf.f_type == BTRFS_SUPER_MAGIC || buf.f_type == EXT3_SUPER_MAGIC))
+    if (fstatfs (fd, &buf) == 0 && buf.f_type == BTRFS_SUPER_MAGIC)
       goto no_fsync;
   }
 #endif