Obsidian has trouble creating new notes from "Relative path to file" links

While I agree that relative links aren’t the easiest to maintain, they do feel a bit more neural than paths relative to some core hierarchy. Relative links are independent of hierarchy and solely rely on the relationship between two Notes. Ideally, though, we’d scrap folder hierarchy entirely for a purely unique ID relationship. Luhmann was right to do this because then things are truly independent of their organization.

I can’t seem to reproduce this exactly on Windows or Mac. If I try to make a note at [[../test]] I get a weird “File Names cannot end with a dot or space” error on Windows or the “Folder already exists” error in Mac. However, I think you might be on to something with this, maybe Obsidian is trying to create a Note relative to the Vault root when it doesn’t exist and only correctly pathing relative to the current Note when the linked file already exists…

1 Like

Is there any way to see whether this is a problem that’s planned to be addressed, if it’s not scoped, or if it’s not going to be fixed ever?

I’m a new user and this is hugely annoying. I was working on setting up a task list which I want to create nodes to future notes in sub-directories… And of course I ran into this :slight_smile: It creates folders and files, but based on the root of the vault not the relative directory. [[./subdir/file]] from /root/category/file will create /root/subdir/file instead of /root/category/subdir/file.

I was pretty excited about the ability to create grey nodes for not-yet-done tasks… Since that lets me skip the annoying process of going and creating a bunch of new empty files just to go and link to them.

Edit: I’m on Ubuntu 22.04.04

I see that this issue has been around for a while. If the code is viewable somewhere, perhaps I can take a look at it? I used to do this sort of thing for a living.

Hi, I saw your remark in the other post:

We have a fraction of users using nested vaults. It will break their use case.

I understand that backward-compatibility is important, even if I think that relative links would rather better support their use-case. So I would like to request an Option to choose the Behavior of File Creation (and also of Link-Resolution) to prefer Links relative to the current File.

Is there already a Feature Request to support Links relative to the current File, instead of relative to the Vault-Root? If not, I would create a new FR. The existing FR Add settings to control link resolution mode deals with resolution order, not with creation of new, non-existent Files.

We have a great deal of open issues/unimplemented stuff regarding relative path mode. It’s not just about file creation.

It’s possible that when we do this, we will tackle all the relative path mode open issues in one sprint. When that will happen I don’t know.

It is unlikely that we implement a toggle in settings that makes the interpretation of where a link points to depended on that toggle. Otherwise, when you look at vault, you would need to know what that setting was to properly reconstruct the link graph (this is bad for external interpretability).
Moreover, if you change that setting along the way, you would need an automated script that goes through the vault and rewrites all the links so that they keep pointing where they were pointing before.

Perfect is the enemy of good. Personally, I would value fixing the broken new file feature above preserving the nested vault use case. But that’s because I do click links to create new files, while I think nested vaults are a bad idea (but that’s just my opinion).

2 Likes

Fixed this in Plugin: New Note Fixer

2 Likes