Bug 79023 - wish: support for Web Archives (.war)
Summary: wish: support for Web Archives (.war)
Status: RESOLVED FIXED
Alias: None
Product: ark
Classification: Applications
Component: plugins (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Ragnar Thomsen
URL:
Keywords:
: 90743 (view as bug list)
Depends on:
Blocks: 192630
  Show dependency treegraph
 
Reported: 2004-04-04 03:38 UTC by David P James
Modified: 2016-05-07 09:12 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 15.12.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David P James 2004-04-04 03:38:34 UTC
Version:           v2.1.9 (using KDE 3.2.1,  (testing/unstable))
Compiler:          gcc version 3.3.3 (Debian)
OS:          Linux (i686) release 2.4.20-686

The konq-plugins package includes a tool to create Web Archives of websites (under the Tools menu). This gets saved in a .war (x-webarchive) but is in fact a gzipped tar archive containing all of the elements of the page being saved (eg, the background image, all images and linked .css files with the page itself saved as index.html). At any rate, Konqueror can view the contents of these files but Ark can't recognize them as is. By renaming .war to .tar.gz Ark has no problems so it shouldn't be difficult to support them as .war without the select archive type dialog showing up.

I didn't want to remove the x-webarchive mime type and reassociate .war with x-tgz since Konqueror probably wouldn't open it by default.

I suspect a fix similar to that used for .debs (bug 47415) would be sufficient.

Thanks
Comment 1 Henrique Pinto 2004-04-04 15:46:08 UTC
CVS commit by pinto: 


Improving archive-type detection.

CCMAIL: 79023-done@bugs.kde.org
CCMAIL: 78740-done@bugs.kde.org


  M +14 -3     archiveformatinfo.cpp   1.7.4.1


--- kdeutils/ark/archiveformatinfo.cpp  #1.7:1.7.4.1
@@ -52,4 +52,5 @@ void ArchiveFormatInfo::buildFormatInfos
   addFormatInfo( TAR_FORMAT, "application/x-tarz", ".tar.z" );
   addFormatInfo( TAR_FORMAT, "application/x-tbz", ".tar.bz2" );
+  addFormatInfo( TAR_FORMAT, "application/x-webarchive", ".war" );
   // x-tar as the last one to get its comment for all the others, too
   addFormatInfo( TAR_FORMAT, "application/x-tar", ".tar" );
@@ -59,4 +60,8 @@ void ArchiveFormatInfo::buildFormatInfos
   addFormatInfo( ZIP_FORMAT, "application/x-jar", ".jar" );
   addFormatInfo( ZIP_FORMAT, "application/x-zip", ".zip" );
+  addFormatInfo( ZIP_FORMAT, "application/vnd.sun.xml.calc", ".sxc" );
+  addFormatInfo( ZIP_FORMAT, "application/vnd.sun.xml.draw", ".sxd" );
+  addFormatInfo( ZIP_FORMAT, "application/vnd.sun.xml.impress", ".sxi" );
+  addFormatInfo( ZIP_FORMAT, "application/vnd.sun.xml.writer", ".sxw" );
 
 
@@ -175,8 +180,14 @@ ArchType ArchiveFormatInfo::archTypeForU
         return UNKNOWN_FORMAT;
 
-    if( !QFile::exists( url.path() ) )
-        return archTypeByExtension( url.path() );
+    //if( !QFile::exists( url.path() ) )
+    //    return archTypeByExtension( url.path() );
+
+    QString mimeType;
+    
+    if ( url.isLocalFile() && QFile::exists( url.path() ) )
+        mimeType = KMimeType::findByFileContent( url.path() )->name();
+    else
+        mimeType = KMimeType::findByURL( url, 0, true, true )->name();
 
-    QString mimeType = KMimeType::findByURL( url, 0, true, true )->name();
     kdDebug( 1601 ) << "find by url: " << mimeType << endl;
     if( mimeType == KMimeType::defaultMimeType() )


Comment 2 David P James 2007-01-16 02:08:31 UTC
This seems to have regressed using Ark 2.6.4 (KDE 3.5.5) on Debian. .war is no longer associated with Ark and Ark will not open them without prompting for an archive type.

To make matters worse, Konqueror no longer opens .war either, which is really curious.
Comment 3 Thomas Damgaard 2008-06-28 14:23:13 UTC
This seems to be a duplicate of this bug: http://bugs.kde.org/show_bug.cgi?id=90743.
Comment 4 Bram Schoenmakers 2008-06-28 16:15:40 UTC
*** Bug 90743 has been marked as a duplicate of this bug. ***
Comment 5 Bram Schoenmakers 2008-06-28 16:17:05 UTC
Please note that, according to bug 90743, Ark got better support sometime ago for detecting *.war archives, although this support has been disappeared somehow.
Comment 6 Raphael Kubo da Costa 2010-12-08 02:14:25 UTC
Changing the default assignee for currently open Ark bug reports to me.
Comment 7 Ragnar Thomsen 2016-05-06 21:02:50 UTC
Konqueror is no longer relevant. Ark now detects mimetype by content so it should be able to open *.war archives (which are renamed Zip files). Closing as invalid...
Comment 8 David P James 2016-05-07 09:03:08 UTC
Sorry, how is this "INVALID"? It was an actual, real, verifiable bug at the time it was filed. It was subsequently confirmed as a bug. For something to be "invalid" it has to have never been a valid issue to begin with.

Somewhere along the way Ark was changed as per your own words: "Ark now detects mimetype by content so it should be able to open *.war archives (which are renamed Zip files)". The key word there is "now". It didn't used to do that. So in other words, Ark was fixed.

This bug is FIXED, not INVALID.
Comment 9 Elvis Angelaccio 2016-05-07 09:11:28 UTC
(In reply to David P James from comment #8)
> Sorry, how is this "INVALID"? It was an actual, real, verifiable bug at the
> time it was filed. It was subsequently confirmed as a bug. For something to
> be "invalid" it has to have never been a valid issue to begin with.
> 
> Somewhere along the way Ark was changed as per your own words: "Ark now
> detects mimetype by content so it should be able to open *.war archives
> (which are renamed Zip files)". The key word there is "now". It didn't used
> to do that. So in other words, Ark was fixed.
> 
> This bug is FIXED, not INVALID.

Correct, this bug has been fixed since Ark 15.12. But didn't let us mark this as FIXED because there was a dependency on #44431.

I'm dropping this dependency, it doesn't make sense for us.
Comment 10 Elvis Angelaccio 2016-05-07 09:12:44 UTC
(In reply to Elvis Angelaccio from comment #9)
> But didn't let us mark
> this as FIXED because there was a dependency on #44431.

* But bugzilla didn't let us...