Links break when moving/renaming linked files

[MikeNakis]

This bug is monstrous, so I thought it has probably been reported already, but I searched the forum and could not find anything like it. Apologies if there is something and I missed it.

The bug happens with all plugins disabled, and without sync. It also happens in the sandbox vault. I am using Windows 10.

Steps to reproduce

Create note /posts/post/index.md
Create subdirectory /posts/post/images
Copy some image into the subdirectory, say /posts/post/images/image.png
Edit index.md and type in the following link: ![](images/image.png)
The image should appear in the note.
Now rename image.png to image1.png

Did you follow the troubleshooting guide? [Y/N] Yes, happens in the sandbox.

Expected result

I expect the link to the image to be updated as follows: ![](images/image1.png)

Also, if something goes wrong, and the link for some reason becomes broken, then I expect obsidian to stop showing me the image in the note. When obsidian keeps showing me an image whose link is invalid, it is trolling me; it is making mistakes much easier to happen, and troubleshooting a lot harder.

Actual result

Obsidian tries to update the link, but in so doing it removes the subdirectory part from the link, so it becomes ![](image1.png), which is broken.

Furthermore, obsidian keeps showing me the file in the note, so it is trolling me.

Environment

SYSTEM INFO:
Obsidian version: v1.9.12
Installer version: v1.9.12
Operating system: Windows 10 Pro 10.0.19045
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

---

Additional information

The same problem happens if you rename images to images1, or post to post1.

[CawlinTeffid]

If in Settings > Files and Links you have “Use wikilinks” deactivated and are using the default “shortest” setting for new links, this may be expected behavior. Changing “shortest” to one of the other settings should stop it.

[MikeNakis]

@CawlinTeffid thanks for responding.

Contrary to your guess, my “Use wikilinks” option is activated.

Now, under “New link format” I do indeed have “Shortest path when possible” selected. However, this is supposed to be for “new” links. The explanation says “What links to insert when auto-generating internal links”. I have no idea under what circumstances obsidian might auto-generate internal links, but updating an already existing link as a result of a rename does not sound like such a circumstance.

Furthermore, the name of the option I have chosen is “Shortest path when possible”, it is not “Select this if you like broken links.”

So, I maintain this is a bug.

[WhiteNoise]

There are a couple of settings to nudge obsidian into working with markdown links and path relative to the current file.

Be aware that relative path mode (to the current file) and using markdown links is in an incomplete/broken state.

For example:

Broken links in relative path mode on move/rename

In Relative-path mode, relative links should be updated when: a linked file is moved (done!) AND a note that contains the link is moved (to-do!). EDIT: Added minimal example: Have foo.md and bar.md in the root of the vault. With foo.md containing [[bar]] move foo.md to /subdir Expected foo.md content: [[../bar]] Actual [[bar]] Same problem applies to standard markdown links.

[MikeNakis]

Setting “New link format” to “Relative path to file” seems to be a workaround for the problem.

[MikeNakis]

OK then I guess my bug report is a duplicate of that one.

[WhiteNoise]

No, your bug report is not a duplicate of that one. I am just warning you to be careful going down the path of markdown links and relative path mode.

When I read your bug report I think you are surprised that ![](image1.png) works, and it shouldn’t . We are pretty non compliant when it comes to standard markdown links.

[CawlinTeffid]

@MikeNakis

Contrary to your guess, my “Use wikilinks” option is activated.

I had thought it was necessary to turn off “use wikilinks” to make Markdown likes behave like wiki ones, but apparently not.

@MikeNakis

I do indeed have “Shortest path when possible” selected. However, this is supposed to be for “new” links. The explanation says “What links to insert when auto-generating internal links”. I have no idea under what circumstances obsidian might auto-generate internal links, but updating an already existing link as a result of a rename does not sound like such a circumstance.

I understand expecting Obsidian to preserve the existing format, but updating a link sounds exactly like such a circumstance to me (and is consistent with how it has treated my wikilinks). Obsidian is replacing the old link with a new one.

“Shortest path when possible” essentially produces wiki-like behavior. It allows you to link to any file in the vault folder by using only its name (unless another file has the same name; then a path must be used to reach the right one). Doing this with Markdown syntax is unusual of Obsidian, but I guess it doesn’t violate any rules, since Markdown doesn’t restrict (or barely restricts) what link destinations can look like.

If you don’t want the behavior that setting is meant to produce, don’t use that setting. Unfortunately (since it looks like you’re managing a website) the other options have their own issues. Obsidian’s handling of relative links is buggy, and the “Absolute path in vault” setting produces links without the leading slash required by other apps to recognize them as root relative. (Related feature request: Start absolute path (path from vault folder) with a leading slash / .) People (including Obsidian’s CEO) use Obsidian to manage websites anyway, so presumably this can be worked around, but I don’t know the details (someone in the FR thread mentions adding the leading slash manually ).

[MikeNakis]

A note on the image that is still being displayed despite the link being broken:

Okay, I understand now that obsidian will try to find the file by filename regardless of its location; however, I still maintain that this is trolling the developer, just as all of the following in all software all over the universe are trolling the developer:

• all cases of works-by-magic
• all cases of silent failure
• all cases of failure to fail

So, my suggestion would be to keep this magic behavior for wiki links only, for those who like magic, and be more strict with regular markdown links, for those who do not like being trolled.

Also, obsidian going the extra mile and finding the missing file despite the broken link is only part of the story; it seems to me that there is something more sinister at play; try not just removing the relative path from the link, but actually deleting the linked image from the filesystem; obsidian keeps showing the image despite the fact that the image has been deleted. I can hardly believe that this is by design. At any rate, it shouldn’t.

[CawlinTeffid]

@MikeNakis

try not just removing the relative path from the link, but actually deleting the linked image from the filesystem; obsidian keeps showing the image despite the fact that the image has been deleted. I can hardly believe that this is by design. At any rate, it shouldn’t.

The image may be cached. I tried this and was surprised to see the image still visible. I switched to Reading View and saw instead a message saying the image could not be found. When I switched back to Live Preview the image was still visible. I opened a different note, then went back, and the image was now gone, replaced by the “could not be found” message.

If the image still persists after you go to another note and back, perhaps there is another copy of it in the vault?