#1

In Relative-path mode,
relative links should be updated when:

  1. a linked file is moved (done!)
    AND
  2. a file 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]]
4 Likes
When moving a note to a different folder, the internal links are not updated
Internal link not updated automatically when moving note to a different directory
Move vault files by Obsidian command line option or URL to allow scriptable link updates
Note created from relative link lands in root
#2

Please use the template when reporting bugs.

:wink::grimacing::face_with_hand_over_mouth:

2 Likes
#3

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

Steps to reproduce

  1. Make a new note in root vault directory
  2. Insert screenshot in note:
    ![](attachments/Pasted%20image%2020210302020308.png)
    This is compatible with most MD editors and image renders fine when viewed in Github.
  3. Move note inside a folder in the vault (e.g., Vault/Test). The link to the embedded image is not automatically updated

Expected result

embedded image link will be updated to ![](../attachments/Pasted%20image%2020210302020308.png)

Actual result

link stays the same:
![](attachments/Pasted%20image%2020210302020308.png)
This renders fine with in Obsidian but broken in other MD editors or when viewed in Github.

Environment

  • Operating system: macOS 11.2.1
  • Obsidian version: 11.4

Additional information

#4

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.

#5

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ā€¦

2 Likes
#6

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.

1 Like
#7

Iā€™m on 0.12.10 and can confirm that this bug still exists.
Itā€™s a big problem

1 Like
#8

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. :frowning_face:

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.

2 Likes
#9

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.

1 Like
#10

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.

#11

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.

#12

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.

#13

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 ?

1 Like
#14

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!

1 Like
#15

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)

2 Likes
#16

Everyone may also have a look at my previous bug report.

1 Like
#17

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.

3 Likes
#18

Stillļ¼Œno solutionā€¦
it really bugs me.

1 Like