File-roller is associated with .docx,.xlsx,.pptx files instead of LibreOffice

Bug #873470 reported by Jonathan Ernst on 2011-10-13
164
This bug affects 29 people
Affects Status Importance Assigned to Milestone
desktop-file-utils
Unknown
Medium
desktop-file-utils (Ubuntu)
High
Unassigned
Oneiric
High
Sebastien Bacher

Bug Description

In a fresh oneiric installation, the default association for .docx is file-roller altough file-roller cannot open .docx files and libreoffice is installed.

TESTCASE:
- download the file from comment #3
- double click on it from nautilus
- before the update it opens with file-roller, after the update with libreoffice

I clicked on an .odp file (it has a presentation icon) and it opened in file roller and gave an error that it couldn't read it because it didn't have zip support or something. In any case I never want to open these in file roller. Maybe Evince or Documents. But probably Impress.

Would be best if we could tell the user the app isn't installed and offer the option to get it.

Sounds like this is a problem of file-roller claiming to support zip while it cannot?
What is the relation with shared-mime-info, and why should it be a bug in it?

(In reply to comment #1)
> Sounds like this is a problem of file-roller claiming to support zip while it
> cannot?

Nothing to do with that. OpenOffice documents are zip files with a bunch of files in it. We advertise that fact in shared-mime-info.

file-roller is launched because we don't have LibreOffice or OpenOffice installed so the file manager looks for the next best handler: the zip file handler.

Aside from debugging, it should never be opened within file-roller.

> What is the relation with shared-mime-info, and why should it be a bug in it?

So I think we should just remove the sub-class of zip in this case, but it would probably break mime detection.

(In reply to comment #2)
> (In reply to comment #1)
> > Sounds like this is a problem of file-roller claiming to support zip while it
> > cannot?
>
> Nothing to do with that. OpenOffice documents are zip files with a bunch of
> files in it. We advertise that fact in shared-mime-info.
>
> file-roller is launched because we don't have LibreOffice or OpenOffice
> installed so the file manager looks for the next best handler: the zip file
> handler.

Thanks for the clarification, given the bug description was not clear about it.

> > What is the relation with shared-mime-info, and why should it be a bug in it?
>
> So I think we should just remove the sub-class of zip in this case, but it
> would probably break mime detection.

This sounds like an (ugly) ad-hoc solution just to solve this specific case.
I'm pretty sure there could be (now or in the future) more cases when you want to handle a mime type but not one or more specific subclasses of it, so my suggestion would be discussing it in the xdg ml for a better solution (most probably at application level, out of shared-mime-info).

(In reply to comment #3)
> > So I think we should just remove the sub-class of zip in this case, but it
> > would probably break mime detection.
>
> This sounds like an (ugly) ad-hoc solution just to solve this specific case.
> I'm pretty sure there could be (now or in the future) more cases when you want
> to handle a mime type but not one or more specific subclasses of it, so my
> suggestion would be discussing it in the xdg ml for a better solution (most
> probably at application level, out of shared-mime-info).

What other mime-types have that problem? I can't see any, so it's not that bad a solution.

(In reply to comment #4)
> What other mime-types have that problem?

None, just like the .odp mime has no problem either.

> I can't see any, so it's not that bad a solution.

The solution is bad because the zip inheritance is perfectly fine from a shared-mime-info point of view (it represents mime types, after all).
If the problem is not letting a specific user-level file archiver application see openoffice documents as zip, then let's find an application-level solution for this (and any other potentially similar case in which you want to handle a mimetype but not some mimes inheriting from it, for any reason you want).
I personally don't think there's nothing wrong in having some file archiver opening any kind of zip files, if the user wants to.

(In reply to comment #5)
> (In reply to comment #4)
> > What other mime-types have that problem?
>
> None, just like the .odp mime has no problem either.

It very obviously does otherwise we wouldn't have this bug report.

> > I can't see any, so it's not that bad a solution.
>
> The solution is bad because the zip inheritance is perfectly fine from a
> shared-mime-info point of view (it represents mime types, after all).

Even if it's technically correct, we currently have 2 uses for sub-class-of, either it's a functional sub-class (video/mp4 is a sub-class of video/quicktime, so an app that handles quicktime should handle mp4), or it's a detection sub-class (like in the case of XML and ZIP file based file types).

> If the problem is not letting a specific user-level file archiver application
> see openoffice documents as zip, then let's find an application-level solution
> for this (and any other potentially similar case in which you want to handle a
> mimetype but not some mimes inheriting from it, for any reason you want).
> I personally don't think there's nothing wrong in having some file archiver
> opening any kind of zip files, if the user wants to.

I don't think it's wrong either, and you can still do that by renaming the file to .zip and opening it.

Two years ago, Alexander Larsson mentionned to me (in passing at Desktop Summit) an idea to solve this exact problem: his idea was to introduce the concept of private inheritance in s-m-i, so that one could say "opendocument files inherit privately from zip", i.e. the fact that it's zip is an implementation detail.

We could then have two ways to check if mimetype A inherits from mimetype B: including or excluding private inheritance.

When looking for an application that handles mimetype A (for launching the app), we would exclude it.

But when the application itself would check "is this file's mimetype supported by one of my plugins" then it would include it.

And when a filemanager wants to populate the "right click / open with ..." submenu, it could also include it, so that people could actually launch an archive program to inspect an opendocument file.

Same thing with application/octet-stream: the implied inheritance from all files could be private, so that associating an hex editor with that mimetype doesn't make it launch by default, but makes it available in the "open with..." submenus.

(In reply to comment #7)
> Two years ago, Alexander Larsson mentionned to me (in passing at Desktop
> Summit) an idea to solve this exact problem: his idea was to introduce the
> concept of private inheritance in s-m-i, so that one could say "opendocument
> files inherit privately from zip", i.e. the fact that it's zip is an
> implementation detail.

Fair enough. And I'm guessing this should be worked on in xdgmime first then.

I'm pretty busy with other stuff so I can't work on this atm unfortunately, but I think such private inheritance is a good approach. There are still reasons we want to know e.g. that some document type is really a zip file, but we clearly don't always want to expose the zip:ness of such files.

Jonathan Ernst (jonathan.ernst) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, what is the mimetype displayed in nautilus? (or could you add an example to the bug, I've no docx to try)

affects: file-roller (Ubuntu) → desktop-file-utils (Ubuntu)
Changed in desktop-file-utils (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Jonathan Ernst (jonathan.ernst) wrote :
  • test2.docx Edit (14.7 KiB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)

$ file -i test2.docx
test2.docx: application/zip; charset=binary

Jonathan Ernst (jonathan.ernst) wrote :

Funnily enough on older Ubuntu releases : this file is correctly associated with libreoffice/openoffice AND it can be successfully opened with file-roller (as docx files are zip files). But on Oneiric the file is wrongly associated with file-roller and file-roller cannot even handle the same file...

I think we have two different bugs here.

Henk-Jan (henk-jan) wrote :

I'm experiencing this bug after upgrading Ubuntu. Before upgrading docx opened correctly in LibreOffice.

Changed in desktop-file-utils (Ubuntu):
status: Incomplete → New
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in desktop-file-utils (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

the mimetype is "application/vnd.openxmlformats-officedocument.wordprocessingml.document)" where the types listed in the default list are "application/vnd.oasis.opendocument.text" and similar so the list should probably be updated for all those next mimetypes

Changed in desktop-file-utils (Ubuntu Oneiric):
importance: Undecided → High
status: New → Confirmed
summary: - File-roller is associated with .docx files instead of LibreOffice
+ File-roller is associated with .docx,.xlsx,.pptx files instead of
+ LibreOffice
Sebastien Bacher (seb128) wrote :

The issue that those types are derivated from zip ones is discussed in https://bugs.freedesktop.org/show_bug.cgi?id=40354

Charles Profitt (cprofitt) wrote :

Fedora patches look good.

Changed in desktop-file-utils (Ubuntu Oneiric):
status: Confirmed → Triaged
Charles Profitt (cprofitt) wrote :

This is also valid on 64bit

Changed in desktop-file-utils (Ubuntu):
importance: Low → High
Changed in desktop-file-utils (Ubuntu Oneiric):
assignee: nobody → Sebastien Bacher (seb128)
description: updated
Changed in desktop-file-utils (Ubuntu):
status: Confirmed → Fix Committed
Changed in desktop-file-utils (Ubuntu Oneiric):
status: Triaged → Fix Committed

Hello Jonathan, or anyone else affected,

Accepted desktop-file-utils into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Charles Profitt (cprofitt) wrote :

I tested the proposed desktop-file-utils and all PPTX, DOCX, XLSX open fine.

Thanks.

Martin Pitt (pitti) on 2011-10-20
tags: added: verification-done
removed: verification-needed

In my system package desktop-file-utils ver 0.18-0ubuntu9 is installed, in fact now .docx and .xlsx are opened with LibreOffice, but if I test it using "file" it says that they are zip file...

$ file -i test2.docx
test2.docx: application/zip; charset=binary

$ file -i test.xlsx
test.xlsx: application/zip; charset=binary

Is it the expected behaviour?

Sebastien Bacher (seb128) wrote :

not sure how "file" works but it's not used in Unity or GNOME and that's a different bug that the one addressed there

Alessio "Spinus" Moscatello [2011-10-20 10:06 -0000]:
> In my system package desktop-file-utils ver 0.18-0ubuntu9 is installed,
> in fact now .docx and .xlsx are opened with LibreOffice, but if I test
> it using "file" it says that they are zip file...
>
> $ file -i test2.docx
> test2.docx: application/zip; charset=binary

It's an unrelated problem. But anyway, file is not exactly wrong there
-- a .docx file is a zipped bunch of XML files and graphics.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package desktop-file-utils - 0.18-0ubuntu9

---------------
desktop-file-utils (0.18-0ubuntu9) oneiric-proposed; urgency=low

  * debian/defaults.list:
    - list the libreoffice openxml mimetypes as well (lp: #873470)
 -- Sebastien Bacher <email address hidden> Tue, 18 Oct 2011 15:29:36 +0200

Changed in desktop-file-utils (Ubuntu):
status: Fix Committed → Fix Released
Changed in desktop-file-utils (Ubuntu Oneiric):
status: Fix Committed → Fix Released

I have desktop-file-utils 0.18-0ubuntu9 installed but nautilus still opens docx with file roller. Is there some magic that needs doing after updating the desktop-file-utils package?

YannUbuntu (yannubuntu) wrote :

I have desktop-file-utils 0.18-0ubuntu9 installed (on Ubuntu 11.10) but nautilus still opens ppsx with File-Roller.

summary: - File-roller is associated with .docx,.xlsx,.pptx files instead of
+ File-roller is associated with .docx,.xlsx,.pptx,.ppsx files instead of
LibreOffice

those would still have the issue probably have an user preference set, could you try in a guest session?

YannUbuntu (yannubuntu) wrote :

Hi Sebastien. I checked in a brand new (and updated) Precise session : this bug is solved for .docx,.xlsx,.pptx , but still exists for .ppsx . I opened a new bug report for better tracking: Bug#904212

summary: - File-roller is associated with .docx,.xlsx,.pptx,.ppsx files instead of
+ File-roller is associated with .docx,.xlsx,.pptx files instead of
LibreOffice

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdgmime/issues/24.

Changed in desktop-file-utils:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.