.tar.lzma not associated with file-roller

[Jonáš Svatoš]

File roller now has an option to create lzma archives with .tar.lzma extension, however, the resulting file is not associated for opening with file-roller.
It can be opened by manualy selecting file-roller, though.

Bug was observed on Hardy post-RC
file-roller 2.22.2-0ubuntu1

[Frédéric Crozat (fcrozat)]

Created an attachment (id=12569)
add .lzma support

[Bastien Nocera (hadess-deactivatedaccount)]

It's missing the acronym bits.

[Frédéric Crozat (fcrozat)]

Created an attachment (id=12570)
new version, with acronym

[Michael Monreal (mimox)]

This patch would be very helpful to have upstream, as file-roller now supports lzma compressed files, but they are not usable from nautilus because they are detected as application/octet-stream

[Bastien Nocera (hadess-deactivatedaccount)]

2008-01-07 Bastien Nocera <email address hidden>

        * freedesktop.org.xml.in: Patch from Frederic Crozat
        <email address hidden> to add LZMA archives (Closes: #13256)

[Jonáš Svatoš (lsde)]

File roller now has an option to create lzma archives with .tar.lzma extension, however, the resulting file is not associated for opening with file-roller.
It can be opened by manualy selecting file-roller, though.

Bug was observed on Hardy post-RC
file-roller 2.22.2-0ubuntu1

[Andrew Starr-Bochicchio (andrewsomething)]

I can confirm this with version 2.22.2-0ubuntu1 on Hardy.

debian/file-roller.mime contains these lines, so it's atleast trying to register the MIME type:

application/x-lzma; /usr/bin/file-roller '%s'; test=test -n "$DISPLAY" -a -e /usr/bin/lzma ; priority=5
application/x-lzma-compressed-tar; /usr/bin/file-roller '%s'; test=test -n "$DISPLAY" -a -e /usr/bin/lzma ; priority=5

[Andrés Rassol (anra)]

I also confirm this bug.

[Alec Faithfull (alec-faithfull)]

The problem seems to be that the MIME types application/x-lzma and application/x-lzma-compressed-tar aren't actually in the shared MIME database; copying the attached file into /usr/local/share/mime/packages and running "sudo update-mime-database /usr/local/share/mime" adds them, so the archives can at least be opened. (The upstream freedesktop.org package has included these MIME types since version 0.30, but the package in Hardy is only on version 0.23.)

Other integration details don't work properly (the files don't have an archive icon or an "Extract here..." context menu item in Nautilus), but that's probably a separate bug...

[Sebastien Bacher (seb128)]

the issue is fixed in intrepid now

[Michael Terry (mterry)]

I'm attaching an SRU minimal debdiff against hardy. This is a safe patch, applied upstream.

This bug is annoying for users because they can right click a file/folder in Nautilus, create an archive of it, and not be able to open the archive because the system doesn't know the mime type of the just-created file!

As noted above, this has been fixed upstream since 0.30 and is fixed in Intrepid by virtue of using newer versions.

[Martin Pitt (pitti)]

This doesn't fall under the SRU criteria (https://wiki.ubuntu.com/StableReleaseUpdates). Is this a regression from a previous release?

[Michael Terry (mterry)]

No, not a regression, I believe. And the effect to the user is not critical (no data loss or anything).

The criteria I considered this bug hitting was "Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)." Which is a pretty wide category of fixes.

But upon reflection, shared-mime-info is likely such a 'critical infrastructure package.'