Allow Obsidian URI to support vaults at different paths with the same name

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
obsidian:///absolute/path/to/my note

this is a copy from one of my vaults
‘obsidian:///E%3A%5CPER_01%5C0010%20-%20Hidden%20Name%5C01_01%20-%20Identity%5Cdocuments%5CLRN%5COn%20Line%20Tools%20For%20Teaching.md’

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.

2 Likes

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.

So this:
E:\INT_03\0001 - Project Group\01_01 - Identity\transfer\Test.md
First becomes:
E:/INT_03/0001 - Project Group/01_01 - Identity/transfer/Test.md
Then has to become:
obsidian://open?path=E%3A%2FINT_03%2F0001%20-%20Project%20Group%2F01_01%20-%20Identity%2Ftransfer%2Ftransfer%2FTest)
And there is no simple way to do that.

Just an exploratory thought. I’ve been experimenting with @czottmann’s obsidian-actions-uri plugin and he appears to have a strong grasp on this subject matter. Does his plugin support full-paths to Vaults (from the docs, it just says Vault name.) and if not, is this something that could be implemented in his code? I hope this helps, as I also have an interest in the same.

Hi there! :wave:t3:

Does his plugin support full-paths to Vaults (from the docs, it just says Vault name .) and if not, is this something that could be implemented in his code?

It does not, and it can not. The reason for this is that all plugins are running in the context of the particular vault. When you call obsidian://…?vault=XYZ in order to work with a plugin, Obsidian will use the vault parameter to look up the vault in its list of known vaults, and if found, that vault will be opened and initialized (if it wasn’t already), at which point the called plugin takes over.

Once running, the plugin is able to get the full filesystem path from the vault environment but I doubt you can access any other vault from there, at least not in a clean/sane way.

HTH!

1 Like

I’m not sure if this helps, but you could use it as a workaround:

I just remembered that the URI scheme allows for opening arbitrary paths, independent of vault name etc.

So it appears you could open vaults with the same name but different filesystem locations after all.

  • obsidian://open?path=%2Flink%2Fone%2FSupervault
  • obsidian://open?path=%2Flink%2Fanother%2FSupervault

/㏄ @gapmiss

1 Like

That works IFF both vaults have been previously open.

I ironically just wrote a little bit about this limitation in another post (see below). In that post is a guide that goes over that and a few other Obsidian URI limitations.

1 Like

So the workaround I came up with is a change to the underlying file structure… basically creating the “alias” system for the vault that I suggest above but outside of Obsidian.

  1. create a folder, anywhere, and name it whatever you like… let’s call it “Obs-Projects”
  2. In the Obs-Projects folder, create junction points to all the folders you want as vaults. In unix I believe these would be hard links. These junction points can be named anything while the underlying folders they point to can all be the same name (which if pointed to by Obsidian directly would break). Obsidian will recognize the junction point as the vault name. Thus, things like “rename vault” doesn’t actually change your file structure only the name of the junction point.
  3. Once the junction points are created, then go to Obsidian and open the individual junction points as vaults.

You’ll now have uniquely named vaults while your folder structure of your projects remains unchanged. This will also work for drag-drop creation of obsidian links, because the vault names (being the junction points) are unique. This does not seem to work with symlinks. Soft links don’t fool obsidian. To create the junction points in windows, I use:

https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

This is an obscure workaround for missing functionality in Obsidian. It does not actually solve the problems:

  1. referencing vaults by full and complete path names.
  2. have a simple way to obtain the vault ID so vaults do not need unique physical names.
  3. if we have to get paths and links, have a way to escape them as URL encoded so manually creating such links (or using a 3rd party tool) is not needed
  4. have a layer of abstraction. Since the vault has an ID, then the path NAME it references should be irrelevant. That said, add vault name field in the config so the vault name is abstracted from the path. This allows other applications (and other obsidian vaults) and integrations external to Obsidian reference the file tree without worry that it will be renamed (or needing the junction point abstraction as above).

As a side note, I use this junction point functionality to share a templates folder easily among multiple vaults. Create the templates folder in Obs-Projects (example above) and put the junction point as “templates” in the folder tree for the vault.

I would not encourage using hardlinks… that’s a bad idea.

@smartguy Unfortunately, no one has provided another workable solution to the problem of multiple vaults with the same name. So, saying it’s a bad idea without any reasoning or alternative solution to the problem is unconvincing.

I mean there is one: avoid hardlinks and use the vaultid (stored in Obsidian’s cache)

If there’s no vaultid for your vault, you can inject one

@smartguy, I am aware of the IDs, but this isn’t a solution since drag and drop between vaults doesn’t use the ID, copy Obsidian URL doesn’t use the ID, and if you try to use the obsidian://vault/other_vault/note manually with the ID, you have to escape the path to the note in windows and there’s no good way to do it. So, yes, IDs are a solution but not a practical or productive one. So hardlinks offer an abstraction allowing all of these to work in Obsidian, and even removes the risk of executing a “rename vault” on a folder tree that might be used by other applications. What is the argument against the use of hardlinks?

I mean here’s just the start of why its bad:

1 Like

Here’s another: filesystems - Why are hard links to directories not allowed in UNIX/Linux? - Unix & Linux Stack Exchange

1 Like

The other issue with hardlinks is that they are a security risk.

By default hard links provode no read or write protection by default. This is called an unprotected hard link. Here’s an example of this security issue in WSL:

I can keep going…

1 Like

@smartguy - so, after reading through those links, the answer is don’t be an idiot when using hardlinks. Don’t make loops. Don’t do something with security perms that could get munged. And maybe obsidian on unix will play nice with soft links, I haven’t tested it. Really, the answer still comes down to solving the underlying obsidian limitations referencing vaults listed above.

1 Like