-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: Get modified date property behave like created date property #890
Comments
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? |
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 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. |
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. |
I want to update this and mention that this actually relates to #183 . |
|
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. |
I just added the ability to only update the date modified when either the Linter updates a file or the user modifies a file. It may encompass any other editor updates as well, but I am not certain on that. Feel free to test this out in the next release or on master. I plan to release a BRAT update soon. |
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.
The text was updated successfully, but these errors were encountered: