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.)
FWIW, you can change this setting using the Preferences dialog in Geany, it's under the Various tab, in the `files.*` items.
As to the actual bug, that shouldn't happen unless you had a Geany instance open when you edited the config file in another editor, then it would clobber your changes once that instance closed.
What OS/distro version, version of GTK/GLib (shown in Help->Debug Messages), and Geany version are you using?
WFM, Geany 1.37 (git >= 82590af4), en_AU.UTF-8 GTK 3.22.30, GLib 2.56.4
@cinchent
Are you sure your VM isn't restoring geany.conf?
As for the postscript rant, as I said in the wiki article, both of those methods are Glib library code that we don't control, you ranteth in the wrong place. However in defence of those, having read the code of GIO (which goes to considerable lengths to attempt to fix ownerships and permissions) its not simple given all the combinations of weird restrictions that various filesystems and permissions create. As you said, using simple overwrite (both the file options off) on a reliable local filesystem with plenty of space in a directory you own is the best, and if its never given you problems why not use that? But other people editing over flakey SSHFS systems and such do have problems, thats why the atomic systems were invented and why its default, even if not perfect they likely save some people.
Anyhow as @codebrainz said, without any information on your Geany, Glib, GTK, and system configuration including the VM if you are using one, we can't help you any more.
Thanks @codebrainz, Yes, I had already discovered that menu option, and changing settings from the geany dialog was in fact the only way I could get the settings changes to persist. That wasn't the point of my bug report, though, it was about direct config file editing, which in the Linux ethos, should always be an option.
@elextr, the "VM restoring geany.conf"? Huh? The "VM" here is VirtualBox, and the guest OS is Linux, neither of which randomly alter file content at random times. I tracked the anomaly to geany exit time, and it was as a direct consequence of exiting the geany application itself when the conf file content was being altered.
----- FYI, operating environment is a stock Ubuntu 18.04 install running under a VirtualBox 6.1.2. geany 1.32-2, the latest update available from the Ubuntu apt repo, without resorting to a PPA. --- From Debug Messages: Geany 1.32, en_US.UTF-8 GTK 3.22.30, GLib 2.56.4 Stock install, no plug-ins, nearly no customization. -----
Today I cannot repro the problem, naturally.
At the time of the failure yesterday, no other geany instances were running, at least not that the App Switcher showed. That was my first thought, in fact, and I checked explicitly for that. The only apps running at the time were the one geany instance I was opening and closing and a Terminal. That said, I suppose it's possible that there was still another geany *process* running that didn't show up as a GUI application to the App Switcher -- I didn't do a `ps auxwww | grep [g]eany` to rule out that possibility.
So, unlikely as it is, I suppose I will chalk up the anomaly to some phantom geany instance still running (?) and withdraw this bug report until such time as I can repro it and diagnose it more fully. I was using the app in very typical mainstream way, though, without trickery or unusual circumstances.
------ To be clear, lest my curmudgeonliness be off-putting: for the most part, I like geany quite a bit, and aside from some egregiously bad choices of default values (don't even get me started on the idiocy of Ctrl+R by default doing a warning-less and un-undoable reload, which cost me dearly twice before I finally nuked it), it's a fine app. The fact that you all spend your good time to support it as open source is quite laudable, and I salute you for that.
"VM restoring geany.conf"? Huh?
Well, the last time I used a VM every time its started it re-creates its file system from scratch was what I was thinking.
don't even get me started on the idiocy of Ctrl+R by default doing a warning-less and un-undoable reload
Just because __your__ use-case does not include reloading a lot does not mean others don't.
Anyway AFAICT 1.32 should allow undo of reload I think, unless you set the option `keep_edit_history_on_reload` to off.
lest my curmudgeonliness be off-putting
Now listen here, I'm the grumpy olde guy here, you are stepping on my turf.
Closed #2450.
github-comments@lists.geany.org