File modification date should not change when dirty file closed with Typora

[neuromachina]

Describe the bug
When I open a Typora file the finder indicates the modification time of the file was changed.

To Reproduce
Steps to reproduce the behavior:

1. Open previously saved file
2. Note that the modification time changes

This is unexpected behavior.

File mod date should not change.

Use BBEdit as an example of proper behavior.

Desktop (please complete the following information):

• macOS 12.7.3 (21H1015)

Typora Version
1.8.10

---

• [ yes ] Searched existing issues to avoid creating duplicates.

• [ no ] Confirmed that it can be reproduced in built-in themes without customized css.

  If it only exists in 3rd party themes or css, you can still report it, but please attach the theme target or the css file. We may not "fix" it, if it is caused by 3rd party themes or css styles that we cannot support.

• [ yes ] Searched http://support.typora.io/

---

This has been an issue for more than one year... maybe two years.

Super annoying. I've just been putting up with it because I believe authors words that they want to build a perfect product. Please ficx this as high priority. I depend on my file save dates as a record keeping attribute.

When I open a file for reading, I DO NOT EXPECT THE MODIFICATION DATE TO BE UPDATED to match the last day I opened the file for read-only.

Thank you!

[abnerlee]

Could you attach the sample md file?
May relates #2354

[neuromachina]

Hello.

I was unable to reproduce just now.
Any text.md file.

My issue that I believe I have experienced many times before is a file's modification date was changed when a file was opened and perhaps edited (maybe not?) but not explicitly saved (for sure). I looked for an option to turn off auto-save.

I probably described this incorrectly in my first message on this Issue.

Our family purchased two 3-packs of the Typora license. We appreciate the design sensibilities in the UI.
Just so you know, I respect and value the commitment to make a sw product as bug free as possible. Typora is both elegant and functional.

Thank you.

[neuromachina]

After I tried to reproduce, I experienced one problem that is not advisable according to Apple User Interface Guidelines. That is, if the file is dirty, an attempt to close the file could result in data loss if the User was not asked if they want to save the new edits to a file. And in this case for me with Typora, an inverse, a data loss scenario is existent when the developer decides to auto-save a file (with no option for the User).

If the context of this auto-save is after a block of important text was inadvertently deleted before this save event, then there will be data loss IF the User cannot intervene to make the decision "not to save the file" in its current state. And presumably the user would perform an Undo command in that situation to restore the file to the previous state (and the current state in the file system).

AFAIK, BBEdit will track all those changes and if the file gets back to a state that matches the saved version in the file system, then BBEdit will no longer consider the file dirty and will close it without prompting the users that it is dirty; because it is not.

So this is definitely a sharp edge in the UI that can cut. It would be best if an auto-save-on-close workflow did not exist as a default with no option to opt-out.

If you want to be in the macOS Application Hall of Fame then consider an auto-save toggle in the Application Preferences such that Users that don't want that can turn that on.

I like auto-save in my Jetbrains IDE but not in my Typora files.

You are definitely on the trajectory for Best in Class application with the work you have done so far.

Please make prudent considerations when adding features that are better solved by other tools that do one thing well. I am thinking that you already think that way. :-)