Blame SOURCES/unattended-file-More-reliable-test-for-raw-images.patch

8f6169
From 9a93e4b1adb38224ab62fc046112f2b9f56b05be Mon Sep 17 00:00:00 2001
8f6169
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
8f6169
Date: Fri, 17 Jul 2015 16:32:09 +0100
8f6169
Subject: [PATCH] unattended-file: More reliable test for raw images
8f6169
8f6169
The issue with checking if content type is
8f6169
"application/x-raw-disk-image", is that it fails on systems with slighly
8f6169
older shared-mime-info where the content_type is detected as
8f6169
"application-octetstream".
8f6169
---
8f6169
 src/unattended-file.vala | 9 +++++++--
8f6169
 1 file changed, 7 insertions(+), 2 deletions(-)
8f6169
8f6169
diff --git a/src/unattended-file.vala b/src/unattended-file.vala
8f6169
index 02aa92e..fbc8b76 100644
8f6169
--- a/src/unattended-file.vala
8f6169
+++ b/src/unattended-file.vala
8f6169
@@ -66,8 +66,13 @@ private async void copy_with_mcopy (string       disk_file,
8f6169
     private static bool is_libarchive_compatible (string filename) {
8f6169
         // FIXME: We need better way to determine libarchive compatibility cause mcopy is used
8f6169
         //        if this function returns false and mcopy can only handle MS-DOS images while
8f6169
-        //        libarchive can handle other types of disk images
8f6169
-        return GLib.ContentType.guess (filename, null, null) != "application/x-raw-disk-image";
8f6169
+        //        libarchive can handle other types of disk images.
8f6169
+        //
8f6169
+        //        Just in case you get the idea to compare the content_type to
8f6169
+        //        "application/x-raw-disk-image", that's what we were doing but then it failed
8f6169
+        //        on systems with slighly older shared-mime-info where the content_type is
8f6169
+        //        detected as 'application-octetstream'.
8f6169
+        return !filename.has_suffix (".img") && !filename.has_suffix (".IMG");
8f6169
     }
8f6169
 }
8f6169
 
8f6169
-- 
8f6169
2.4.3
8f6169