luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-25 19:52:10 +01:00
Code Issues Packages Projects Releases Wiki Activity

Revert "g_file_set_contents(): don't fsync on ext3/4"

Browse Source 
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
This commit is contained in:
Colin Walters 2013-06-20 13:13:29 -04:00
parent 69afaf6905
commit 4829e02c09
1 changed files with 1 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
glib/gfileutils.c
View File

@ -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