Yes, I would like to second this - even linking to a local file anywhere on the local drive with the possibility to open that link within Obsidian / with the default app would be fantastic.
Edit: also - opening local folders with the OS explorer.
Okay, I’ve since realised that both of those actually already work, which is neat. 
The more I use Obsidian, the more I want to manage my notes exclusively in Obsidian. These notes are related to documents and other resources. I could link to those documents from Obsidian notes, but any links I add are device-specific. Those links also break if I move the file or rename it. Better to manage those files through Obsidian itself where any file moves or changes will propagate throughout my library of related notes.
Somewhat out of scope for this feature request: If every non-markdown file had a corresponding markdown file, users could add descriptions, metadata, and associations with/links to other files. That may also ease implementation somewhat, as Obsidian would be managing files it understands (the MD files) and so has more leeway to manage the “unsupported” attachments in a more controlled way.
I really like this idea, and I’ve started implementing it in my vault. I also reference it here https://forum.obsidian.md/t/integrating-microsoft-onedrive-office-365-files-into-obsidian/3550.
I don’t see a benefit in having the actual non-markdown files in my vault. I want to keep my vault size small for easy backup and sync.
Sam, how do you then handle image files that you need for your Obs notes? The way I understand it, Obs can only access images in a folder within a vault.
Yes, that’s one limitation right now. I don’t use a lot of images in my notes, but I do have a few in my vault. I also have some images publicly hosted through my OneDrive account.
Related: https://forum.obsidian.md/t/allow-embed-of-local-images-using-file/1990
New Obsidian user here. I decided to finally organise my notes and Obsidian seems ideal! I’d be happy to pay even for the personal version. Unfortunately, I cannot figure out how to make arbitrary files in the vault linkable from the md docs in the vault.
The whole vault will be synced using Unison or SyncThing to other machines, so I need a way to do relative paths, to make the links work on any machine irrespective of the location of the vault. The [link name](file:///…) approach works but works with absolute paths, so it is tied to a single machine, almost completely negating the advantage of Obsidian operating over a regular folder.
I registered a handler to open ad-hoc URLs of the form zk://relative/path/to/file on one of my machines as a temporary solution, but I don’t want to have to do this on every machine.
Obsidian vaults are likely to be synced to other machines, so in my opinion all links should be relative, not absolute.
If there is a better solution to this use case, I’d be grateful.
Other than that, fantastic work!
What do you mean by arbitrary files? Non-markdown files?
Yes. Files with arbitrary extension not necessarily recognised by Obsidian. .mhtml, .zip, .hpp, .lyx …
Okay, similar to this request https://forum.obsidian.md/t/show-non-md-files-in-obsidian-file-explorer/1948
Just to be sure, what I have in mind is supporting the local file links as supported by Typora: https://support.typora.io/Links/ , section " Link to Local Files". Specifically, support for relative links of the form [label](relative/path/to/something.weird_filetype) would be fantastic.
For now, I’ll probably use the “open with default app” functionality to quickly open any .md file in Typora, and then navigate the relative link from there.
The only problem with this approach is that Obsidian will interpret such link as a link with not-yet-created-target, and will attempt to create it (which, depending on the path, may succeed or fail with a “ENOENT: no such file or directory” error).
I think the shorthand form [[link]] doesn’t have to support arbitrary file links, only the longer form [label](path) should.
Ah okay, this wasn’t clear from your original post. You might want to add the Typora reference in your original request. This does seem useful.
It seems to work the same in several editors, it is not Typora-specific.
We’re in the same boat. I’m evaluating Obsidian for use within our small Data/Analytics shop. We are looking for a tool to document the many data requests we receive from the dozens of departments in our org. Internally linking the documentation will be a huge win for us. However, we absolutely have the need to link to non markup documents and have them open in system default programs. Ex. if we link to a .xlsx file, it will open in Excel, or whatever the local system uses to open files of that type. We will be linking .sql, .xlsx, .txt, .docx, etc. I believe I can achieve this by [text link](absolute file path), but can’t make it work for a relative path. As we’re all currently using a network share, we can make it work, but if we ever have to move it, it will be a pain, as all of the links will break and have to be modified. I believe having the ability to use relative file paths (with the vault as the root) would solve this issue. Other than this one item, I’m loving the platform and hoping I can lobby for team wide adoption.
A temporary solution:
{
"[markdown]": {
"editor.quickSuggestions": true,
"editor.wordBasedSuggestions": false,
},
"vscodeMarkdownNotes.noteCompletionConvention": "noExtension",
"vscodeMarkdownNotes.workspaceFilenameConvention": "uniqueFilenames",
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
"path-autocomplete.triggerOutsideStrings": true
}
Then, if the need to work with external links arises, I use the “open in default app” command to open the .md file in the already running VS Code (if we hadn’t opened the vault directory in advance, VS Code wouldn’t open the file in the context of the vault directory, and suggestions would not work correctly or at all).
I use standard md local relative links: [blah blah](./local/relative/link). The “path autocomplete” VS Code extension kicks in as soon as I type “./” . To follow any such local link, do a comand-click on the link (in VS Code). It opens it in VS Code. If you don’t like that, do a right click on the tab with the newly opened file, and choose “open in application” (which is available thanks to the corresponding extension). So it is three clicks to open the file instead of one.
The autosave feature ensures that all changes are almost immediately visible in Obsidian, too.
Aften much hesitation, I decided to keep all external stuff next to the Obsidian vault, not in the vault. I then use paths of the form ../path/to/some/external/resource.xlsx to access the external stuff. If I move the vault and its “sibling” directories together, links don’t break. (If you use folders in the vault, the the links would look like ../../path/to/resource etc.)
Alternatively, you can invent your own URI scheme and write and install a very minimal custom URI handler into each of your systems. I successfully used a scheme of the form pavelbazant://path/relative/to/vault/root 
. This works directly in Obsidian, but you don’t get the benefit of autocompletion and the approach feels rather non-standard and somewhat intrusive.
I’d like to add that recognizing relative paths could also support image formatting. For example:
<img src="../path/to/image.png" alt="My Image" style="zoom:50%;" />
This is also very relevant here: Microsoft is working on a broader, more unified API for Office 365.
And can now already be perfectly integrated into Obsidian by using iframes as @sam.baron rightly mentioned some time ago.
I experimented with the concepts and it works great. If I wanted I would be able to manage office documents right from inside Obsidian.
+1 from my side. I often need to link/attach other files (mainly office), so that would be really nice to have
There are a lot of exciting things happening with Microsoft 365 development. I think ultimately there will be two solutions to this problem (not including iframes, which I think of as a workaround).
+1 I created a spreadsheet and made a link to it and was hoping it would open up in my default app, Excel. I could see plenty of other times in the future where I may want to link to local files that contain information not in Markdown.