CSS snippets fails to load with faulty symlink in folder

I’m not sure if this happens on other platforms, but the procedure below triggers the fault on MacOs 10.15.7 at least.

Steps to reproduce

  • Open Sandbox Vault, and go to Settings > Appearance > CSS Snippets
  • Use the folder icon to open the snippets folder
  • Create a file like working.css (doesn’t need any contents, so I did touch working.css )
  • If you now refresh the snippets, it’ll show the working.css
  • Open a terminal window in the snippets folder and create a non-existing symlink, i.e. ln -s /foo/bar
  • Go back to Obsidian, and do a refresh of the snippets, you’ll still see the working.css, and if you’ve got the Developer tools open you’ll get an error message on “no such file or directory”
  • But here’s the real kicker: Do a Force reload, and go back to the CSS snippets setting, and no nothing is displayed anymore. The working.css has disappeared and nothing is shown at all

Expected result

All of the above was executed in the Sandbox vault, and I expected that even though the symlink don’t exist it should show all the other snippets and apply them as usual.

Actual result

No snippets was recognised, nor applied (if doing a fuller example), and the error message on “no such file or directory” had appeared. Obsidian was still able to open up the snippets folder as usual.


Obsidian version: v1.5.8
Installer version: v1.5.3
Operating system: Darwin Kernel Version 19.6.0: Tue Jun 21 21:18:39 PDT 2022; root:xnu-6153.141.66~1/RELEASE_X86_64 19.6.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on


Additional information

The reason why I happened to be in this situation is through operating system upgrades, and copying/moving folders from their original location into a better and cleaner structure. It could be solved by fixing the symlink, but I wanted to report it so as you’re aware that the file scanning of the snippets folder is not very robust, and can be easily broken by a little bit of bad luck and a faulty symlink.

This faulty symlink seems to also to expand into other areas related to at least the theme settings, and possibly also some of the plugins. The issue in the post below was fixed when removing the faulty symlink, and Force reload’ing the vault, and then also another plugin, Custom File Explorer sorting, kicked back into action.

ok thanks