Once you’ve done the above, delete everything above this line.
Steps to reproduce
- Create a vault on C:\obsidian named “Identity” (we’ll reference this as vault1)
- Create a vault on D:\obsidian named “Identity” (we’ll reference this as vault2)
- Create a note in vault1
- Create a note in vault2
- drag and drop the note from vault1 to note in vault2 (to link the note in vault1 from note in vault2) Alternatively, copy obsidian URL and create the link in the note in vault2
Click the link in the note in vault2 and open vault1 and display the note.
Because the obsidian URL identifies the vault by name with no indication of path, it assumes that the link clicked in vault2 belongs in vault2 (because it’s the same name “Identity”) so it creates the note as new
- Debug info:
Obsidian version: v1.1.9
Installer version: v1.1.9
Operating system: Windows 10 Enterprise 10.0.22621
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: light
Community theme: Prism v3.2.0
Snippets enabled: 1
Restricted mode: off
Plugins installed: 3
Plugins enabled: 3
1: Icon Folder v1.6.0
2: Style Settings v0.4.12
3: Advanced URI v1.31.2
as seen above vault= has no indication of path (and you can’t put any in there) so there is no way to cross link vaults of the same name.
For example, if the “Copy Obsidian URL” copied vault=“C:\obsidian\Identity” as a folder rather than just a name, then the bug goes away. OR another option to “Copy Obsidian URL with path” so it adds a path= var on the query string.
Why is this an issue? This is the Use Case. I have multiple project folders with a defined set of subfolders in each project for consistency
The goal was to specify the Identity folder as an obsidian vault for the project. Normally, there wouldn’t be a lot of cross linking between projects, hence the folder isolation, but on occasion, I would like to make references. Especially helpful if a particular solution is useful across projects.
As an FYI, Advanced Obsidian URI plugin doesn’t solve the problem either.
So just to be clear, your bug report is only talking about Obsidian URLs right?
When you drag from vault to vault, you are creating an Obsidian URL link, not a Wikilink right? (just checking, because maybe the title can be edited to be more explicitly about URLs.)
Well, there is a clunky way. In the help docs, it says you can also use a vault ID number. Unfortunately, the only way to get it is by looking up
%appdata%/obsidian/obsidian.json and I guess you’d have to manually edit your links to use it.
But that is a known issue, and the docs say at some point, a more accessible way to access that vault ID will be provided.
My report is about the obsidian URL. I believe it would have to have the obsidian:// at the start to force it to open the program. And although it seems you can specify a path, no one wants to manually escape like
The simple answer, would be to always use the vault ID for “copy obsidian URL” This seems like a trivial solution since the vault= parameter already accepts both forms thus being backward compatible. It would also allow external links to remain intact if the vault is renamed.
On a broader solution, still using the ID as the default for an obsidian URL, I feel the vault name should be a meta parameter not tied to the file system. Adding a vaultname: element in the obsidian.json and/or in the .obsidian folder. On creation, sure use the directory name. But the “rename vault” option should NOT rename the folder. What if that folder is accessed by other applications? Using the name as the linking parameter is less resilient than the ID. I am sure I’m not the only one that layers an obsidian vault over a project tree for documentation, annotation, meeting notes, second-braining the project, etc. Further, this would allow one to differentiate the names in the UI, so one doesn’t have 4 windows open all named “Identity” with the only clear way to differentiate is to color code the theme.
As a side note, I noticed this was changed to a “feature request” it’s not. It’s a bug… specifically, edge case feature failure with obscure workaround.
cross linking vaults of same name fails with drag and drop or menu option without the use of an obscure workaround (ie. the ID from the unprettified json file and manual edit).
You need two paths…
- Create a folder “c:\test1\Identity”.
- Create a folder “c:\test2\Identity” or put it on a thumb drive to separate them.
- For each of them, “open folder as vault”.
- Create a note in one
- Create a note in the other.
- drag and drop the note from the first vault into the note of the second to create a link. Or “Copy obsidian URL” and create the link in the second.
- if you click the link in the second, it will create a NEW note in the second vault with the same name as in the first… it will not actual cross link the vault to the original note because vault=Identity in the URL is non-specific. The work around is use the Vault ID and then it’s specific.
as per the documentation in shorthand formats
this is a copy from one of my vaults
fails as it doesn’t find the vault. The full form path= works. file:// doesn’t work because it asks what application do you want to use to open the .md file of the note.
this “E:/PER_01/0010 - Hidden Name/01_01 - Identity” is vault root
thus the issue is I have multiple vaults named “01_01 - Identity”
At the end of the day, this workaround is not a solution. Where do you come up with the full escaped path? I had to drop it in URL escape/unescape (or encode/decode) online and then manually create the link. So the problem remains… drag and drop or the Copy obsidian URL doesn’t work between two vaults of the same name.
The devs use a narrow definition of “bug”. That can be frustrating, but it doesn’t mean they’ll never address the issue.
Highly disagreeing with that particular point.
As a much simpler workaround for the time being, that wouldn’t change some fundamental ways Obsidian works and confuse large amounts of users, why not consider using unique vault names? For example with a short alphanumeric project ID code in your naming conventions.
I’m definitely agreeing with your original request to be able to access non-unique vault names. But a few of your other suggestions seem to go against the grain of Obsidian’s design of simple access to a folder of Markdown files.
The accessible access to the vault ID is a known issue, as I said. That will likely get addressed. (I’m guessing, not speaking for the devs.) Or a user could find a way to make their own script or plugin to access it automatically.
Two vaults called
test stored in two places. Both have one file with the same name. This syntax opens the right file in the right vault each time:
[Link 1](<obsidian://open?path=/Users/eightning/Desktop/Test/This is on the desktop.md>)
[Link 2](<obsidian://open?path=/Users/Shared/Test/This is on the desktop.md>)
Not what is wanted?
The issue with renames are if “create vault from folder” and that folder is the top level of a folder tree, with that tree being a standardized folder layout for the user. For example, I have about 100 different project folders where 01_01 - Identity is the first one for a project collection. They are unique serial numbers by full path based on folder hierarchy: INT_03/0001 - Project Group/01_01 - Identity
The project serial is therefore 03.000101.01 which tells me if it’s internal or not, project group, project type and the auto-increment of that type in the event there is more than one Identity within a project group, it would be 01_02 for instance. Thus, making using unique vault names breaking the standards of the project structure. And since Obsidian doesn’t look at the whole path as being part of the name, just the tail of it, it’s not unique.
Further, since these folders are accessed various applications for various things, renaming the folder would break all of those connections. Even something as simple as items in applications “open recent” lists. Making the vault name meta data and not renaming the underlying folder doesn’t break the overall vision of Obsidian while not breaking anything that links.
the syntax you provide does not work… at least not on windows when you have a drive letter and spaces. You have to escape (urlencode) the string.
E:\INT_03\0001 - Project Group\01_01 - Identity\transfer\Test.md
E:/INT_03/0001 - Project Group/01_01 - Identity/transfer/Test.md
Then has to become:
And there is no simple way to do that.