Better Directory Management

[ggs]

Use case or problem

It’s good to have the folder exclusion option that we already have. However, a subfolder of my media vault contains an enormous number of non-markdown files. I would’ve hoped obsidian could ignore this directory entirely, but Obsidian is still trying to index all of those files. The graph view takes much longer to fully initialize, and it introduces a lot of overhead for plugins that query non-markdown files.

Proposed solution

---

At minimum

We really need a stronger exclusion option that utterly bars obsidian from even bothering from ever using a directory, not just making it less noticeable.

Really, we need…

…to have a full tree UI in the settings for managing directory specific settings. Generally someone would develop a plugin for that sort of thing. But, considering there are multiple built-in uses, I think it’s something that should be considered a base feature of Obsidian, where plugins could add their own directory options.

Why would it make sense as a base feature? We’ve got:

• Standard exclusion: excluded files hidden in Search, Graph, and Unlinked mentions, downranked in switcher and suggestions
• Sync exclusion
• Publish exclusion
• Complete exclusion from obsidian: not visible anywhere, save for explicit file:/// links

This would unify and improve existing settings.

Features, and problems they solve

A drawback of the current UI is that if I have a directory with 1 subdirectory, which I want included, I’ll have to exclude every other subdirectory except that one. A directory settings tree would allow inverting the settings for a directory, so users could select one directory, and invert.

A while back I made this request:

Sync Types

Use case or problem I recently started using Obsidian on another machine. I wanted all my plugins and settings on the new machine. On my main machine I turned on plugin syncing. Weeks later I found out that doing that ended up syncing old plugin data (from a previous sync before I disabled plugin syncing) to my main machine rather than treating all the current data as new and pushing that (luckily I also keep it updated on a git repo). I believe this happened because I enabled the plugin sync o…

And among a few other related issues, @EleanorKonik made this request:

Publish: Permanently Exclude Folders

Use case or problem I like to share my notes with people as an example of a working vault, but I have to do a lot of scrolling past my “definitely not ever going to make this public” folders every time I do an update, and I live in terror of accidentally clicking the “check all” button when I meant to check the “collapse” button and not really noticing and accidentally publishing my tax record pdfs and stuff. Proposed solution Let me (quasi-permanently, hide it in a setting somewhere or somet…

These are two examples of settings that could easily be managed in a directory settings tree. There could be a dropdown to select the context (general, sync, publish) to show the associated settings. The Sync type (mirror, update, two-way, ignore) could be set by cycling through a multi-toggle. The app FreeFileSync is a good example:

A similar UI with varying options could be used for each context, cycling through visible, hidden, and excluded.

One of the best features in my opinion would be providing a unified file-ignoring interface for plugins. Switching the context to a plugin would allow managing plugin specific directories, and the Obsidian devs could expose an API call or two (maybe getVisibleFiles() and getHiddenFiles(), or simply adding a parameter to getFiles() which defaults to Visible files). That would alleviate a common issue among plugins, which is not having any way to ignore files. And it prevents the extra complexity of each and every plugin that does, having a different method for doing it.

Current workaround (optional)

Currently, you can add a ‘.’ to the start of the directory name. This solves the main issue for which I’ve created this request.

But, I think users aren’t likely to know that this exists, and it also forced a lot of changes for me personally as everything in my system referencing that directory had to change. And that was just the most recent and egregious offense. I now realize I have a number of other subdirectories that total a few thousand files which I’d like ignored, to speed up obsidian a bit more. But it would be too tedious to change all of them.

[ryanjamurphy]

Note that Settings → Files and Links → Excluded files accepts a regular expression, so you can use e.g., /(.pdf)/ to exclude all files with the string “.pdf” in the filename (excluding PDF-format files).

This might help with the media files!

[ggs]

Well, like I said above, Obsidian still tries to index them since they aren’t ignored completely. The performance hit is the big issue, and Obsidian only truly ignores directories starting with ‘.’ which requires a bunch of changes.

[Iv3llios]

Hey! I have been dealing with the same issue for the last two years, and am straight up desperate for this kind of solution. As of now obsidian takes multiple minutes to open on my end. I am aware that I could simply move folders in such a way that they were not part of my obsidian vault, but that would result in it creating a mess in my organisational structure simply to keep Obsidian smooth and running.

I beg the devs please address this somehow. Something as simple as a proper exclusion list (bare minimum solution listed in the OG post) would already be life-changing!

[WhiteNoise]

Duplicate of:

Ignore/exclude completely files or a folder from all obsidian indexers and parsers

“Excluded files” option doesn’t quite work for me as the most annoying features of having an unwillingly indexed folder for me are not excluded from parsers Use case or problem Im currently hosting my obsidian vault in Mega, Mega currently uses a folder called “Rubbish” for local cache, hosted, in this case, inside the vault. The rubbish folder i cannot deactivate in any way nor rename it to “.rubbish” (for obsidian to ignore it) as the service just creates a “rubbish” folder again Problem is…