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
