GNOME Bugzilla – Bug 567235
expose archive backend as application
Last modified: 2018-05-09 14:12:41 UTC
We are shipping a patch in Fedora since gvfs 0.99 days that adds a desktop file for the archive backend. We should probably either get it upstream, or drop it.
Created attachment 126156 [details] [review] patch
Ugh, i forgot this. The desktop file was only an easy fix, we should really make this a part of nautilus so we can get it as a regular menu item instead of an app.
*** Bug 597443 has been marked as a duplicate of this bug. ***
From the dupe bug, the extension is missing support for: *.gz, *.bz2, *.lzma, *.tar.lzma Not sure it makes sense to support archive browsing when the archives only support one file...
support for multi-files archives is sure a priority, but i really would welcome support even for the one-file ones, it makes sense and thanks for your effort on this project ;)
Provided fix in comment #1 is also being used under Gentoo, the problem is that it causes the following behavior: 1. I go to a directory with tarballs using nautilus 2. I click on a tarball and nothing seems to occur -> tarball is being mounted in ~/Desktop, and clicking on it, tarball is opened like a normal folder From my point of view, nautilus should open tarball directly without needing to know that I must go back to ~/Desktop to look for mounted device Thanks a lot :-)
*** Bug 612842 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Provided fix in comment #1 is also being used under Gentoo, the problem is that > it causes the following behavior: > .... --> bug 605965 (In reply to comment #4) > From the dupe bug, the extension is missing support for: *.gz, *.bz2, *.lzma, > *.tar.lzma > > Not sure it makes sense to support archive browsing when the archives only > support one file... Proper support for format-less archive types needs to come in libarchive first.
This is current fedora patch working with 1.16.0: http://pkgs.fedoraproject.org/cgit/gvfs.git/tree/gvfs-archive-integration.patch
I think this should be part of nautilus as per comment 2. Anyone who wants to manually mount an archive can do it with gvfs-mount. I'll also split the part about format-less archive types into a separate (gvfs) bug.
(In reply to comment #9) > This is current fedora patch working with 1.16.0: > http://pkgs.fedoraproject.org/cgit/gvfs.git/tree/gvfs-archive-integration.patch However mentioned patch does not work well currently see: https://bugzilla.redhat.com/show_bug.cgi?id=1001988
(In reply to comment #11) > However mentioned patch does not work well currently see: > https://bugzilla.redhat.com/show_bug.cgi?id=1001988 Not anymore. Commit 7770b63d6726bc7ab4b886d6bd3edd009e622e55 was reverted: https://git.gnome.org/browse/nautilus/commit/?id=9a4ff3ca0d8476e15daa6dd92ac6c0eb8c5b9695
Comment on attachment 126156 [details] [review] patch $:andre\> patch --no-backup-if-mismatch -p0 < aaaapatch patching file mount-archive.desktop.in.in patching file Makefile.am Hunk #1 FAILED at 1. Hunk #2 FAILED at 15. 2 out of 2 hunks FAILED -- saving rejects to file Makefile.am.rej Hence setting 'needs-rework' as patch does not apply cleanly.
Created attachment 357024 [details] [review] Expose archive backend as application Current patch from http://pkgs.fedoraproject.org/rpms/gvfs/blob/master/f/gvfs-archive-integration.patch
Review of attachment 357024 [details] [review]: Thanks for the patch. I am aware of it in downstream, but I am not convinced that this is something what should be directly in gvfs upstream. The desktop file is a helper for file manager and doesn't make any sense standalone. It was just a temporary workaround before it is properly integrated into Nautilus. However, Nautilus introduced its own way of handling archives in the recent releases and it is harder to open it this way due to changes "Open with other application" option. So I am not sure how much sense it makes these days...
@Piotr perhaps the best thing to do would be to propose this approach for dealing with archives on Nautilus bugzilla and link to this ticket?
I don't think that another report is needed, Nautilus developers moved this report here. Carlos, what are plans for Nautilus in terms of handling with archives...?
(In reply to Ondrej Holy from comment #17) > I don't think that another report is needed, Nautilus developers moved this > report here. > > Carlos, what are plans for Nautilus in terms of handling with archives...? Right now I'm giving Nautilus mime type handling support of what gnome-autoar supports and it's going to be in 3.26 if everything goes fine. Does that answer your question?
Not really. Don't you consider the possibility to integrate archive backend as an alternative to direct extracting (configurable in preferences)? Just a note that the archive backend supports same file types as gnome-autoar, because it is also based on libarchive. Using "Archive Mounter" is currently pretty unfriendly, right click -> Open With Other Application -> mark Archive Mounter -> Select -> open archive:// mount from sidebar :-/ It would be so nice if one can click on archive and archive:// mount would be automatically opened. If you don't consider this, I am about closing this as WONTFIX, because I really don't think that adding any desktop file for GVfs is wanted since GVfs is only library/extension for GLib and doesn't contain any other desktop files, neither apps, neither cmd tools nowaday...
I don't think that the archive backend, or its integration in nautilus through the "Archive Mounter" is useful for end-users. It's also not very useful applications as mounts will popup and disappear in user's file managers, without any explanation. This last behaviour is the reason why totem-disc (in totem-pl-parser) started using libarchive itself directly for disc-type detection.
(In reply to Ondrej Holy from comment #19) > Not really. Don't you consider the possibility to integrate archive backend > as an alternative to direct extracting (configurable in preferences)? Just a > note that the archive backend supports same file types as gnome-autoar, > because it is also based on libarchive. Using "Archive Mounter" is currently > pretty unfriendly, right click -> Open With Other Application -> mark > Archive Mounter -> Select -> open archive:// mount from sidebar :-/ It would > be so nice if one can click on archive and archive:// mount would be > automatically opened. If you don't consider this, I am about closing this as > WONTFIX, because I really don't think that adding any desktop file for GVfs > is wanted since GVfs is only library/extension for GLib and doesn't contain > any other desktop files, neither apps, neither cmd tools nowaday... Ah I see... the way we are following is to remove the archive handling ASAP for the user, as in... if we can decompress/compress automatically or not make the user interact with compressed archives, the better. What we don't want is a pseudo file system where half of the features are not possible (thumbnailing, indexing, fts, etc.) due to having your files in an archive. So yeah, I guess you can close as WONTFIX.
(In reply to Carlos Soriano from comment #21) > So yeah, I guess you can close as WONTFIX. (and remove the integration downstream)
I am going to remove the integration downstream, so let's close it here...