is the link not working after you move in the subfolder?
because it’s now always necessary to include the path in the links. (e.g. if there isn’t another file with the same name)
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 just saw that also the Graph View ignores sub folders and only looks at the filename when linking notes. Unless there is a note with the same filename in the root folder.
But I guess there is a common internal graph used by the Graph View and the link update. (…and the auto-suggest feature, see In case of auto-complete of file inside folder only the file name is inserted)
Steps to reproduce
- Create fileA inside folderA
- Go to another file and use autocomplete of [[]] to enter the file
- Press enter
Expected result
- [[folderA/fileA]] is inserted
Actual result
- [[fileA]] is inserted
Environment
- Operating system: MacOS Catalaina
- Obsidian version: 0.6.2
- Using custom CSS: No
Additional information
This can create issues with disambiguation. In case a file is created in some other the links start pointing to the new file and all links are now wrong.
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.
3 Likes
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.
2 Likes
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/
- overview.md
-
projects.md –
Our first project was [Project ABC](overview.md) - plant-abc/
- overview.md
- plant-xyz/
- overview.md
1 Like
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.
2 Likes
Thank you very much for taking time and replying in such detail!
It is very nice to see Obsidian growing and getting better.
The point I tried to make was: IMHO it’s worth to sacrifice beauty if it leads to more stable/reliable linking. If you find a way to achieve both - even better! I am looking forward to your solutions 
4 Likes
I think the problem is that people should not have two notes with the same name in their Knowledge database. If treating Obsidian as our second brain, every concept should be unique.
But I’d like @maxhq to share in what circumstance you would create notes with the same?
Now I see your example. You use it to manage your files.
If I were you, I would name them like this:
- plant-abc/
- abc_overview.md
- plant-xyz/
- xyz_overview.md
But the officials might have a better solution.
I recorded this bug because seeing is believing. Skip ahead to 00:45. (I recorded two bugs in the video.)
Before finding this thread, I described the issue like this:
Unreliable link updating when moving from one folder to another. Instead of the link updating like it does when files are simply renamed, Obsidian creates a new document where the file used to be.
Hope this gets fixed soon!
Steps to reproduce
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’)
Expected result
temp link change to ‘folderC/mynote’
Actual result
link is alse ‘folderA/mynote’
Environment
- Operating system: macOS 10.15.3
- Obsidian version: 0.7.3
Additional information
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)”.
1 Like
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.
Steps to reproduce
- (Optional step). Select Relative path to file for New link format option in the File preferences.
- Create two subfolders in your vault.
- Place an image or a note in both folders.
- Link those notes and images.
- Move one of the linked notes into vault’s root folder and back into subfolder.
Expected result
Respect the links no matter what happens when moving files around.
Actual result
The links become broken and disconnects from the original.
Environment
- Operating system: Windows 10 Corporate
- Obsidian version: 0.8.0
Additional information
My guess is that the issue has something to deal with ../ part of the path.
1 Like
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.
In 0.8.3 we have a major overhaul of the file linking system. So check it out. I am going to archive this report. If you find some weird behaviour with the new system, open a new and specific bug report.
Thanks