Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] broken symlink for .desktop #44

Open
zaza42 opened this issue Oct 19, 2023 · 2 comments
Open

[Bug] broken symlink for .desktop #44

zaza42 opened this issue Oct 19, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@zaza42
Copy link

zaza42 commented Oct 19, 2023

Description

findex skips a valid .desktop file if found a broken symlink with similar name

Do you already have Findex Installed? (If yes, how did you install?)

building from findex-0.8.0.tar.gz

To Reproduce

There is a valid /usr/share/applications/chromium.desktop and a broken symlink at ~/.local/share/applications/chromium.desktop.
findex doesn't find anything "chromium" until I remove the broken symlink.

Expected behavior

Just ignore the broken symlink and use the valid chromium.desktop.

Screenshots

no need for them

System information

  • Distro: Debian sid/unstable
  • Findex Version: 0.8.0

Output of rustc --version --verbose (if you compiled findex on your machine):

rustc 1.70.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.6

Log/Output (if applicable)

nothing relevant

Additional context

I have to restart findex-daemon after deleting the broken symlink.

@zaza42 zaza42 added the bug Something isn't working label Oct 19, 2023
@mdgaziur
Copy link
Owner

I think it's more of a GTK issue as Findex uses utilities provided by that. I'll still check this anyways.

@trinitronx
Copy link
Contributor

To Reproduce

There is a valid /usr/share/applications/chromium.desktop and a broken symlink at ~/.local/share/applications/chromium.desktop. findex doesn't find anything "chromium" until I remove the broken symlink.

Expected behavior

Just ignore the broken symlink and use the valid chromium.desktop.

This is actually to be expected, given that the FreeDesktop standard specifies what should happen when two .desktop files with the same Application ID are found: The user-level one in ~/.local/share/applications/chromium.desktop will take precedence. That rule holds even when it is a broken symlink, or a file containing a syntax error. It's probably best to simply remove the broken .desktop symlink, because it is broken and overriding the other.

Here's the relevant part of the FreeDesktop spec that goes over the precedence rules:

Desktop File ID

Each desktop entry representing an application is identified by its desktop file ID, which is based on its filename.

To determine the ID of a desktop file, make its full path relative to the $XDG_DATA_DIRS component in which the desktop file is installed, remove the "applications/" prefix, and turn '/' into '-'.

For example /usr/share/applications/foo/bar.desktop has the desktop file ID foo-bar.desktop.

If multiple files have the same desktop file ID, the first one in the $XDG_DATA_DIRS precedence order is used.

For example, if $XDG_DATA_DIRS contains the default paths /usr/local/share:/usr/share, then /usr/local/share/applications/org.foo.bar.desktop and /usr/share/applications/org.foo.bar.desktop both have the same desktop file ID org.foo.bar.desktop, but only the first one will be used.

If both foo-bar.desktop and foo/bar.desktop exist, it is undefined which is selected.

If the desktop file is not installed in an applications subdirectory of one of the $XDG_DATA_DIRS components, it does not have an ID.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants