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

[Matthias Clasen <matthiasc src gnome org>]

commit cf1922965a897cbfb53ac3e88c2a444f880b01d7
Author: Ryan Lortie <desrt desrt ca>
Date:   Tue Jun 4 09:48:12 2013 -0400

    g_file_set_contents(): don't fsync on ext3/4
    
    ext3 and ext4 (for quite some time) with default mount options don't
    need fsync() to ensure safety of replace-by-rename.  Stop doing that for
    these filesystems.
    
    Note: this patch also impacts ext2, which is probably not safe, but I
    don't know of any way to check ext2. vs the others because they all have
    the same magic numbers (short of opening /proc/mount).
    
    This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
    EXT3_SUPER_MAGIC.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=701560

 glib/gfileutils.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/glib/gfileutils.c b/glib/gfileutils.c
index 2980098..b6ca3bb 100644
--- a/glib/gfileutils.c
+++ b/glib/gfileutils.c
@@ -1088,9 +1088,16 @@ 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)
+    if (fstatfs (fd, &buf) == 0 && (buf.f_type == BTRFS_SUPER_MAGIC || buf.f_type == EXT3_SUPER_MAGIC))
       goto no_fsync;
   }
 #endif