Daily notes command doesn't work right when there's a "Folder path to create new notes in"

Steps to reproduce

  1. Configure the daily note date format to “YYYY/MM/YYYY-MM-DD \C\A\L\L”, and no parent folder, but set a “Folder path to create new notes in” of “Inbox”
  2. Create a 2021/01 folder in the vault root, and an Inbox folder. Create a note “2021/01/2021-01-14 CALL”, and close it.
  3. Invoke the “open today’s note” command.

Expected result

Today’s note should open.

Actual result

Nothing happens. Checking the developer console, the following error appears:

Uncaught (in promise) Error: ENOENT: no such file or directory,
open 'E:\Daybook\Inbox\2021\01\2021-01-14 CALL.md'

In this case “Inbox” is the “Folder path to create new notes in”, which should not be being prefixed to the daily notes path. I tried changing the daily notes format to use an absolute path (i.e. prefixing it with /), and got a different error:

Uncaught (in promise) Error: File already exists.

The only way to stop the prefixing appears to be to turn off the “create new notes” path.


  • Operating system: Windows
  • Obsidian version: 0.10.7

Additional information

What appears to be happening in the second case (/-prefixed date format) is that the daily notes plugin is now not recognizing the file doesn’t exist (after checking under Inbox), then tries to create it at the correct path, which then fails because it already exists. The approach it uses to check for the file’s existence seems to be based on non-/ prefixed paths (the cache doesn’t normalize paths on checking for existence).

The workaround for this seems to be to empty the setting for “Folder path to create new notes in”.

Earlier versions of Obsidian handled this configuration fine (as long as the note’s parent folder existed), but I think this might actually have stopped working as of 0.10.6. I’m not positive when it stopped because I use the Calendar plugin (which has no problem with this filename format). I’m fairly sure that one of the 0.10.x series quit creating the daily notes if they didn’t exist, but earlier Obsidians did create them, and I’m pretty sure Obsidian was opening for most of this year. So I would guess that opening them broke as a result of a bug fix to something else, perhaps in 0.10.7.

While investigating this problem, I also discovered that Obsidian has previous and next daily note commands… which I never knew existed before because they don’t work with my date format. :wink: Apprently the iterateDailyNotes() method compares the basename of the file against the full format string, instead of e.g. taking the basename of both, and then regenerating the target path from the parsed date and seeing if it’s a suffix of the full path.)

The format string I’m using, by the way, is not one I reallly want to change at the moment, as I have many years of pre-Obsidian notes in this organization. It seems the Calendar plugin has no problems because it doesn’t ever try to parse file names, it just generates them from a set of dates.

One possible way to improve the detection/iteration behavior (besides taking the basename of the format and checking the suffix), would be to convert the format string + base folder to a regular expression, saved with the plugin settings. It then would be very fast to find/iterate daily notes by testing them with a regex before attempting date parsing, and it’d make having a daily notes search option practical.

But just using the basename of the format string would certainly work for my format, or better yet, just don’t take basename of either part, just remove the notes folder prefix from the file’s full path. That would also avoid problems when people have a date format that doesn’t include the full date in the basename, as I do.

Have you tried putting a / in Daily Notes plugins -> new file location. Works for me.

Thanks for the workaround!

ISTM though that if the intent is for that location to be otherwise relative to the “create notes in” folder, then the suggestions for that setting are broken, as they are not relative to the create-notes folder. It seems to me that if you want it to be relative to that folder it should be an explicit selection of “NewNotes/Whatever” rather than just “Whatever”, with the NewNotes being implicitly added. It’ll be especially confusing if you change your create-notes-in folder and suddenly daily notes start appearing in a different directory. :wink:

The workaround also doesn’t address the previous/next day’s note nav commands; should I file a separate bug report for that?

I don’t see this as workarond. This is the solution.
We have new file location field, you put the directory there and it creates the new daily notes there.
If you leave that filed blank, it uses the general folder to create new notes in.

Maybe we should defult to new file location / instead of leaving it blank.

Fot the prev/next day changes, open a feature request.

Certainly defaulting to a “/” would help.

But there’s a problem with the logic of including the new note location as a prefix: the suggestions that are given when you set the daily notes folder are wrong.

The suggestions that are shown aren’t subfolders of the new note location, so if you put anything in the field that Obsidian suggests, you’re going to be trying to create daily notes in a folder that doesn’t exist.

And even if you fix the UI so that it only suggests subfolders of the new notes location, it will still silently break if somebody changes their new notes location, and doesn’t immediately change their daily notes location to match.

In short, even if you consider the field’s semantics to be correct, its UX is not, because the suggestions are wrong and the UI does not link the two settings.

And the only way I can see to fix that without changing the field’s semantics would be to prefix all of the suggestions with “/”… but that seems like basically the same thing as changing the semantics to not prefix the daily notes folder with the new notes location.

I just don’t see the problem. It seems all right to me.

When are they wrong? show me an example?

Is your point that in your current syntax looks like this: we should show the full pathname?

I think perhaps I misunderstood something you were saying about how this works.

The mental model I had was, "Daily notes adds the path in the “New file location” to the path in “Folder to create notes in”.

But if I understand correctly (now), the actual model is "Daily notes defaults to “Folder to create notes in”, unless you override it by putting in a “/”.

Both models would produce the result I was experiencing, but one of them makes a lot more sense. :wink:

So I guess that’s a documentation issue at most, not a bug. Sorry for the confusion!