From 4829e02c09c9faa5a312bac04bbaaccb82fa7981 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Thu, 20 Jun 2013 13:13:29 -0400 Subject: [PATCH] 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 05a46ee..7e5bedc 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 -- 1.7.1