[Github-comments] [geany/geany] Configuration settings overwritten (#2450)

[Rod Pullmann]

Failure Recipe:
 1. No geany instances open.  
 2. Use _some other editor_ to edit my own geany config file (~/.config/geany/geany.conf), make a settings change, save the change.
 3. cat the config file to verify that the settings change is in fact present there as expected.
 4. Start up geany, close geany.
 5. The geany config setting modified in step 2 has been automatically reverted to its "original" setting value, the value it had before step 2.  <=== FAILURE

The failure in step 5 is because geany is saving its volatile internal configuration info to the config file on exit, every exit.

It is arguably bad practice to save the configuration file unconditionally every editing session, whether or not I have changed config settings during the editing session ("not", in my case).  That aside, why is geany reverting the setting to some previous state of its configuration, and where is that configuration info even being loaded from, if not my own config file?!

In other words, even if geany always loads config info at startup and stores it at shutdown, why is it loading the config info from location X (wherever that is) and storing it to location Y (my own config file)?  This is a bug.

------
POSTSCRIPT:
This is all because I'm trying to disable the broken 'use_atomic_file_saving' option.  (Yes, I have read all of the https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving page, and understand it fully.)  Enabling this option results in an edited file having its permissions/ownership/attributes altered arbitrarily whenever the file is saved!  I understand the technical difficulties in being able to reestablish ownership of the renamed file (a problmatic impediment), but there is no excuse for not reasserting the original permissions (and attributes) on the file after renaming, which should suffice for a huge percentage of the typical use cases.  This is intolerable, and renders it a generally useless -- and dangerous -- option.

Incidentally, I resorted to trying 'use_atomic_file_saving' at all because, in the VM filesystem in my use case, with 'use_gio_unsafe_file_saving' enabled (the default), geany flat-out refused to save an edited file successfully whatsoever, no how, no way, failing with an "access denied" even though I possessed full ownership on the writable file.  Yet another bug.  My only recourse is to disable all "safe" saving options and live "dangerously".  (Though, in 30 years, using countless other editors that do "dangerous" file saves, I've never once had a file truncation event due to a full filesystem or any other anomaly.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20200314/00d22840/attachment.htm>