Folder structure for my daily notes

Help
1

Hi,

I’ve been Obsidian-aware for years, but have only just made the decision to start using it. Can somebody please tell me if I’m doing it right?

I’m starting out with Daily Notes. I’ve imported about ten years’ worth of daily journal entries and am going through the process of linking them (changing references like “tomorrow” or “next week” into links to other notes, that sort of thing). Each daily note has at least one embedded photograph.

I’ve more or less let Obsidian handle the files. All my Daily Notes are in a folder called “Journal” and all my photos and other attachments are in a sub-folder called “Attachments”.

Daily notes are titled “2024-02-12-Monday”, and attachments are titled similarly, “2024-02-12 - Daily Photo”.

I’m syncing all this between devices using the default iCloud folder. I don’t have any non-Apple needs.

One of the reasons I chose Obsidian over the alternatives (I’ve played around with them all) was because I wanted to end up with neatly formatted markdown files that could easily be transferred to another app, when that becomes necessary. I’ve wasted too much time, over the years, moving these notes between various proprietary systems.

Unfortunately, it all seems a bit unwieldy. My “Journal” folder and its “Attachments” folder each have in excess of 4000 files, making scrolling and finding entries onerous (especially on the iPhone). The mobile apps also seems to have slowed down.

Importing my Daily Notes is just the start of my plan. I hope to move all my writing to Obsidian but want to make sure I’m heading in the right direction before I mess things up.

So, does it sound like I’m taking the right approach? Any suggestions would be greatly appreciated. How many notes and attachments can Obsidian handle?

Steve.

2

On this point about the “Journal” folder full of notes, when I used daily notes (I use weekly now), I had a folder structure something like this:

.
├── 01 ...
├── 02 journal/
│   ├── 2022/
│   │   ├── 01/
│   │   │   ├── 2022-01-01
│   │   │   ├── 2022-01-02
│   │   │   └── ...
│   │   └── 02/
│   │       ├── 2022-02-01
│   │       ├── 2022-02-02
│   │       └── ...
│   ├── 2023
│   └── 2024
└── 03 ...

When using the Files tab, it makes things a bit easier to navigate, but I wouldn’t use the Files tab for scrolling through these. The Quick Switcher, Search, embedded search, Dataview queries, etc., are better IMO.

If you keep good backups, versioned if possible, you can always change around your vault structure without worrying about it.

3

Obsidian can handle far more files than that, but it will slow the startup time. Also iCloud may have its own ideas about what’s good.

Depending on your preferences, you could consider using a larger time unit like weeks (but obviously don’t do that if it will make working with them unpleasant).

4

It is good to have this organization in subfolders, because very big folders will be a factor for slow down at the operating system level. I thus support your idea to have subfolders, at least per year, or even per month.

If you set the “Date format” in the settings for the “Daily notes” core plugin to YYYY/MM/YYYY-MM-DD, new notes automatically will be stored under Daily notes (or a different name set in the “The file location” option of the core plug in) in folders per year and per month.

  • Apply that setting
  • Quit Obsidian
  • Manually organize your daily notes according to this structure in your Daily notes folder
  • On restarting Obsidian, these automatically will be picked up and recognized as daily folders. New daily notes will also be integrated into that structure.
2 Likes
5

Be very careful using iCloud for sync, you will lose files and data eventually. Make sure you have a good backup and a way to verify your data against the backup.

6

What I’m about to say has kind of already been said, and that is split up into folders. However, I just wanted to add that from the good old days ( a few decades ago :smiley: ) there was a rule of thumbs not to let any folder have more than a hundred (or so) files. Back then it was due to actual file system limitations, but nowadays I kind of adhere to this rule still due to what we’re capable of getting a quick overview of at a glance.

So for me it comes down to how many files/journal entries are you likely to generate? With 4000 files in 10 years, you’ve got 400 a year, and 3-4 for each month. Doing a year/month folder structure would then leave many folders with just those 3-4 notes. Maybe then it would be better to do a year/quarter variant, and have around 100 files in each. Or possibly skip a level and have year-month (or year-quarter) as the only level between Daily notes and your actual journal entries.

Regarding attachments, different people different wishes, but I’m not opposed to actually storing those attachments within the journal folder. Especially when the numbers are low, and the overall criteria related to number of files is somewhat kept (to your liking, that is).

Less folders are less hassle, as long as the number of files within each folders doesn’t cause a problem of its own. :smiley:

On a related side note, I’m in general not using localised names in my folders, due to the length mismatch in the folder structures. My preference is to use mostly numeric variants, both since they are easier to sort, but also since they have a uniform length. (In Norwegian the month names varies from “mai” to “desember” (similar to English) so the folder name length would vary a lot…) In a few occasions I’ve used the abbreviated variants in combination with the number, like the 3 letters month, which do have the advantage of keeping the names at the same length. Then a folder name could look like: 2024/02 feb, which would still sort correctly, but also add some letters to the mix to help identify the month.

Regarding the number of files Obsidian can handle, there’s been reports of those having vaults with several tens of thousands of notes (and even up in the hundred of thousands). So I don’t think 4000 should be any problem, and you’d still have some room to expands… :smiley:

PS: I’ve opted for changing your thread title to better convey what this thread actually is about.

7

Thanks so much for all the replies. They’re really helpful.

The consensus seems to be that:

  • Daily Notes are better structured in folders with smaller numbers of files.
  • iCloud is unreliable.

Just to politely push back a little:

  • Other than being visually cluttered, is there really a performance issue (on a modern device) with having thousands of files in one folder — either with macOS or Obsidian itself?
  • Is iCloud still sub-par, or is this apocryphal from experiences in its early days?

I’m just trying to get my head around the best approach. I prefer to use fewer folders, if possible, and I prefer the free sync solution, if possible.

Steve.

8

I think generally no, but maybe in some apps (and maybe more likely if in a cloud or synced folder of some kind, especially if it has a web view). I’ve raised my limit over time from 100 to 1,000 to 10,000. But it depends partly on what’s in the folder and how I’m likely to access it, and how often. Most of my folders are still under 100, and most of the rest still under 1,000. I think the only 10,000-file folders I use are my day job’s archives and my media collections.

9

I mostly agree with @CawlinTeffid here, but there is a little more work to be done for the operating and file system when needing to look through massive folders. But for most cases it’s not something you’ll as the end user will notice.

Like on Mac if the number of files in a directory is low, it’ll only need to check one inode. When it passes the first number threshold it needs to do a dual lookup, and the more files the more lookups. (This is heavily simplified! It uses btrees to store this information) But the actual maximum numbers of files in any given folder on Mac with hfs+ is around 2.1 billion files. I wouldn’t recommend that, though.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.