Expanding Nautilus' functionality as an archive manager

As Nautilus is now (and has been for a while) the default archive manager for the GNOME desktop, I’d like to discuss a specific use case it doesn’t yet cover, which happens to be one it should be well equipped to improve on significantly over file-roller’s own capabilities at this time.

While Nautilus already works well when it comes to extracting the whole archive either in the folder it’s already in or extracting it (again, in full) to another folder, it is at this time incapable of extract select files/folders from an archive separately, which is something I personally do quite often. And while file-roller is capable of fulfilling that use case, it does not at this time support drag and drop functionality from the archive into nautilus. There is a merge request to restore that functionality but it’s unclear when that will be ready and I think Nautilus may be better equipped to accomplish this task in a more straightforward manner, as I’d imagine it should be capable of full DnD functionality within itself even from an archive.

My suggestion would be to add the capability for Nautilus to open (not extract) archives as a “folder” in a new (non-modal) window, with some adaptations to make it more suitable to archive management than a default Nautilus window, from which you could then extract either the whole archive somewhere or certain files, either drag and dropping them to the original Nautilus window (in whichever folder) or leveraging Nautilus’ up and coming file chooser capabilities. The work @antoniof is currently doing on that front, with these mockups as a basis, could also serve as a learning experience of how to adapt the Nautilus UI for functionality beyond its pure file manager job.

I personally feel this should become the default behavior when interacting with an archive within Nautilus, but failing that could still be a valuable secondary behavior.

1 Like

I’d like to see nautilus transparently enter the archive just as if it were any normal folder, like Windows Explorer has been able to do for nearly 20 years now.

That’s what the libarchive GVFS backend is for; of course, it requires “mounting” archives, and it also depends on libarchive supporting them.


Thanks for the thoughtful feedback, @Magio !

A few comments for nuanced context:

nautilus is not an archive manager, nor it is trying to be one.

Specifically, it’s not trying to replace the Archive Manager app (a.k.a. file-roller).

The Files application offers plain compress and extract actions.[1]

This is a major, unforeseen regression on our side. We should fix that, really. We should try Company’s suggestion. As far as I know nobody has found the time to work on this yet, unfortunately.

What I’m learning with this experience reinforces my reservations about adding an archive manager mode. Adapting to file chooser modes without breaking the file manager mode has been challenging and time-consuming enough. It would possibly take another release or two to reach this point if not for funding from the GNOME STF team.

  1. Originally provided by the file-roller-nautilus extension, nowadays built-in through gnome-autoar. This implementation change has allowed to remove file-roller from the core modules of GNOME. But that’s a different thing from replacing it as an Archive Manager. ↩︎


There is an idea I have wanted to explore for a long while: adding a preview step to the Extract action.

In other words, instead of directly extracting everything, you would be able to inspect what’s going to be extracted before confirming it.

This preview step could afford some optional control over the extraction action. Maybe we could fit “select which files to extract” into that, assuming we would still extract everything by default if that option is not used.

I’m not sure if it’s easy to visualize the concept. I should draw a mockup some day.


Thanks for the answer !

That’s part of why I tagged you in my suggestion. How well nautilus had taken to having its UI refactored for a different function is understandably a make-or-break criteria in deciding whether trying to add another (arguably more complex) mode in. With that plus the fact that I was wrong about nautilus having become the default archive manager (as opposed to just being the default archive file handler) probably should rightly disqualify my suggestion.

I think I mostly get how the preview step idea you mention would look like, which if I’m interpreting it correctly would be a very welcome addition and do away with most of the gripes I have with its current extraction capabilities, at a lower (I imagine) refactoring cost than the addition of a full archive manager mode.

Lastly, regarding file-roller and its currently missing drag and drop functionality, is what you refer to as “Company’s suggestion” the currently open merge request or is it something else?

Right, I forgot to address this caveat.

I’m not 100% sure about the whole story behind this implementation detail, but it’s something I wish to investigate.

My current belief is that there was a desire to make the default action (e.g. double clicking a file) configurable. Say, you don’t want to extract archives on double click, so you set a different default handler and it’s done…

… except it’s not, because you need to go and set a different default handler for every single as archive type. Not really a user-friendly configuration.

If this was indeed the whole story behind becoming the default handler (I need to confirm ir first), then I think it should cease to be a handler for archives, and instead have a switch in Preferences for whether to extract or open. (Or present both choices in the hypothetical preview step.)

It’s something else. I don’t have a link handy. But it’s about having a custom MIME type which basically acts as a pipe, allowing the source app (file-roller in this case) to extract directly into that pipe while the destination app (nautilus in this case) saves the content on the pipe into the target folder. Company’s idea is for the pipe to act like a tar file (content-wise), except it’s a not a real file anywhere.

Yeah, part of what brought my suggestion on is a recent OS upgrade reset my preferences which were to open all archives in file-roller to nautilus handling them, and going around changing that for each archive type is not ideal. I think I’ve gotten there, but I might be surprised by a type of tarball I haven’t thought about later.

A toggle in preferences for all archive types would be a much improved experience, but I wonder if it would require moving file-roller back into core module status? Unless the toggle was only present if file-roller or another archive manager was installed.

Another slight annoyance is that while if you set file-roller as the default the nautilus actions are still a right click away, however with nautilus as the default handler (if you prefer extract on double click) you have to right-click > open with > scroll down and select file-roller if you find yourself needing to do more than just extract the whole archive. If the hypothetical preview step made it in and let nautilus cover more (most?) of the basic use cases that wouldn’t bother me as much, but as it stands it makes having nautilus as the default handler a less-than-ideal situation in my opinion.

And regarding the options to bring back drag and drop to file roller, since it seems like it’s not been easy to find people to work on it maybe making it part of a future STF-type endeavor (if and when another such grant is awarded to the GNOME project) could help on that front.

1 Like

Haha, exactly. Good to learn my hypothesis (about this being a configuration headache for users) was right.

Hmm. Good point. I haven’t thought that far ahead.

I agree. That’s another disadvantage of nautilus posing as a MIME handler app for archive types. If we stop doing this, we could still have “Extract” as first option in the menu, but follow it up with “Open in $DEFAULT_APP” as second item.

Let’s hope that the GNOME Development Initiative succeeds in gathering such grants.

This new drag-and-drop format would basically replace XdndDirectSave, which doesn’t work on Wayland and cannot be made to work on Wayland without compromising on the security model. So there may be a compelling case here to apply for funding.

1 Like

I worked around having to do it by hand with this command to set FileRoller as the default handler for all mimetypes Nautilus supports, except for directories:

grep '^MimeType=' /usr/share/applications/org.gnome.Nautilus.desktop | cut -d'=' -f2 | tr ';' $'\n' | grep -v 'inode/directory' | xargs xdg-mime default org.gnome.FileRoller.desktop

Now the default action is to open archive files with FileRoller and in the context menu I have Nautilus’s “Extract” and “Extract to” actions to quickly extract an archive. No surprise extraction on double-click or pressing Enter.

Wow. That’s not something anyone would be able to come up with and use.

The fact you have to resort to such methods when for something that’s supposed to be configurable (and we stretch the code a lot to ensure it is configurable) confirms we need to make this configuration simpler.

GNOME Settings has the Default Apps panel that allows you to set a default for Web/Mail/Calendar/Music/Video/Photos. I think it would make sense to add Archives here as well…