blob: 0414197912733ed29ec8710272bb3a36efa5a9e9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
From 05d430065da918051a97e3384c4b2252af47503d Mon Sep 17 00:00:00 2001
From: Colin Walters <walters@verbum.org>
Date: Thu, 20 Jun 2013 17:13:29 +0000
Subject: 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
---
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
--
cgit v0.9.2
|
