obsidian-linter
obsidian-linter copied to clipboard
platers
FR: Get modified date property behave like created date property
The created date property has the option "Force Date Created Key Value Retention" which is useful to retain created date when moving the vault around. Unfortunately the "Date modified" property does not have that option and thus the only practical way to keep it from updating when moving the vault around is to use another plugin "Update frontmatter modified date" by Alan Grainger.
Hope the problem is clear, here is a slightly better explaination if needed.
Hey @ironhak , how would this work in reality? We have discussed this a little on #886 , but nothing makes sense there.
The Linter currently only knows 2 things about a file: when it has been modified by the Linter and when the file system says the file has been modified. This means that when you edit a file in Obsidian ans then lint it, the Linter has no idea whether that date modified is because of an actual edit or a new file system (technically you could compare the created at and modified at times, but that does not always work).
So could you explain exactly what scenarios you would expect the Linter to update the date modified in? For example, how would it handle a scenario where the user edited a file, but the Linter does not make any changes to the file?
Hello, honestly I don’t know. The other plug-in I mentioned seems to work properly tough, maybe you can look into it.
I‘m sorry if I can’t be more useful, unfortunately I’m just the end-user and I don’t know nothing about coding.
I perfectly understood what you mean, I wouldn’t know how to answer it, but as said apparently that plug-in solve the problem.
So this is a slight variation on #392 . Once that gets added (assuming I have time to do it), then the only thing to do would be to add a boolean or list to determine what the user considers the date modified to be: the filesystem time or the last user/Linter edit in Obsidian.
Ignoring the file system's metadata for the modified date would be the simplest solution I think; only update the modified date when Obsidian saves the file. The date modified property could be older than what the file system reports, but does it really matter? It matters if you care about edits to files done externally to Obsidian, or if you want the modified date to update when moving to a new drive or something, but I'd say both cases shouldn't be what this feature aims to track. I'd be happy with date created and date modified sticking to events caused by Obsidian itself (then there'd be no need for the former's retention feature).
Edit: Markdown files created with other software pasted into an Obsidian vault would still benefit from reading the file creation metadata. Perhaps only read file metadata if the key isn't already present? A save could fix/add the modified date.
@redactedscribe , the rules in the Linter are device agnostic. So they were never designed to be run on multiple devices that sync to each other. That would be why the retain key was added. The same would need to be added for date modified. However, the Linter does not run on all vault modifications right now so it is not feasible to add that logic for forcing retention of the date modified until #392 is added.
What I don't get is why for creation data there's the option to switch from only internal or external, while for modified date you don't have that option.
What I don't get is why for creation data there's the option to switch from only internal or external, while for modified date you don't have that option.
The reason for that is because in order to do that #392 would need to be complete. This is because the Linter would only know when it makes a change as it stands.
~~Just an FYI, there's a useful plugin to update the modified date, although not perfect, which doesn't rely on the OS metadata: Update frontmatter modified date. Been using it some months and works well.~~ The original comment mentioned this... Might've even found out about it from this. My bad. Guessing I should say thank you!
It is not 100% feasible to do the same right now. It may be that modified date and time gets converted into a special case where it can run by itself to update the date modified and date created times. But I would likely need to think through what that would look like as a whole.