In Relative-path mode,
relative links should be updated when:
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
foo.md content:[[../bar]][[bar]]Same problem applies to standard markdown links.
Please use the template when reporting bugs.
I’m using a single vault attachment folder/relative path to file /MDlinks so embedded images will still work with most MD editors like Typora or when synced in Github when I want to read my notes on my phone. However, I tend to move notes around in the vault across different folders (ex. Inbox folder first, then to Project1 folder). This breaks the links for the embedded image files since links are not automatically updated.
Settings:
Automatically Update Internal links: On
New link format: Relative path to file
Use [[Wikilinks]]: Off
Default Extension for file attachments: In the folder specified below
Attachment Folder Path: attachments
embedded image link will be updated to 
link stays the same:
This renders fine with in Obsidian but broken in other MD editors or when viewed in Github.
I’m on 0.11.13 and can confirm that this bug still exists – when the file that contains the link is moved, the links (relative paths) won’t be updated.
Hi I was wondering if this is planned to be fixed in the near future?
Relative path is how these markdown files can play nicely with other programs, which I think is important as local first & plain files are what Obsidian advertises itself. With this renaming function broken, it really generates a lot of hesitation/fear despite that the links will still work within Obsidian while the relative paths are incorrect…
Yeah, this just bit me. I reorganized my entire vault, and now almost none of my links are valid anymore.
I would expect that moves/renames would update references, but it does not. This becomes very problematic when consolidating & summarizing notes. Now a significant amount of effort has to be put into listing out all reference points up manually updating them.
That’s a LOT of friction, and a LOT of error.
I’m on 0.12.10 and can confirm that this bug still exists.
It’s a big problem
Unfortunately, I haven’t been using Obsidian for a while due to this bug hasn’t been fixed for so long. This bug report post has been listed as a high priority and in the discord server I’ve mentioned this bug a couple of times but it doesn’t seem to be that important among other things. 
My ideal workflow requires me to move things a lot AND I would like my files to be accessible and fully functional in other markdown editors – this was the reason why Obsidian was so attractive at the beginning, at least for me. But as long as this bug doesn’t get fixed, it kind of is a joke of me thinking that my data is really portable if I keep using Obsidian.
Actually, a few days ago I renamed the tag high priority to important. Because I believe high-priorty gave the impression that things were going to be worked out right away, which as you have seen is not the case.
This problem will require a substantial amount of work, this is more a feature request than a bug to be squashed.
We recognize the importance of fixing/implementing this but it hasn’t been prioritized.
Thanks for the update and being upfront about the priority vs importance of this bug/feature!
I love Obsidian and appreciate everything that it and its plugins have made possible! But this is a deal breaker for me personally. That said - I’ll keep an eye on this and will gladly return once this has been properly addressed.
One thing – it would be nice to make it clear in the setting panel (options > file links) within the app. I would argue it is definitely a bug instead of a feature request as long as it has not been made clear, and users would think this renaming should be the default behavior when they are deciding which linking mode to go with. I am pretty sure there are a lot of people who don’t even notice this “bug” because within Obsidian the linking appears to still work (I believe through Obsidian’s own internal metadata), even without the actual data been fixed. This is a huge “bug” (yes, it is) because your data isn’t really portable as Obsidian advertises itself.
Edits: fixed typos.
In a sense, I agree with you. The thing about bug vs feature request from a dev POV is because this is not a corner case to be fixed, this is a whole new system to be implemented. I understand from the user POV this is a bug.
I would go as far removing relative path mode until this is done or adding warning as you suggested.
Yes I think a warning would be good enough. Removal of relative path mode might break other people’s workflow and I wouldn’t want to see that either.
I totally agree with and recognize that it might require a substantial amount of work to implement that properly. But when it’s done it really would be awesome, because if it is paired with markdown link mode, it makes it super easy for a lot more markdown editors to play nicely with the files we create using Obsidian.
Hmm, where are we on this feature ? I make a test today and seeing that moving files to sub-level will auto change the relative path, but then moving up to parent-level will not. HOWEVER tho, in obsidian it still show the correct attachment in preview mode, even the link is now broken. This is pretty dangerous behavior as it causes data corruption and it’s very annoying to recover it. Any comment ?
I just want to confirm that this bug is still present - moving a file’s location when it has a relative link within results in no change in the links within the document itself. (Links TO the document are updated, just not WITHIN the document.) I am using v0.12.15. Thank you for your attention to this!
I’m also waiting for a fix.
unfortunately the developers do not consider this a serious problem.
besides, only the relative path is the “FUTURE-PROOF FORMAT” (as in the program description)
because it is supported by other applications(Typora, etc)
Everyone may also have a look at my previous bug report.
Is there any plan to at least add the warning inside Obsidian’s Settings > Files & Links > New link format?
I think this is a really dangerous setting if people are not inspecting the behaviors carefully, particularly because that those incorrect links (corrupted data) can still be interpreted correctly by Obsidian itself but obviously not other editors. This means that people might not even notice their data has been/is/will be corrupted, for a workflow that seems to work well within and only within Obsidian itself.
I acknowledge that this might not be fixed (or implemented, per dev’s POV) in the near future. But I feel the lack of warning when the devs are aware of the issue is inappropriate, especially when Obsidian bills itself as future-proof.
Please let me know if I’m missing anything, and I apologize if the warning is mentioned somewhere, or if the issue has been resolved.
Still，no solution…
it really bugs me.
Hi team, just broke links on about 700 files because there was no indication that this would happen. A fix would be really nice 
EDIT: huh! looks like closing & relaunching Obsidian updated all the links, actually!
Not a fix, but you can use this tool to find broken links and correct them manually, if there aren’t many: