Oh interesting. The link is still working. I.e. now both of the following links work from the root folder: [[subfolder/note-a]] and [[note-a]]
… until I create a note note-a in the root folder. From this moment on the second link leads to note-a in the root folder.
I think there is some confusion here on what the expected behaviour should be.
We are aiming at referencing notes in the simplest possible way. So, if there is no ambiguity, you can refer to a note with just its title.
If there is ambiguity, then we force you to specify (a part of) the path.
We still have work do to to cover all the corner cases (and updates).
The issue here is that once a filename stops being unique, existing links stop working. The right fix would be to update the existing links. If the change is made outside Obsidian, you can’t always catch it in real time so that case need not be fixed but at least if the rename or modifying name of a new note is done from within obsidian this should be possible.
I absolutely agree. Features like renaming and moving in conjunction with auto-updates of links only make sense if they work reliably.
The corner cases are IMHO not too far fetched: I tested Obsidian for 30min to evaluate it, and I find it to be the best existing tool for “locally hosted notes in plain files with references and backlinks” so far. But I already stumbled upon the glitches when moving files and it’s a bit sad - I want to use Obsidian for all my future projects.
It should be relatively easy write down (or draw a graph with) the possible cases to then write tests for them - I am happy to help.
Is it really useful to reference notes in the simplest possible way? If you want/have to use other markdown tools, they couldn’t resolve links to notes in subfolders if not “fully qualified”. If you stay in Obsidian, the great auto-complete feature makes it easy to insert full references. So why not always fully reference them? Or even better - make it a “compatibility option”. If Obsidian handles the corner cases, simple referencing where possible would be fine for my use case.
I just realized that esp. the case I described in my second post is hard to solve with simple links: a simple link is ambiguous - it might link into a sub folder or to a not-yet-existing note in the same folder. This could lead to a lot of confusion e.g. when having structures like
projects.md – Our first project was [Project ABC](overview.md)
I want to reassure you that we are aware of the issues you are raising and we had internal discussions about it.
We will have proper mechanisms in place before 1.0 to handle these cases. It’s a short term goal.
@scmwiz: yes, there will be cases where outside Obsidian you can break the internal consistency. There is nothing we can do about it, because you have access to the data structure directly (the markdown files).
Yes, it is useful. Because, if possible, we don’t want to clutter your note taking experience with fully qualified pathnames.
1、create a new file name ‘mynote’ in folderA
2、create another new file name ‘mynote’ in folderB
3、create a new file name ‘temp’ and link to ‘folderA/mynote’
4、rename ‘folderA’ to ‘folderC’
5、link of ‘temp’ is broken (link is alse ‘folderA/mynote’)
temp link change to ‘folderC/mynote’
link is alse ‘folderA/mynote’
Operating system: macOS 10.15.3
Obsidian version: 0.7.3
if there is same filename, link will include path.
if there is not same filename, link just use filename.
this will not ensure that the link is correct. may be all links include path, and if rename filename or foldername, update all links.
One of the reasons why I like Obsidian is because of the development team’s principle that “we want you to own your data”. In order to help the end-user avoid vendor lock-in, ‘extra’ features - no matter how helpful - that add proprietary syntax should be kept to a minimum (and not encouraged).
In order for the markdown used in Obsidian to be ‘as compatible as possible’, the end-user should be able to choose themselves whether they want to have their file paths automatically trimmed, or not.
My own experience, is that if I type “projects/alpha.md” as a file path, I expect the program to leave it alone, as-is. Auto-shortening my file paths is likely to make it so that the document will work in Obsidian, but not necessarily in other software. Note that the path auto-shortening happens even if use ‘standard’ markdown-style links, rather than WikiLinks - e.g., “[my link](projects/alpha.md)” gets automatically shortened to “[my link](alpha)”.
Suppose I have a folder “F1”, and a file “file.md” inside. I also have a folder “F2”, and a file “file.md” inside too.
In another file “abc.md”, if I write[[, it will let me choose "[[F1/file.md]]"or “[[F2/file.md]]”. This is nice.
However in another situation, which I only have the folder “F1” and the file “file.md” inside at first:
In “abc.md", if I write[[, it will fill as “[[file.md]]”. This works. But if I then create a new file “file.md” in another folder, [[file.md]] will link to the new file, which is weird.
I have the same/similar issue to report as @AlexanderSavenkov. I am using relative links, as it seems to me that that is the most compatible externally.
Relative links seem to update fine when you move the file that is being linked to. However, relative links are not updating when you move the file that has the link in it. Sometimes they stay functional, such as when the folder level remains the same, but if you move to a higher or deeper folder level, it no longer works.