The file mode bits after saving an already existing file is modified according to umask setting. It should preserve the file mode.
For example, if file with mode 600 is modified (umask 2), file saved by geany has mode 664.
This is a known documented problem that depends on the saving settings you use, the full TL;DR is [here](https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving).
You are saying because you selected to use glib's use_atomic_file_saving you can't fix the permissions (non-atomically) after glib has done the magic? Then you could ditch glib and write to temporary file by yourself and call fsync+close and fix file modes and ACL's etc before renaming over the original file.
... write to temporary file by yourself and call fsync+close and fix file modes and ACL's etc before renaming over the original file.
Thats what the GIO setting does (as described in the wiki article).
The Glib and GIO library code is quite complex, since it has to handle various file systems (you can mount windows file systems on Linux and vice versa, so its not just your native file system types) and it takes into account network file systems characteristics.
Since the Geany contributors do not have the range of different systems, nor the other resources, to test such code to the level that something as critical as writing your superb code to disk deserves, it is unlikely that it will be reinvented locally, even if "somebody" made a pull request.
Glib and GIO are heavily used libraries that have a fair chance of most bugs being bashed out of them, a little tested local replica would not be likely to be an improvement.
github-comments@lists.geany.org