Automatically update last modified date in note

Yes it is, you just didnā€™t use MomentJS format like it mentions.

Nothing is double quoted at my end. If youā€™re using 1.4.x just remember that itā€™s not ready yet and theyā€™re still fixing bugs.

1 Like

YYYY-MM-DD indeed works.
Itā€™s only one tag actually. Iā€™ll figure it out.

Cheers

Hi, Iā€™ve tried implementing this but I am getting the following error message. Anybody know how to solve this?

I have opened a new fault in Obsidian and now the times do work. Anybody knows what the issue might be?

Excellent, this is what I was looking for. System mtime is changed each time my Dropbox synchronizes files between different machines, so itā€™s frequently not reflecting actual time, while your plugin will update the modification time only when I actually edit the file.

1 Like

Glad to help :+1: I have no idea why the other two plugins which update a modified field use the file system time.

2 Likes

Truth be told, when running normal or regex replacements from other programs (Notepadqq, for instance), I see the field updated ā€“ but Obsidian was left open.

Slightly more concerning is this. Disabling these plugins seems to make this confounding issue stop.

  • Wonder what is causing the interference here.

Now I use the manual way of Save [Contrl+S] with Linter (Lint current file with ā€˜lint on saveā€™), which updates date modified.

That makes perfect sense, because Obsidian is executing a ā€œnote modifiedā€ event each time the note is modified.

Regarding the linked issue, if iCloud is constantly modifying notes in the background ā€¦ that seems a little concerning :grimacing: I donā€™t have a Mac so canā€™t comment on that, but it doesnā€™t sound good.

In terms of updating frontmatter on modified, perhaps there is another event to hook into rather than the ā€œnote modifiedā€ event. Iā€™ll have a look.

2 Likes

@gino_m I have updated the plugin to v1.1.0 with a new experimental update mode.

Instead of using Obsidianā€™s built-in ā€œfile has been modifiedā€ event, the new mode will watch for typing events in the editor view, and only update the frontmatter when actually typing occurs.

Can you please test this and see if it solves your use-case?

https://obsidian.md/plugins?id=frontmatter-modified-date

edit: I think you will need to restart Obsidian after changing that setting for it to work. I forgot to watch for the setting change and then re-register the plugin events.

I am curious about your opinion on what triggers the automatic merging issues (nothing to do with iCloud or sync) and how these changes effected by you will be an improvement?

No opinion - it is certain what is happening, itā€™s even documented in my code.

  1. Obsidian has an event that fires when you update a file: app.vault.on('modify')
  2. Obsidian has a method to update a frontmatter field: app.fileManager.processFrontMatter()
  3. When you update the frontmatter through Obsidianā€™s provided method while also typing, it causes an edit on the file which pops up the message ā€œ<File> has been modified externally, merging changes automatically.ā€

The changes I have just made are nothing to do with the above. The changes I made were for you to deal with your external modification of files - e.g. Notepadqq with Obsidian left open, or iCloud.

Thatā€™s what I feared, Alan. The advantages of installing either of the two plugins far outweigh the disadvantages (data loss) ATM. Sorry.

Iā€™m confused, why would there be any data loss? In fact I would go so far to say itā€™s impossible, since Iā€™m using Obsidianā€™s built-in methods to update the frontmatter. If thereā€™s any data loss it could only be due to an error in their own function, which seems very unlikely.

At the time of the message flashing up, people including me reported characters, lines missing. I linked the full thread.

It happened with the other modified date updater too, Alan.

The other modified date updater (and my plugin previously) used Obsidianā€™s ā€œfile modifiedā€ event to trigger updating the frontmatter. This event would be triggered by iCloud (apparently).

The new update mode does not use that event and will not be triggered by iCloud, only by you typing a keystroke.

Yeah but people reporting issues did not use iCloud. I use git too.

Also, how about this I wrote up a few days back?

I updated and reenabled the plugin and will be testing it.

Please let me know how it goes. It will solve the problem of stopping external processes from updating the frontmatter. It has no impact on any issues with Obsidianā€™s own file merging (in that the plugin does things the ā€œcorrectā€ Obsidian way, so it canā€™t be updated to be more correct).

Those issues are a question for the Obsidian devs, and well outside the scope of this plugin.

As a non-coder, I still understandā€¦that something gets entangled in what needs to be weeded out in core code. I thought first it was about the every-two-second auto-save. Some parts of these processes get tangled upā€¦but as I said, I am no coder.

As I am in the process of publishing important material online (challenging High Academia), I cannot lose face because of textual failures of any kind. I do etymology so every letter must be in place.

I expect 10-50 of my notes to be faulty at this point (not because of your plugin, of course).

The way my plugin works is that it waits until 10 seconds after all typing has stopped before it updates the frontmatter. This reduces the chances of any merge error message.

I did it this way purely because those error popups annoy me, rather than attempting to solve a merge issue.

Another solution for the issue youā€™re experiencing is to increase that timeout. For example if you set it to be 2 minutes after the last typing occurred before updating the frontmatter, it seems very likely that there wonā€™t be any merge conflict.

See how the v1.1.0 update goes, and if still no luck we can add a configurable timeout length.