Tight integration of archive manager functionality

Registered by Lee Hyde

I have for some time now been perplexed as to the reasoning behind the separation of file management and archive management. After all, to the casual the end-user an archive is little more than a compressed file or folder. Surely then it makes sense to manage files, directories and archives within the file manager interface!

I thus propose that Marlin should incorporate archive manager functionalities, and obfuscate as much as is practical the distinction between a file, directory and an archive. Obviously there should be visual cues (such a icons, emblems and chrome/UI colourations) to signify the presence of an archive and perhaps identify the algorithm. However, where the end-user is concerned, managing (editing, deleting, copying and moving) an archive and its constituent files should be indistinguishable from managing raw files and directories.

For example:

1. An archive (example.7z) containing a single file (example.odf), should appear as a .odf file with an emblem signifying that it has been archived and (if applicable) compressed. This emblem should indicate the archival algorithm used. When the end-user double-clicks this icon, the archived file (example.odf) is extracted to a temporary hidden directory (.~example.7z) in its parent directory and the default action (editing with LibreOffice) applied. Once the file has been edited and saved the modified file is re-archived and the temporary directory deleted.

2. An archive (example.zip) containing multiple files, should appear as a standard directory (perhaps with a different coloured directory icon) with an emblem signifying that it has been archived and (if applicable) compressed. Again, this emblem should indicate the archival algorithm used. When the end-user double clicks this icon, the archive should be opened within the file manager as if it were an ordinary directory. Again, a temporary hidden directory (.~example.zip) should be created in the parent directory for the purpose of file management purposes. It may also be of utility to apply some form of UI colouration (location-bar, background, etc...) to make it clear to the end-user that they are browsing an archive.

Furthermore, when the end-user requests compression of a given file or directory, Marlin should suggest the optimal compression algorithm based on context (i.e. 7z for text files, etc...). If this can be reasonably achieved (i.e. without delay) via some form of benchmarking to determine the ideal compression algorithm on-the-fly, that would be excellent. However, I suspect that such an approach would be time consuming and CPU intensive, and so context (i.e. what type of file(s) is being archived) should be used to determine the optimal compression algorithm based on what is generally known.

Blueprint information

Not started
Series goal:
Milestone target:

Related branches



Here are some of the archival and compression algorithms marlin could support (feel free to add to the list):

> Tar (.tar)
> GZip (.gz, .tar.gz and .tgz)
> BZip (.bz, .tar.bz and .tbz)
> BZip2 (.bz2, .tar.bz2 and .tbz2)
> LZO (.lzo, .tar.lzo and .tzo)
> LZMA (.lzma, .tar.lzma and .tlz)
> LZip (.lz)
> ISO (.iso)
> JAR (.jar, .ear and .war)
> 7Zip (.7z)
> Zip (.zip)
> RAR (.rar)
> ACE (.ace)
> ICE (.ice)
> LRZIP (.lrz)

It might also be nice to support Parchives (.par and .par2), although that (and some of the above) may be stepping into advanced archive management territory best suited to a standalone programme (e.g. file-roller).


Work Items

This blueprint contains Public information 
Everyone can see this information.