EPERM opening Vault when any part of the tree is inaccessible

Steps to reproduce

  1. Create a file/directory in a vault
  2. Restrict access to the file in some way, i.e. change its ownership or lock the file
  3. Try to open the vault

Did you follow the troubleshooting guide?

Y, and you can repro in a Sandbox by creating the test file/dir in advance and denying the current user write access to it.

Expected result

Inaccessible files will be ignored

Actual result

Obsidian refuses to open the vault at all

Environment

SYSTEM INFO:
Obsidian version: v1.4.5
Installer version: v1.4.5
Operating system: Windows 10 Home 10.0.19045
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none


Additional information

This is the same issue that prevents Windows users from opening our Documents directory as a vault. Ignoring inaccessible paths in general will fix this problem.

More critically, this issue makes it undesirable to comingle Vaults and code, particularly because building and debugging frequently involves locking files for long periods. One of my favorite uses for Obsidian is to pop it open on the side for doc writing while I code, and I run into this for various reasons quite regularly.

I’m sure there are other ways to run into this issue. Some things I’ve done in the past that do/probably break a vault:
Use git-gui, which doesn’t always free locks (at least on Windows) when it should.
Run other types of filesystem watchers, which are often lock-hungry beasts.
0700 a directory in a multiuser environment to hide a mess.
Mix NTFS and Unix permission schemes in the same directory tree.
Symlink or Junction to root-only directories (like a systemwide keystore).
Anger Windows in some odd way that creates a mysterious undeletable file.

I don’t consider this a bug. You can search/open a FR for this.

Your software errors out in situations that don’t concern it. Surely, that is a bug, especially when so many of your users have raised the issue over the years.