Skip to content

Conversation

@yfdyh000
Copy link
Contributor

@yfdyh000 yfdyh000 commented Feb 26, 2025

I expect this to mitigate dirty writes caused by XML build failures, although it is not sufficient for disk errors unless further safe writing methods are implemented, such as .tmp file and moving.
I encountered a crash issue (due to a detached attached database via execute SQL command) in version 3.13.1, which led to the loss of the project file, although I am unable to reproduce the crash on the master branch (this seem fixed by #3662 (comment)).

@mgrojo
Copy link
Member

mgrojo commented Nov 16, 2025

Thanks for your contribution, but if you weren't able to reproduce on master branch, I'd need more explanations on why this is needed.

There were two fixes since v3.13.1: 5d84f53 and the one you mentioned from #3662 (comment) (fdc4169)

@yfdyh000
Copy link
Contributor Author

This is a logical modification to prevent unprepared content from being written to the file successively at xml(&file). In the past, if the preparation process was interrupted, this could not be rolled back, i.e. non-atomicity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants