Workaround for: Rendering markdown files on Windows results in timestamp changes (Detected by Git)

Share & showcase
1

Context

We use Obsidian with the vault shared from a Git repository as our internal knowledge base solution at where I work. Windows users have been plagued with a perplexing bug that results in unexplained changes to markdown files when triggered.

It seems that a feasible workaround has been discovered so I’m sharing it here for posterity.

Problem Description

Under conditions that are difficult to replicate/understand, rendering some notes in Obsidian results in the underlying markdown file being modified in some way.

  • The behavior manifests only with Obsidian on Windows
  • Occurs sporadically
  • git diff reveals no changes in the file
  • MD5 hashes show file as unchanged
  • Regardless, Git believes that unstaged changes exist
  • Detailed listing of the file on Linux reveals that the last modified timestamp has been altered
    • A Stack Overflow posting led me to this page, which made me think this could be why Git interprets the file as changed
    • Google then led me to discovering the Git trustctime configuration

Environmental Considerations

  • Our shared vault is hosted in a private GitLab repository.
    • I’ve developed a custom Go application to configure installations for internal users, including Git.
  • Obsidian-Git is being used to pull/push files from a central repository.
  • The repository is being share between Linux, Mac, and Windows hosts.

Workarounds

We appear to have corrected the issue by applying the following settings to the local git configuration file:

  • core.autocrlf=true
  • core.trustctime=false

That is, the [core] section of the repository’s .git\config file is:

[core]
        bare = false
        autocrlf = true
        trustctime = false
2

Thanks for sharing! I’ve moved the post to Share & Showcase and added "Workaround for: " to the title.

3

Could the cause be a line-encoding issue?

4

Sorry for my delayed response!

No, I don’t believe so. We crossed the “line ending issue” early during adoption and found that Windows implementations needed receive autocrlf=true in .git/config. That corrected the line ending problem for us.

The timestamp issue appears to be distinct, and one could argue it’s more of an abnormality with git. This is the first time I’ve witnessed git hit on timestamp changes.

A partner organization uses Obsidian as well and they implemented the workaround shortly after we did.

We’ve not witnessed this issue in 16 days! :tada:

Example Workaround Git Configs

Linux

[core]
    bare = false
    autocrlf = input

Windows

[core]
    bare = false
    autocrlf = true
    trustctime = false
5

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