Absolute link path has higher precedence than relative path

[mnaoumov]

Steps to reproduce

Consider vault with the following files

A.md

Absolute path resolved A

Folder/A.md

Relative path resolved A

Folder/B.md

Wikilink [[A]] resolves to the root `A.md` rather than to the relative one `Folder/A.md`

Same issue with the markdown link [A](A.md)

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

Relative Folder/A.md should be taken precedence when resolving absolute vs relative path collisions.

Actual result

Root A.md is resolved as a link.

Environment

SYSTEM INFO:
Obsidian version: v1.4.16
Installer version: v1.4.13
Operating system: Windows 10 Pro 10.0.22621
Login status: logged in
Catalyst license: insider
Insider build toggle: on
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

---

Additional information

There exists a workaround to explicitly specify the type of the links

[[/A|A]] and [A](/A.md) resolve as absolute link path

[[./A|A]] and [A](./A.md) resolve as relative link path

However such workaround has its own issues, and it’s better for it to be addressed on the Obsidian dev level

[WhiteNoise]

This is not a bug. it’s intentional. Otherwise, where [[A]] points to depends on which file it is contained. We don’t want that. We want [[A]] to point to the same note across the vault.
In other words, we don’t want [[A]] to point to one note if it is contained in Folder1/Note1.md and to another note if it contained in Folder2/Note2.md.

@mnaoumov

Folder/A.md

Relaitive path resolved A

No, a link to [[A]] in that note still resolves to A.md in the root.

[mnaoumov]

What if we consider this not as a bug but as a feature request to add a configuration setting? By its nature markdown built to use relative paths, so while Obsidian team prefers the absolute paths by default, I think it would be very handy to give a setting to switch to relative-first approach. Or even disabling absolute path resolution completely

[WhiteNoise]

You can open a FR about this if you want. I am unsure how likely it is to happen.

Regarding relative paths, this is more likely to happen:

In relative path mode, always add `./` and `../` in front of links

In relative path mode, always add ./ in front of links for files in subdirectories relative to the current file and ../ for files in subdirectories above the current file. This is particularly important since Obsidian doesn’t use a front / in absolute path mode and this creates confusion and ambiguity.

[mnaoumov]

My FR

[mnaoumov]

@WhiteNoise I found a new argument explaining why this behavior is indeed a bug

If you run the following code

app.fileManager.generateMarkdownLink(app.vault.getAbstractFileByPath('Folder/A.md'), 'Folder/B.md')

you get

[A](A.md)

According to the API documentation, generateMarkdownLink generates a markdown link to the destination Folder/A.md from the source Folder/B.md

However as described in the previous comment, the link leads to the root A.md instead

If we would want to get a link to the root A.md

app.fileManager.generateMarkdownLink(app.vault.getAbstractFileByPath('A.md'), 'Folder/B.md')

we get

[A](../A.md)

which is a valid link to the root A.md

I think, those examples prove that at least the API documentation and the Obsidian link resolution logic are inconsistent.

[WhiteNoise]

Yes, this is a bug of the link generator/suggestion, not the link resolver.

I’ll write a bug report about it. Thanks!

[mnaoumov]

I am sorry, but I disagree. Such links work properly in every other markdown editor. And only Obsidian treats them in a non-standard way.

Obsidian team claims

Obsidian strives for maximum capability without breaking any existing formats. As a result, we use a combination of flavors of Markdown.

Therefore, such behavior is a violation of the declared principle, and should be considered as a bug.

I understand the undesired effect of changing the behavior, that’s why I suggested a more configurable way in my FR

[WhiteNoise]

ok, you opened your FR for that.