Modifying a file causes the file to enter a never-ending loop of having the modified time changed until you restart Obsidian.

[mGuv]

• Restart Obsidian
• Modify a file
• Wait until the modified time changes
• Wait until the next modified debounce expires
• Notice that the modified time updates again
• This repeats forever. (Until Obsidian is restarted)

It seems the way the files are being listened to for changes (this.app.vault.on("modify", (file) => {..etc})) is being triggered by both manual edits AND then the actual change to the frontmatter the plugin does, entering an infinite loop.

I fixed it locally with the following changes:

Track files in a grace period

constructor() {
    super(...arguments);
    this.timer = {};
    this.gracePeriod = {};
  }

Wrapping the entire body of the vault.on("modify") call with:

if(!this.gracePeriod[file.path]) {
    // original code
} else {
    this.gracePeriod[file.path] = false;
}

And changing the timeout function to do:

this.gracePeriod[file.path] = true;
// Existing code

It's not perfect as technically someone editing at just the right time would trip it up. But it's working for me so far.

[alangrainger]

Can you replicate this in the Sandbox vault? I cannot replicate this behavior on Windows in the Sandbox vault. It may be some other plugin causing this situation in combination with the modified update.

As an aside I asked the Obsidian team the best way to approach this, but have not yet had an answer.

[mGuv]

I just created a brand new vault, with one file and just this plugin and it's still doing it.

Other info I can share is:

• I'm on Windows 11
• Obsidian Version: 1.3.7
• Plugin Version: 1.0.3
• I have changed the settings of the plugin
  • I have changed the frontmatter property in the settings to updatedAt
  • I have it set to ignore a folder, Extras

[alangrainger]

Cheers, that should hopefully give me enough detail to track it down.

[alangrainger]

Thanks @mGuv , I could reproduce and this should be resolved in v1.0.4. Can you please test and let me know?

[mGuv]

@alangrainger, no worries. Just tested a couple scenarios and all looks good.

Your plugin was the first plug-in I could find that would actually work with how I want to track files across multiple machines. All the others relying on file.ctime and file.mtime don't sync as it's all per machine based. This way I can actually commit my modified times without worry.

That's when I saw the issue as git status would keep flagging files for no reason, so I diffed them and it was the updated at time constantly changing, so took a look at the main.js file of the plugin to see what was going on and guessed it would be related to a setTimeout loop or setInterval getting stuck in the global js scope (as it would do it even with the file closed), so had a look for those and saw it.

Thought I'd let you know so you could fix it how you were comfortable with, so all good from me.

[mGuv]

Fixed in d5aa158925bd5975de5f7508a1d50e1c67435130 / v1.04

[alangrainger]

Your plugin was the first plug-in I could find that would actually work with how I want to track files across multiple machines. All the others relying on file.ctime and file.mtime don't sync as it's all per machine based.

Exactly! Using the filesystem time just seemed silly - I'm surprised I'm the first plugin developer who wanted it this way.

Glad it's working for you now 👍