From 05d430065da918051a97e3384c4b2252af47503d 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 file changed, 1 insertion(+), 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 -- 2.7.4