Bug 414742

Created attachment 124257 [details]
vnd.lotus-1-2-3 stored in /usr/share/mime/application

Created attachment 124258 [details]
vnd.lotus-1-2-3.xml stored in ~/.local/share/mime/application

This is a bug in shared-mime-info, which is identifying the file as a lotus 1-2-3 file because of its filename extension ".123". shared-mime-info has the capacity to use more advanced methods of introspection to prevent these kinds of conflicts, which it it apparently not using here. I would recommend that you file a bug for the shared-mime-info folks at https://gitlab.freedesktop.org/xdg/shared-mime-info/issues

Thanks!

Many thanks too!

Here is still an other question about this issue:
When trying to delete the "*.123" entry with systemsettings5, systemsettings5 is always crashing, as I wrote before, where should I file this?
Thanks for an answer.

System Settings | kcm_componentchooser

Thank you for this answer.
I sent this issue to freedesktop.org, but freedesktop.org wrote, that it is not a fredesktop.org issue .../123. Does "Your front-end/file manager is broken..." in their answer mean, that it is still an kde/plasma issue?

Can you share the URL of the ticket you filed so I can continue the conversation with the shared-mime-info developers?

The URL is:
https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/123
I hope, you have much better arguments, than I had.

Oh, I understand the issue now. Yes indeed, this is our issue Sorry for sending you on a wild goose chase!


STEPS TO REPRODUCE:
- Create a symlink called test.123 that points to a file that is NOT a Lotus 1-2-3 file
- Right-click on that symlink > Properties

EXPECTED RESULTS
- The symlink is identified with the MIME type of the file it points to, or maybe as a symlink

ACTUAL RESULTS
- The symlink is identified as a Lotus 1-2-3 file.

Maybe my description was too short and not transparent enough. So I think, I caused this misunderstanding myself.
But I think now, that there are 2 defects in this one description:
First:
The Symlink with a name that ends with ".123" should not be identified as a lotus-1-2-3 file.
Second:
If shared-mime-info would work correctly no one would ever had recognised the first defect. The .local mime setting would always override the default setting. But I wonder, why this does not happen. In this .local setting "*.123" files or symlinks are definitely excluded from being identified as a lotus-1-2-3 files.
Should this be a separate bug?
You have changed the status into confirmed, but "resolved as "fixed"" may become changed too?

In that case (second Bug of comment 11) I added a comment to bug # 354688 and tried to describe it as transparent as possible. Maybe at will work.

QMimeDatabase always prepends the first glob pattern in the relative mimetype xml file from /usr/share/mime/ to the list of glob patterns, so even if you remove it in your user account that glob will always be-read/added to the glob patterns of that mimetype... AFAICS, this is the intended behaviour.

Also I echo the comment from the upstream bug report:
"What real world problem does this cause, apart from a spreadsheet icon appearing in the middle of your /lib directory in your file manager?"

The reason for me to file this bug was, that I expected, that the settings in ~/.local/share/mime/application would overwrite the settings in /usr/share/mime/application here file: vnd.lotus-1-2-3.xml. But this did not happen. So I thought, that this should be solved.

(In reply to Walther Pelser from comment #15)
> The reason for me to file this bug was, that I expected, that the settings
> in ~/.local/share/mime/application would overwrite the settings in
> /usr/share/mime/application here file: vnd.lotus-1-2-3.xml. But this did not
> happen. So I thought, that this should be solved.

Well, it can't be solved because this is how QMimeDatabase works, it always readds the "main glob pattern" (i.e. the first glob pattern in the system-wide .xml file); that's been the case since around 2012.

And that also seems what other tools are doing:
gio info libvlccore.so.123 | grep standard::content-type
  standard::content-type: application/vnd.lotus-1-2-3

What we can do is change the filetypes KCM to echo what the QMimeDatabase is enforcing, i.e. disallow removing the first glob pattern in the list...

<?xml version="1.0" encoding="utf-8"?>
This is attachment Nr.2 in the list above (https://bugs.kde.org/attachment.cgi?id=124258)

<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/vnd.lotus-1-2-3">
  <!--Created automatically by update-mime-database. DO NOT EDIT!-->
  <comment>Lotus-1-2-3-Tabelle</comment>
  <glob-deleteall/>
  <glob pattern="*.wk1"/>
  <glob pattern="*.wk3"/>
  <glob pattern="*.wk4"/>
  <glob pattern="*.wks"/>
</mime-type>

And this is  from 
https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html 
(part of it)

"For example, when using the default paths, “Load all the <MIME>/text/html.xml files” means to load /usr/share/mime/text/html.xml, /usr/local/share/mime/text/html.xml, and ~/.local/share/mime/text/html.xml (if they exist, and in this order). Information found in a directory is added to the information found in previous directories, except when glob-deleteall or magic-deleteall is used to overwrite parts of a mimetype definition." 

If I understand the example right, then the line "<glob-deleteall/>" delets all the settings in /usr/share/mime/application/vnd.lotus-1-2-3.xml and overwrites it with the settings in ~/.local/share/mime/application/vnd.lotus-1-2-3.xml and the "<glob pattern="*.123"/>" will be deleted too.

$ cat .local/share/mime/application/vnd.lotus-1-2-3.xml 
<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/vnd.lotus-1-2-3">
  <!--Created automatically by update-mime-database. DO NOT EDIT!-->
  <comment>Lotus 1-2-3 spreadsheet</comment>
  <glob-deleteall/>
</mime-type>

$ kmimetypefinder5 libvlccore.so.123 
application/vnd.lotus-1-2-3

$ gio info libvlccore.so.123 | grep standard::content-type
  standard::content-type: application/vnd.lotus-1-2-3

so that's how it works in KDE and GNOME (gio).

And this is my result:
cat ~/.local/share/mime/application/vnd.lotus-1-2-3.xml
<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/vnd.lotus-1-2-3">
  <!--Created automatically by update-mime-database. DO NOT EDIT!-->
  <comment>Lotus-1-2-3-Tabelle</comment>
  <glob-deleteall/>
  <glob pattern="*.wk1"/>
  <glob pattern="*.wk3"/>
  <glob pattern="*.wk4"/>
  <glob pattern="*.wks"/>
</mime-type>
OS is openSUSETumbleweed and this should have it´s own settings. I ask myself why this doesn´t work as expected.
Okay, we should better stop here, as a consensus seems not to be possible.

I made further testing and I got the impression, that update-mime-database always and only refuses to delete <glob pattern="*.123"/>. In your comment 18  is a line <glob-deleteall/>. if this line would have been executed properly, kmimetypefinder5 would not have been able to find a matching entry. That´s my point of view.

FYI, https://phabricator.kde.org/D28079#631730

This is an upstream bug, per David's comment in the link I posted.