In Obsidian there are the following options for ‘New Link Format’:
Shortest path when possible
Relative path to file
Absolute path in vault
I use ‘Absolute path in vault’ because I sync my notes using Git to a private Gitea instance (though it would be the same if I were using GitHub for example). I also view my notes in other apps sometimes.
Using this link option, I would typically get a link which looks like this:
[Note 1](L1folder/L2folder/note.md)
The problem is that I have to manually add a ‘/’ onto the beginning of the path every time to maintain compatibility with other apps. It would be great if I didn’t have to do that, but the main problem is actually if I decide to rename a note. In that case, Obsidian automatically updates all the references to it (great!) but it will strip this leading ‘/’ character and I would have to go through and amend everything again manually.
Proposed solution
It would be great if the absolute path included the starting ‘/’ to show that that was the beginning of the path. This would need to take effect both when generating the link for the first time and also when updating the links after a note rename/move.
Current workaround
Manually adding the ‘/’ when creating links
When renaming or moving notes, I have to find all automatically updated references using Git and then add the ‘/’ manually
Related feature requests
I only found one related post on the forum so far about this and there had been no response:
this is unlikely to happen since it will break the nested vault workflow. A leading / also generally means “from the root of the filesystem” not “from the root of the vault”. I am not sure how that would help with compatibility.
It is likely that ./ will be added in relative path mode.
Nested vaults are not something I use myself so I’m not too familiar with how they work, but if my request would cause an issue with another workflow then it could always be done as a setting so hopefully then everyone is happy
Maybe the existing setting could be extended with another option which includes the leading ‘/’, or an extra field could be added allowing an optional/user-defined leading character (or characters, then the same setting could also be used for the ‘./’ you mentioned for relative paths).
I encountered this problem. The ./ is necessary for markdown links to work correctly with VuePress. Obsidian Apply Patterns plugin helps me to solve this issue in the current Obsidian functionality.
Find (\]\()(\w) and replace to $1./$2
The absolute links format is not really considered absolute by other tools, such as when displaying notes backed up on GitHub in browser. If I have vault-root folder _media and link such as [](_media/cat.png) inside a pets/cat.md note, GitHub will resolve the image path as pets/_media/cat.png.
While I understand handling this may be left up to implementation, a truly absolute link, one beginning with / (i.e. [](/_media/cat.png)) seems to work in both Obsidian and GitHub. The problem is that there’s no option for Obsidian to automatically place starting / in the link, making this manual effort and error prone.
Proposed solution
An option to start absolute links with /.
Current workaround (optional)
I’ve tried to put /_media in “Attachment folder path” option to at least handle pasted images, but the / gets trimmed so there doesn’t seem to be any workaround.
Agreed that a clean way to indicate “relative to vault root” vs. “relative to local folder” is needed. The absolute path specification works if the application has an awareness of a “domain root” (Vault root in Obsidian, repo root in Github). But becomes problematic when opening the file in filesystem-centric applications – e.g., Vim or some other text editor. Here, the current convention works if the editor or other application working directory is set to the vault/project root, but of course breaks with the leading “/”, as this is now interpreted as the filesystem root. It would be nice if there was a convention that worked across both contexts, but that might be too complicated
Related: maybe relative paths should automatically (or linted to) start with “./_media/cat.png” as well to minimize ambiguity between local/relative and absolute paths in both Obsidian and non-Obsidian contexts?
The reason why this is not added is to support nested vaults and it’s not universally clear if it’s / means the root of vault or the root of the filesyste
I wasn’t aware of nested-vaults being a thing, so read up quickly on them and I don’t understand the relation between them and leading /.
The only case I can imagine this being relevant is when creating link in note in sub-vault, and then opening that note in the primary vault. But:
Does that even work as of today? Will Obsidian consider the origin of the link to be in the sub-vault when note is opened from primary vault?
Aren’t such sub-vault links then actually relative to the sub-vault? Why call them absolute?
In any case, the ask was to make it an option - that could come with a note to not turn it on for nested vaults. But I don’t see why one use-case should block another.
I agree with BetaRavener. I would really need this option to make Obsidian work seemlessly with Vimwiki.
It already works 98%. That would make it awesomely compatible 100%.
this is unlikely to happen since it will break the nested vault workflow.
Adding the option to prepend the absolute path with / and turning it off by default would make it compatible with nested vault users.
A leading / also generally means “from the root of the filesystem” not “from the root of the vault”. I am not sure how that would help with compatibility.
Many project-based tools, for example, VSCode’s markdown processor and GitHub, accept leading / as project root, not filesystem root. Also, every tool I’ve used regards the path without leading / as relative. In that sense, Obsidian is the one that is not compatible.
This feature would be great since moving files with leading / backlinks is very tedious in the current state.
As mentioned before, most programs will have a dedicated interpretation of where the root should be and Obsidian seems to be the odd one out.
Surprisingly the current implementation seems to try and resolve the path relative to each of the parent folders. (E.g. a note /Vault/Parent/Sub1/Test with a link Sub2/Test seems to be able to find another note in /Vault/Parent/Sub2/Test). I wonder if this should be desired behavior, because it could cause wrongly resolved files in some cases. Regardless, this implementation should be achievable if links did start with /? It’s only a prefix after all
But a toggleable option (maybe enabled by default for new users) would be a perfect solution.
I tried to read up on Nested Vaults and it doesn’t seem to be an officially supported feature. It makes me wonder why we should be protective of an unsupported feature while a real one is broken. (Also since the Obsidian home page promises to not use a proprietary format?)
Also note that the current implementation already seems to be able to resolve links starting with / relative to vault root, but it does not support this kind of “sibling search” I talked about in the second paragraph.
+1 for this. VScode and GitHub would be compatible with the “leading” slash idea and there is no harm done when it’s added as an option that defaults to off.
Amongst other things, I use Obsidian to draft blog posts - if I forget to prepend a / (or rename a file, causing Obsidian to rewrite stuff I’d already updated) the images won’t display on the web (because browsers consider them relative).
Same with Jekyll: I’m considering editing my Jekyll blog posts directly in Obsidian, for Markdown preview and ability to rename images and sync their paths in all .md using them (still looking for a plugin that sync attachment file names in VS Code…). But as soon as I rename a picture it updates it whole path and that would remove the initial slash expected by Jekyll.
I agree that in general you’d expect slash to mean file system root, but some note “this is for advanced users who need compatibility with other note apps and website deployment” should be enough.
