1 files changed, 0 insertions, 37 deletions
diff --git a/dev-libs/glib/files/glib-2.36.3-revert-ext34.patch b/dev-libs/glib/files/glib-2.36.3-revert-ext34.patch
deleted file mode 100644
index 041419791273..000000000000
--- a/dev-libs/glib/files/glib-2.36.3-revert-ext34.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-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