Bug 414742 - Symlink should reflect the MIME type of the file it points to, or else just be identified as a link
Summary: Symlink should reflect the MIME type of the file it points to, or else just b...
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.64.0
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-02 10:02 UTC by Walther Pelser
Modified: 2021-06-13 18:20 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
vnd.lotus-1-2-3 stored in /usr/share/mime/application (3.84 KB, text/plain)
2019-12-02 10:35 UTC, Walther Pelser
Details
vnd.lotus-1-2-3.xml stored in ~/.local/share/mime/application (395 bytes, text/plain)
2019-12-02 10:38 UTC, Walther Pelser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Walther Pelser 2019-12-02 10:02:41 UTC
SUMMARY
Vlc-build writes a symlink libvlccore.so.123. This is always identified as a lotus spreadsheet-file, but should be a shared lib. In home/.local/share/mime/application there is also a vnd.lotus-1-2-3.xml, which should override the setting in /usr/share/applications/vnd.lotus-1-2-3.xml, but it doesn´t. Trying to change the setting with systemsettings5 always causes a crash of systemsettings5.

STEPS TO REPRODUCE
1. always
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: openSUSE TW
(available in About System)
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.1

ADDITIONAL INFORMATION
The only way to solve this problem at the moment is to make a change in /usr/share/packages/freedesktop.org.xml. But this not the right way.
Comment 1 Walther Pelser 2019-12-02 10:35:57 UTC
Created attachment 124257 [details]
vnd.lotus-1-2-3 stored in /usr/share/mime/application
Comment 2 Walther Pelser 2019-12-02 10:38:06 UTC
Created attachment 124258 [details]
vnd.lotus-1-2-3.xml stored in ~/.local/share/mime/application
Comment 3 Nate Graham 2019-12-02 21:00:58 UTC
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!
Comment 4 Walther Pelser 2019-12-03 08:15:18 UTC
Many thanks too!
Comment 5 Walther Pelser 2019-12-03 08:45:59 UTC
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.
Comment 6 Nate Graham 2019-12-04 17:02:18 UTC
System Settings | kcm_componentchooser
Comment 7 Walther Pelser 2019-12-05 08:58:44 UTC
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?
Comment 8 Nate Graham 2019-12-05 14:41:32 UTC
Can you share the URL of the ticket you filed so I can continue the conversation with the shared-mime-info developers?
Comment 9 Walther Pelser 2019-12-05 16:24:40 UTC
The URL is:
https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/123
I hope, you have much better arguments, than I had.
Comment 10 Nate Graham 2019-12-05 23:22:21 UTC
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.
Comment 11 Walther Pelser 2019-12-06 10:02:00 UTC
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?
Comment 12 Walther Pelser 2019-12-08 11:21:31 UTC
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.
Comment 13 Ahmad Samir 2020-03-12 15:49:56 UTC
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.
Comment 14 Ahmad Samir 2020-03-15 09:31:13 UTC
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?"
Comment 15 Walther Pelser 2020-03-15 10:30:01 UTC
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.
Comment 16 Ahmad Samir 2020-03-15 11:05:19 UTC
(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...
Comment 17 Walther Pelser 2020-03-15 17:08:08 UTC
<?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.
Comment 18 Ahmad Samir 2020-03-15 19:12:29 UTC
$ 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).
Comment 19 Walther Pelser 2020-03-16 08:29:35 UTC
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.
Comment 20 Walther Pelser 2020-03-17 05:52:13 UTC
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.
Comment 21 Ahmad Samir 2020-03-21 17:24:32 UTC
FYI, https://phabricator.kde.org/D28079#631730
Comment 22 Ahmad Samir 2021-06-13 18:20:03 UTC
This is an upstream bug, per David's comment in the link I posted.