Closed Safari77 closed 2 weeks ago
Thanks for reporting this, it indeed looks like we should indeed just remove these lines
I'll do it because the current code indeed looks like a good way to lose the file contents entirely...
On Windows the destination should be removed first.
And fflush / fsync before fclose :) (mingw needs a bit different handling for fsync) (... and check for EINTR; and EINVAL (which is okay to ignore if writing to some special devices)).
Oops, yes, MoveFile()
doesn't remove the existing file without a special flag not used by rename()
. And maybe we should actually use ReplaceFile() instead?
I don't think we want to add fsync here, this is a whole different can of worms.
Yeah, I add fsync into my own wxGTK build :)
wxFile::Flush
already has HAVE_FSYNC
check but it does not work when writing config files?
Note that fsync is not very scary, glib2 has had it since v2.66 in g_file_set_contents_full
, which is often used to write config files. Without fsync the written file usually is zero bytes after a crash (when using a temporary file like now in wxGTK).
I think the latest PR version should work, please let me know if you still see any problems with it (not related to fsync
).
I didn't find config option to configure unlink-usage, but this app does just Write() and Flush() . Filesystem is ZFS.
rename overwrites the config file atomically (
preferences
), unlink it harmful: if crash happens after unlink and before rename, file contents are maybe gone, at least in theory.wxGTK-3.2.6 on Fedora x86_64 Linux, Gnome 47 Wayland gtk-3.24.43