:O thanks for reporting, I think we shouldn't provide decompression support for this one.

I think the problem is more general than just inappropriately supplying decompression support for file types like .docx and .xlsx that shouldn't have it because the file type has its own application.

File types like .zip that used to default to Archive Manager and which still show that as the default application also now default to "Extract Here" with no apparent way to override that as the default.  

This is simply an inappropriate change in behavior.   "Extract Here" from the user's view is like any other application applied to the file.  It should be possible to choose that as a default for a .zip file, but the fact that a file COULD be processed by "Extract Here" does not mean it SHOULD be by default.  "Extract Here" should not take precedence over an explicit choice of some other default application like Archive Manager for the file type.

This is an extreme annoyance for anyone that keeps a number of file archives in compressed format that are only occasionally viewed and where the only version  you want long-term is the compressed one.  Arvhive Manager is a much more useful default in such cases as it eliminates the need to do manual trash management to clean up extract-here files afterwards.

> This is an extreme annoyance for anyone that keeps a number of file archives
> in compressed format that are only occasionally viewed and where the only
> version  you want long-term is the compressed one.  Arvhive Manager is a
> much more useful default in such cases as it eliminates the need to do
> manual trash management to clean up extract-here files afterwards.

Can you explain the use case behind having the compressed files only? Why would you have so many of them?

To be clear, the point of this work is for the user to *not* have to deal with compressed files at all, and instead allow the full spectrum of features a regular folder allows (search, thumbnailing, etc).

The argument for allowing the user the choice of whether defaults should leave files in compressed format or not is simple:  there is no way gnome or nautilus can know the intent of the user in choosing those formats.  To assume that these are files brought from some external source which should by default be extracted makes no more sense for .zip files than for .docx or .xlsx.

In my case, most of the zip files that I retain in that format are archives of old data that are rarely consulted but convenient to have at hand.  Each file is a compression of many files and their related directory structures.  

Having them in compressed format means not only do they take less space but multiple files and directory structures are saved as a single file, so the local file system structure is simpler for processes that need to search or scan for truly active files.  Differential backup processes like rsync only have to examine a single file to determine it hasn't changed instead incurring the overhead of chasing down sub directories for hundreds of files to find none of them have changed.

In addition, keeping data in compressed format makes it difficult to change a single file in an interrelated structure of files, which is extremely important if you are talking about archived data, or even just many interrelated files that should not be changed individually but only as a group.  While there are ways to change individual files within a compressed file, it involves a very deliberate act, not something that might happen unintentionally.  

If you leave around a permanent extracted copy in addition to the compressed files, this is doubly bad for archived data.  Now not only does it take up at least double the space on the file system and on backups, but you now have the possibility that some accidental or intentional change may have rendered the two copies different and the only way to be sure is to repeatedly compare the contents of the extracted version with the original.

In these cases it is more efficient, and safer for the integrity of the data, if extraction is only done on the fly in read-only mode when the file must be read, and no extracted copy retained.

Although uncompressed archives could also address the above integrity issues, compressed archives are the only archives directly supported by menu options from nautilus, and compressed archives are the only archive formats ubiquitous enough to also have native support on non-Linux platforms.

It is dangerous to force an assumption that files that appear to be an archive, compressed or not, should be auto-extracted, because there is no way to know the intent of the user.  Use of such formats to port data across systems with the intent of extracting data once it reaches the target system is only one of a number of reasons, not the only reason, for their use.

One could make a valid argument that having "Extract Here" as the default action for .zip and similar files that are not associated with a known application might make some things simpler for a novice user; but it doesn't follow that more knowledgeable users should be denied the ability to change that default application, just as is allowed for any other file type.

Hey, thanks for the effort on the feedback! It's appreciated.

(In reply to jcewing from comment #4)
> The argument for allowing the user the choice of whether defaults should
> leave files in compressed format or not is simple:  there is no way gnome or
> nautilus can know the intent of the user in choosing those formats.  To
> assume that these are files brought from some external source which should
> by default be extracted makes no more sense for .zip files than for .docx or
> .xlsx.
> 
> In my case, most of the zip files that I retain in that format are archives
> of old data that are rarely consulted but convenient to have at hand.  Each
> file is a compression of many files and their related directory structures.  
> 
> Having them in compressed format means not only do they take less space but
> multiple files and directory structures are saved as a single file, so the
> local file system structure is simpler for processes that need to search or
> scan for truly active files.  Differential backup processes like rsync only
> have to examine a single file to determine it hasn't changed instead
> incurring the overhead of chasing down sub directories for hundreds of files
> to find none of them have changed.
> 
> In addition, keeping data in compressed format makes it difficult to change
> a single file in an interrelated structure of files, which is extremely
> important if you are talking about archived data, or even just many
> interrelated files that should not be changed individually but only as a
> group.  While there are ways to change individual files within a compressed
> file, it involves a very deliberate act, not something that might happen
> unintentionally.  
> 

You look like the perfect target to deactivate this default by the user preference in the preference dialog then.
Although I see your case, I don't think "I compress files in different structures and compressed files so my rsync works more efficiently" it's something we target by default. But there is the preference for that.

> If you leave around a permanent extracted copy in addition to the compressed
> files, this is doubly bad for archived data.  Now not only does it take up
> at least double the space on the file system and on backups, but you now
> have the possibility that some accidental or intentional change may have
> rendered the two copies different and the only way to be sure is to
> repeatedly compare the contents of the extracted version with the original.
> 

Indeed, this is less than ideal. I hope at some point we can delete the original compressed file and leave only the uncompressed one. But it will require some time for other apps to do the autodecompression automatically.

> In these cases it is more efficient, and safer for the integrity of the
> data, if extraction is only done on the fly in read-only mode when the file
> must be read, and no extracted copy retained.
> 

I don't really like making the user have to think or know that a file system is in read only mode, then change it to write mode too... this all sounds too distracting for me.

> Although uncompressed archives could also address the above integrity
> issues, compressed archives are the only archives directly supported by menu
> options from nautilus, and compressed archives are the only archive formats
> ubiquitous enough to also have native support on non-Linux platforms.
> 
> It is dangerous to force an assumption that files that appear to be an
> archive, compressed or not, should be auto-extracted, because there is no
> way to know the intent of the user.  Use of such formats to port data across
> systems with the intent of extracting data once it reaches the target system
> is only one of a number of reasons, not the only reason, for their use.
> 

Not sure I understand this. You download a compressed file to...see the files and work with them no? Otherwise... if your most common intent is just moving this compressed file around systems... then yeah, probably this tool is not appropriate for you. For that I would recommend switching off the preference.

> One could make a valid argument that having "Extract Here" as the default
> action for .zip and similar files that are not associated with a known
> application might make some things simpler for a novice user; but it doesn't
> follow that more knowledgeable users should be denied the ability to change
> that default application, just as is allowed for any other file type.

Right, that's something I pondered in the past. Problem here is that nautilus doesn't really manage compressed files as if it was it default application. Think about this more like the folders itself, since my vision is to threat the compressed files as folders as soon as possible. In this case, opening Nautilus makes the "inode" mime-type be worked by Nautilus, not that it consults the application associated to that mime-type. So in our vision to treat compressed files as folders, this is the same.

But this idea could be too much of a change for those used to the other behavior, that's why there is a preference.
Hopefully in a future this shouldn't be necessary and one can work transparently with compressed files.

Just to clarify, I would like to explore more the idea of using Nautilus as handler of these mime-types, instead of the current preference. Contributions to this exploration are more than welcome!

(In reply to Carlos Soriano from comment #5)
...
> 
> You look like the perfect target to deactivate this default by the user
> preference in the preference dialog then.
> Although I see your case, I don't think "I compress files in different
> structures and compressed files so my rsync works more efficiently" it's
> something we target by default. But there is the preference for that.
> 

You can't believe how long and hard I looked for the existence of such an option without finding it:   
Files -> Preferences -> Behavior -> under Compressed Files turn off "Extract the files on open"  and finally things work the way they used to.   docx, xlsx, zip files now all honor the default application.  There are at least two other problem reports that reference this one, and none have mentioned that simple solution because it is hard to find.  It is counter-intuitive that it is under preferences because it appears to the user in the right-click menu in the same context as a default application, which makes it look like just an unexplained failure to honor the default application.

> 
> Indeed, this is less than ideal. I hope at some point we can delete the
> original compressed file and leave only the uncompressed one. But it will
> require some time for other apps to do the autodecompression automatically.
> 

I would really hesitate to do that until it becomes more widely known how to disable the "extract on open", as the existence of the original compressed file makes recovery (by just deleting the extracted directory) much easier when "extract" was not the intent.

...
> 
> I don't really like making the user have to think or know that a file system
> is in read only mode, then change it to write mode too... this all sounds
> too distracting for me.

I wouldn't advocate being able to change from read to write mode.  I would want an attempt to change a file from within that environment to be rejected.
...
> > It is dangerous to force an assumption that files that appear to be an
> > archive, compressed or not, should be auto-extracted, because there is no
> > way to know the intent of the user.  Use of such formats to port data across
> > systems with the intent of extracting data once it reaches the target system
> > is only one of a number of reasons, not the only reason, for their use.
> > 
> 
> Not sure I understand this. You download a compressed file to...see the
> files and work with them no? Otherwise... if your most common intent is just
> moving this compressed file around systems... then yeah, probably this tool
> is not appropriate for you. For that I would recommend switching off the
> preference.
> 

Therein lies the mis-understanding.  Relatively few of my compressed files are ones I've downloaded.  Many more started out as uncompressed files and directories of various saved documents, scanned records, etc., eventually by age becoming inactive files but of archival interest and were at that point converted into compressed files.  I'm talking about files that are evolving in the opposite direction from ones you are describing.

> > One could make a valid argument that having "Extract Here" as the default
> > action for .zip and similar files that are not associated with a known
> > application might make some things simpler for a novice user; but it doesn't
> > follow that more knowledgeable users should be denied the ability to change
> > that default application, just as is allowed for any other file type.
> 
> Right, that's something I pondered in the past. Problem here is that
> nautilus doesn't really manage compressed files as if it was it default
> application. Think about this more like the folders itself, since my vision
> is to threat the compressed files as folders as soon as possible. In this
> case, opening Nautilus makes the "inode" mime-type be worked by Nautilus,
> not that it consults the application associated to that mime-type. So in our
> vision to treat compressed files as folders, this is the same.
> 
> But this idea could be too much of a change for those used to the other
> behavior, that's why there is a preference.
> Hopefully in a future this shouldn't be necessary and one can work
> transparently with compressed files.

That this had been introduced as a preference setting may have been stated in the Fedora Release Notes somewhere, but having jumped from f22 to f25 I must have missed or not understood its implication it if it were mentioned.  From the user's standpoint it is always safer if a new preferences option has a default value that preserves prior behavior.

Knowing that the option exists, I have now set it off because I much prefer the old behavior of honoring of the default application of Archive Manager for compressed files. 

I also concur with your comment 1 observation that [even with "Extract the files on open" option set in preferences] decompression support should be suppressed for file types like docx and xlsx that are always regarded by the user and associated application as a single entity.  In the meantime until that change can be effected, I would also suggest that turning off the "Extract the files on open" option be offered as a circumvention for those for whom the unexpected behavior on docx and xlsx files is an annoyance.

(In reply to Carlos Soriano from comment #6)
> Just to clarify, I would like to explore more the idea of using Nautilus as
> handler of these mime-types, instead of the current preference.
> Contributions to this exploration are more than welcome!

I don't understand enough of the internals to know what you mean here, but what I would like to see is a more consistent user interface than was used with the "Extract Here" default change.  

It would have been much cleaner from the user standpoint if there had been some way to set "Extract Here" as a default application preference using preferences on a file with that file type, like for other external applications, even if the associated  action is really performed somehow by internal code rather than a separate application.  That way if through some design error an inappropriate file type is mapped to that function, the same technique of just assigning a different default application to the file type would have been an obvious way to fix the problem.  

It is inconsistent to have some file actions be controlled by Nautilus preferences, others controlled by file type preferences, and have both presented to the user in the same way on the action menu for a selected file, as that makes it impossible to know where to go to change an unwanted default action.

> 
> You can't believe how long and hard I looked for the existence of such an
> option without finding it:

That's why I don't like preferences, but what can we do :)
   

> Therein lies the mis-understanding.  Relatively few of my compressed files
> are ones I've downloaded.  Many more started out as uncompressed files and
> directories of various saved documents, scanned records, etc., eventually by
> age becoming inactive files but of archival interest and were at that point
> converted into compressed files.  I'm talking about files that are evolving
> in the opposite direction from ones you are describing.

That's definitely not something we want as default use case, rather as mentioned a preference.

> That this had been introduced as a preference setting may have been stated
> in the Fedora Release Notes somewhere, but having jumped from f22 to f25 I
> must have missed or not understood its implication it if it were mentioned. 
> From the user's standpoint it is always safer if a new preferences option
> has a default value that preserves prior behavior.

It has been in Fedora release notes, GNOME release notes, my blog post I do every release to show what's new and what changed in Nautilus for users (precisely for this case), has been in OMG Ubuntu and other news...

BUT you didn't notice, because you shouldn't have to follow these ^ things. We should present "what's new" inside the app, however for that we need to switch to a model where apps get updated independently of the distro so we can update more frequently, otherwise you would see what's new only in the last version, not from your fedora 22 to fedora 25.

I'm eager to see this, really :)

> In the meantime until
> that change can be effected, I would also suggest that turning off the
> "Extract the files on open" option be offered as a circumvention for those
> for whom the unexpected behavior on docx and xlsx files is an annoyance.

Not really, we also want to evolve and change. This is just a bug to be fixed :)

> 
> It would have been much cleaner from the user standpoint if there had been
> some way to set "Extract Here" as a default application preference using
> preferences on a file with that file type, like for other external
> applications, even if the associated  action is really performed somehow by
> internal code rather than a separate application.  That way if through some
> design error an inappropriate file type is mapped to that function, the same
> technique of just assigning a different default application to the file type
> would have been an obvious way to fix the problem.  
> 
> It is inconsistent to have some file actions be controlled by Nautilus
> preferences, others controlled by file type preferences, and have both
> presented to the user in the same way on the action menu for a selected
> file, as that makes it impossible to know where to go to change an unwanted
> default action.

Yeah you are right.

Keep in mind the "choose application" hopefully will change soon, and we will have portals (search Flatpak portals) for that.

In any case, Nautilus can still be a handler of these compressed mime-types as we are proposing here.

It seems like this bug report is getting a bit sidetracked. To me there appear to be several issues here:

1. Files that contain zip file metadata but are not really archives from a user perspective, like docx, xlsx, etc. are extracting when double-clicked instead of opening with an office application. This is clearly a bug, nobody would ever want to extract these files by default instead of opening them.

2. Extracting an archive as the default action when double-clicking, rather than opening an archive manager, violates the principle of least surprise and is potentially damaging (it could fill up the disk for instance). Since there's no real user feedback that anything has happened other than a folder appearing next to the file they double-clicked, they can easily end up doing it more than once and creating multiple extracted copies.

3. The "Open With" tab in the file properties gives misleading information about what the default action is on archive files. It says that they will be opened with Archive Manager, for example, but that isn't what happens. Having an option in the Preferences window to disable this behavior, where nobody knows it's there and which has an unreasonable default setting, is not the answer.

Let's keep this bug for only what the tittle and product is, no doc files etc. should be treated as archives in gnome-autoar.

Feel free to open a new one in Nautilus for the misleading "Open with".

Hm actually the original bug was Nautilus default application being ignored, so this should be the opposite. This bug as the Nautilus one, I will open a new one for gnome-autoar.

One thing to work on is if we go with the mime-type handling path, we need a UI that works also when opening compressed files from any other app that will open in Nautilus.

As long as this bug is not fixed, I suggest defaulting /org/gnome/nautilus/preferences/automatic-decompression to false.

(In reply to Robert Hancock from comment #11)
> 3. The "Open With" tab in the file properties gives misleading information
> about what the default action is on archive files. It says that they will be
> opened with Archive Manager, for example, but that isn't what happens.
> Having an option in the Preferences window to disable this behavior, where
> nobody knows it's there and which has an unreasonable default setting, is
> not the answer.

Reported in a separate bug: https://bugzilla.gnome.org/show_bug.cgi?id=780355

This specific bug (as per the tittle) has been fixed in https://bugzilla.gnome.org/show_bug.cgi?id=780214 so closing this one.

I opened a new one for Nautilus to support compressed files as regular mime types in https://bugzilla.gnome.org/show_bug.cgi?id=780386