GNOME Bugzilla – Bug 772765
No "Extract..." menu item for RAR files
Last modified: 2017-03-02 14:30:41 UTC
nautilus-3.22.0-1.fc25.x86_64 file-roller-3.22.0-1.fc25.x86_64 When right-clicking on a zip file, I get the option to "Extract here" or "Extract to..." provided by nautilus. But, as libarchive doesn't support rar files well, nautilus doesn't handle those files. File-roller doesn't add its own menu items for RAR files, meaning that some archive types can't be extracted without opening a separate application.
In https://bugzilla.gnome.org/show_bug.cgi?id=770248 instead of restricting the mime-types it handled, we just removed it. As file-roller supports more archive types than nautilus, we end up with a bunch of archive types without any menu items.
Would it make sense to add back the file roller nautilus extension until nautilus gets support for all the file types that file-roller currently supports?
I think that 1) bringing back the extension 2) removing its support for mime-types that nautilus supports internally, would make the most sense.
that sounds like the best approach, yes
In this case this is actually an autoar bug that the mimetype is not correct... rar files are usually supported, so restoring the file roller extension might be not necessary yet. I'm taking a look now on the autoar side.
(In reply to Carlos Soriano from comment #5) > In this case this is actually an autoar bug that the mimetype is not > correct... rar files are usually supported, so restoring the file roller > extension might be not necessary yet. I'm taking a look now on the autoar > side. gnome-autoar uses libarchive, and libarchive doesn't support a lot of RAR files (that's also the reason why evince uses "unrar" instead of libarchive to read cbr files): https://github.com/libarchive/libarchive/issues/373
Hey Bastien, Yeah I'm aware, but it improved quite a bit. Try yourself the file posted as example in that bug report (and other files), it works here. If you want to try in nautilus, add "application/vnd.rar", to https://git.gnome.org/browse/gnome-autoar/tree/gnome-autoar/autoar-mime-types.c#n26
the mime type missing is what I'm looking now, trying to guess from where this "application/vnd.rar" comes from.
(In reply to Carlos Soriano from comment #7) > Hey Bastien, > > Yeah I'm aware, but it improved quite a bit. Try yourself the file posted as > example in that bug report (and other files), it works here. I'll test, thanks. > If you want to try in nautilus, add > "application/vnd.rar", > to > https://git.gnome.org/browse/gnome-autoar/tree/gnome-autoar/autoar-mime- > types.c#n26 From shared-mime-info, that's the correct mime-type for RAR files: 3385 <mime-type type="application/vnd.rar">• 3386 <_comment>RAR archive</_comment>•
*** This bug has been marked as a duplicate of bug 779431 ***
The rar5 files seems to not be actually supported, so reopening and we will probably do what you proposed, restore the extension and drop rar support on autoar for now.
Created attachment 347009 [details] [review] Revert "Remove nautilus extension" This reverts commit da09ee41ca7c9b63082cf2a35ae19701c34adca7. Some of the main comopressed archives are not still supported by libarchive. Specifically, rar5. This is a major issue for the Nautilus builtin compression handling, so for now and until libarchive adds support for rar5 let's enable the nautilus extension of file roller for the "Extract here" menu item. See https://github.com/libarchive/libarchive/issues/373 for libarchive support of rar5.
Created attachment 347010 [details] [review] nautilus-fileroller: remove supported mime types by nautilus Nautilus has support for some of the mime types that we were using with the extension. Drop those so nautilus can use the built-int support of those, since they provide a better user experience.
since file-roller didn't see any release for this cycle, I would like to put this in and make a 3.23.91 release. What do you think?
Review of attachment 347009 [details] [review]: > Some of the main comopressed archives are not still supported by "compressed" . And "archive formats", not "archives". > libarchive. Specifically, rar5. "libarchive, for example, RAR5. > for now and until libarchive adds support for rar5 let's enable the for now, and until libarchive adds support for RAR5, let's enable the > nautilus extension of file roller for the "Extract here" menu item. file-roller. > support of rar5. RAR5. If the rest of the commit is a straight revert, then please, feel free to push this. Marking as after freeze so you don't forget to tell i18n :)
Review of attachment 347010 [details] [review]: > remove supported mime types by nautilus remove mime-types already supported by nautilus Loads of typos in the rest of the commit message, how about: " Remove support for the mime-types already handled by nautilus' built-in support, as nautilus provides a more integrated user experience. This also avoids having 2 separate "Extract here" menu items in nautilus. " If you have a one-liner script, or something else to "automate" this, can you please post it in the bug as well?
Created attachment 347068 [details] [review] Revert "Remove nautilus extension" This reverts commit da09ee41ca7c9b63082cf2a35ae19701c34adca7. Some of the main compressed archive formats are not still supported by libarchive, for example, RAR5. This is a major issue for the Nautilus builtin compression handling, so for now, and until libarchive adds support for RAR5, let's enable the nautilus extension of file-roller for the "Extract here" menu item. See https://github.com/libarchive/libarchive/issues/373 for libarchive support of RAR5.
Created attachment 347069 [details] [review] nautilus-fileroller: remove mime-types already supported by nautilus Remove support for the mime-types already handled by Nautilus' built-in support, as nautilus provides a more integrated user experience. This also avoids having 2 separate "Extract here" menu items in Nautilus.
Review of attachment 347068 [details] [review]: Looks good.
Review of attachment 347069 [details] [review]: ++
git bz is failing: Pushed as https://git.gnome.org/browse/file-roller/commit/?id=366a5147bd097a877d85295a36fb062213355a36 and https://git.gnome.org/browse/file-roller/commit/?id=aab1b7335c40b8b0e3d5a00cf8305dc53d48f3c8 with the changes mentioned, thanks for the review! I'll make a release of file roller with this in. No, I don't have a script for that, I updated manually. File roller should use g_content_type_is_a() function as I recently implemented in https://bugzilla.gnome.org/show_bug.cgi?id=779431 for autoar to be able to have a script that matches both lists correctly.