ObsidianOpen opens file as if vault directory is the MacOS root directory if vault dir is behind symbolic link

[shakesbeare]

🐛 Describe the bug

If obsidian vault is configured to use a directory behind a symlink, using :ObsidianOpen while in a note which already exists opens a blank file from the vault directory as if it the vault directory were the root of the entire file tree.

Example:
File: /path/to/vault/Notes/my_note.md
Obsidian Opens: /path/to/vault/path/to/vault/again/Notes/my_note.md

For completeness, here is a real example using my own paths:
File: /Users/username/Library/CloudStorage/Dropbox/Documents/0-obsidian-notes/MUS-490 Landing Page.md
Obsidian Opens: /Users/username/Library/CloudStorage/Dropbox/Documents/0-obsidian-notes/Users/my-name/Library/CloudStorage/Dropbox/Documents/0-obsidian-notes/MUS-490 Landing Page.md

Note that this error occurs regardless of if the note is in a subdirectory of the vault or note.

Working config:

require('obsidian').setup {
    dir = "/Users/username/Library/CloudStorage/Dropbox/Documents/0-obsidian-notes",
    notes_subdir = "Notes",
    use_advanced_uri = true,
    completion = {
        nvim_cmp = true,
    },
    templates = {
        subdir = "0-templates"
    }
}

Bad config:

require('obsidian').setup {
    dir = "~/Dropbox/Documents/0-obsidian-notes",
    notes_subdir = "Notes",
    use_advanced_uri = true,
    completion = {
        nvim_cmp = true,
    },
    templates = {
        subdir = "0-templates"
    }
}

For what it's worth, it seems to work completely properly as long as I removed the link dir from my config and instead used the absolute dir, but this is absolutely not expected behavior so I figured it's worth documenting at the very least. I can't say for sure whether this happens on other operating systems.

Seems I also have some error in some kind of python-related thing going on that I just discovered as I was writing this up. Doesn't seem related, but I also don't know what to do about it. Happy to mess with it if you think it's relevant. I haven't noticed any other odd behavior besides in any of my nvim experience besides #106. I did go through and test to see if that issue is still present with the alternate config and it indeed is.

Versions

NVIM v0.9.0-dev-1265+g410dc3349
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /Applications/Xcode_13.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wvla -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -fdiagnostics-color=always -fstack-protector-strong -DUNIT_TESTING -DINCLUDE_GENERATED_DECLARATIONS -I/Users/runner/work/neovim/neovim/.deps/usr/include/luajit-2.1 -I/Library/Frameworks/Mono.framework/Headers -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Users/runner/work/neovim/neovim/build/src/nvim/auto -I/Users/runner/work/neovim/neovim/build/include -I/Users/runner/work/neovim/neovim/build/cmake.config -I/Users/runner/work/neovim/neovim/src -I/Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Users/runner/work/neovim/neovim/.deps/usr/include

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Run :checkhealth for more info

1.8.0
Error detected while processing command line..VimLeave Autocommands for "*"..function remote#define#AutocmdBootstrap[7]..VimLeave Autocommands for "*"..function remote#define#request:
line    2:
Error invoking '/Users/username/.vim/plugged/semshi/rplugin/python3/semshi:autocmd:VimLeave:*' on channel 3 (python3-rplugin-host):
no request handler registered for "/Users/username/.vim/plugged/semshi/rplugin/python3/semshi:autocmd:VimLeave:*"

[epwalsh]

Hey @shakesbeare,

If you get a chance to debug before I do, I suspect the issue might be in this function:

obsidian.nvim/lua/obsidian/init.lua

Lines 128 to 141 in 5f48a8b

	client.vault = function(self)
	local vault_indicator_folder = ".obsidian"
	local dirs = self.dir:parents()
	table.insert(dirs, 0, self.dir:absolute())
	for _, dir in pairs(dirs) do
	---@type Path
	---@diagnostic disable-next-line: assign-type-mismatch
	local maybe_vault = Path:new(dir) / vault_indicator_folder
	if maybe_vault:is_dir() then
	return dir
	end
	end
	return nil
	end

[shakesbeare]

@epwalsh

I did some digging and I think you're right that this is the origin of the bug. The link is not being expanded into it's absolute version there, which is causing issues further down the pipeline here:

obsidian.nvim/lua/obsidian/command.lua

Line 107 in 4bc10b8

path = Path:new(bufname):make_relative(vault)

because you naturally can't make a relative version of the path from the vault when the path doesn't look like a subdirectory of the vault directory.

At my best guess, it seems like it's an issue on Plenary's end. A brief glance at their open issues reveals that following links might not be implemented for them across the board.

Do you want to try and hack together a solution or just document and wait for plenary to fix it?

[epwalsh]

@shakesbeare if you have an idea for a workaround I'd be happy to accept a PR