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
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.
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.
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.
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.
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.
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.
create a folder, anywhere, and name it whatever you like… let’s call it “Obs-Projects”
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.
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:
This is an obscure workaround for missing functionality in Obsidian. It does not actually solve the problems:
referencing vaults by full and complete path names.
have a simple way to obtain the vault ID so vaults do not need unique physical names.
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
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.
@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.
@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?
@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.