There is a pref in Geany: "use_gio_unsafe_file_saving". "Whether to use GIO as the unsafe file saving backend." If it is set to false, the creation of '.goutputstream-' files will be disabled. More info about the issue here: [https://github.com/mate-desktop/caja/issues/1439%5D(https://github.com/mate-...) I want to disable this "goutputstream file saving behavoiur" for ALL applications (mostly GTK apps) not only for Geany. This is why I am asking: How Geany achieve to disable this GIO behaviour? What is the exact code for that? Is there any Gnome setting we can apply? Can be used gsettings to disable creation of '.goutputstream-' files?
Geany does not disable the GIO behaviour, it simply does not use GIO code to save if the setting is false. Geany has three ways of saving files. For details see my PHD thesis (well its nearly as long) on the subject [here](https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving)
Closed #3697 as resolved.
Why would you disable this on the first place? The issue you linked has a fairly complete explanation on why it exists, and unless save actually fails (e.g. no free space, failure to rename to the source or other errors). If really Caja is showing those file for a longer time, I see two possibilities: the save failed and the file was left around (either a safety feature or a bug in GIO), or the file has been renamed and there's a bug in Caja not noticing.
In fact the OP link points to an issue raised on Caja that its slow to notice the file being renamed.
Geany does not disable the GIO behaviour, it simply does not use GIO code to save if the setting is false
This is a bad news for me; so, no way to get rid of this because the application developers write the GIO code into their apps. I suppose in case of Geany the choice is only possible because there are other options for saving. The only solution is to not use GTK applications. (Except Geany which gives the user the freedom of choice.) But I remember that formerly this "GIO saving" was not used, no '.goutputstream-' files were created. The "evolution"...
Why would you disable this on the first place?
I do not want any swap file, backup file ... be created, because they are unnecessary and harmful for envorinment. Unnecessary because if in 10.000 cases there are 1 case with a problem that is not a tragedy. That 1 case does not justify the other 99.999 totally unnecessary writes. And those unnecessary writes means use of energy and hardware wear .i.e. **destruction of nature**. And if you say that this does not matter since it is a very little energy and hardware wear ... you are wrong: these "little nothings" are made by millions; that is it makes a huge difference globally. Similar stupidity (wrong for nature) is that now not the noatime option is the default mount option in Linux kernel.
I do not want any swap file, backup file ... be created, because […] those unnecessary writes means use of energy and hardware wear
Did you measure that they are? I mean, in either case the *whole* file is re-written, the only question is *where* it is. The additional operation is the rename, but nothing else (yes, it's one more write, adjusting the directory entry, I must admit). It would actually save things *if, and only if* there was an environmentally efficient (and that's a big question on what is the best trade-off between more writes or more CPU cycles to avoid writes) "do not write if identical to current data" implemented in the file system (or some place down the line).
If you want to save energy, I suggest you *close apps like Caja when not needed* because they monitor files and get the updates, that's likely a whole lot more costly than updating the directory entry. And I won't talk about not using any modern web browser, or rather website, because that's likely a nightmare :)
Unnecessary because if in 10.000 cases there are 1 case with a problem that is not a tragedy.
Well, hopefully it's not, but if might depend on *what* is actually lost. And yes, it should not happen, but when it actually does it might be painful -- and what is the cost of restoring the lost data?
---
Anyway, if it's so much of a concern to you, I suggest you patch GIO itself not to do that for your usage. I doubt you could convince upstream to change this to something that doesn't offer the same level of safety (although there is probably still a current bug that makes this safety moot, e.g. in case of not enough space to write the file), but you could also try and sell it there.
Did you measure that they are? I mean, in either case the whole file is re-written, the only question is where it is. The additional operation is the rename, but nothing else
I doubt that only a rename happens, even more I am sure that not. I tried to make measure but not succedeed. They advised inotifywait application. Ufortunately it is not installed on the system currently I am using, and I did not installed just for this. Francesco Galgani explained how to use polling instead of inotifywait [https://www.baeldung.com/linux/command-execute-file-dir-change%5D(https://ww...) so I followed this tutorial. I opened Geany with ~/test/test.txt empty file, pasted some Lorem Ipsum and accented characters, but not saved the file. Then executed this command:
`watch --chgexit -n 0.01 "ls --all -l --full-time ~/test/ | sha256sum" && ls --all -l --full-time ~/test/`
And then executed save in Geany. At that moment watch exited and the ls command was executed. But I can see only 1 file, test.txt and not the '.goutputstream-' file. The reason I think is that '.goutputstream-' file had a very little life time, so the ls comand was executed too late. But that '.goutputstream-' file was created because I could see it in PCManFM file manager for a very short time (just a blinking). And in that moment there were 2 files there: the '.goutputstream-' file and test.txt. Just this is the reason you can see clearly the change: the "list of files" grows in that moment. So, not only a rename happens. Otherwise @elextr's [page](https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving) confirms this:
use_gio_unsafe_file_saving ... Disadvantages: ... Uses twice the disk space.
An other issue:
It would actually save things if, and only if there was an environmentally efficient (and that's a big question on what is the best trade-off between more writes or more CPU cycles to avoid writes) "do not write if identical to current data" implemented in the file system (or some place down the line).
I do not really understand this. Why means a simple save more CPU cycles than saving when you use a backup file or "GIO saving"? If you talked about periodic automatic saving, yes that is other stupidity but of course I turn it off. Also turn off checking the file periodically for changes. And "do not write if identical to current data" of course is the "best trade" because this spares your storage device.
Well, hopefully it's not, but if might depend on what is actually lost. And yes, it should not happen, but when it actually does it might be painful -- and what is the cost of restoring the lost data?
I think the best solution would be (for all apps): by default: simple save without using any swap, backup, "GIO method", or other thing (also disabled automatic save, check for file changes). And if you are editing a document that is very important for you, you could switch on (only for that time/case/document) the enumerated methods for your safety. I have been editing documents for many many years but never happened that the "GIO method" saved my file.
An other solution would be using laptop with battery inside (against blackout), but the problem is that every charge cycle shortens battery life. And if you keep the battery always in laptop there will be many. Well, there would be solution: to set to not charge the battery in BIOS or until a specific charge level. My Dell laptop theoretically supports this (I can set it in BIOS) but in reality not: every time there is a power failure or simply I shutdown the laptop the BIOS "resets" the charging behaviour and the battery charges again. I really do not understand how they could make such an idiocy...
And I won't talk about not using any modern web browser, or rather website, because that's likely a nightmare
Yes, there are many many things the developers could make more environmentally friendly, efficient and logic. Unfortunately the trend is just the opposite. There must be good laws for this made by specialists. Not laws such the "cookie consent law" which is a rare stupidity and digital environmental disaster made by idiots who do not know nothing about IT. That law must be complemented by a law to force all web browser developers to ensure a standard way to set your "cookie consent" easely and globally and do not waste your time and the energy for every web site. I just lose my all zest for life after visiting a few sites...
I suggest you patch GIO itself
Yes, it seems that is a real possibilty, thank you for idea, although I am afraid it is not a very simple thing...
I doubt that only a rename happens, even more I am sure that not.
What happens when you write a file in-place:
- write the *whole* file data again at the same place as the old one[^1]
When happens if you write to a temp file (like GIO does)
- create a new file (which is allocating a new directory entry) - write the whole file data at this new place - (optionally) copy over file attributes form the old file - move the new file in place of the new one (dump the old entry, update the new one with the old name -- or the other way around, I'm nto entirely sure but that's the same)
Yes, it's more complicated, but the only extra writes are meta-data about the file, it is *not* written twice. It's not "write to temp then write again to original", and it's not a backup either (although a backup is not more greedy in writes either, it's almost the exact same thing but the backup is not deleted).
Yes, this requires twice the amount of free space during the write operation, because you do not remove the old data before the new one is fully written, but when the operation is finished it uses the same amount -- and again, doesn't write twice.
[^1]: actually with SSDs it's highly unlikely it'll be written at the same place, but the visible behavior is the same.
To emphasise @b4n's fourth bullet point, only the directory entries are changed, this probably only means modifying the inode number in the directory file and marking the old one free.
And more on the footnote, not just SSDs, but with journalling file systems its guaranteed it won't be the same blocks.
And don't forget shingled disks never overwrite, and have to move stuff around internally to defragment whole zones before reusing them.
Also the miniscule costs of one extra directory write has to be balanced against the cost of running the computer for the time required to reproduce lost data if something goes wrong. Probably everyone should be backup saving every minute to a raid 5 (min 3 disks) array :smiling_imp:
Yes, it's more complicated, but the only extra writes are meta-data about the file, it is not written twice.
Yes, I understand your explanation (if really this happens), but even in this case there is an extra write operation (the renaming), which is unnecessary in my opinion. I have explained why...
But actually what happens when Geany saves the changes (made during the edit)? The whole old data is replaced every time? This is not very logic: if you change only a little part of the file then should be changed only that part. This could be accomplished since rsync can do such thing. Maybe there are such applications which use this type of saving. And if there is such saving the "GIO method" does more writes.
Also the miniscule costs of one extra directory write has to be balanced against the cost of running the computer for the time required to reproduce lost data if something goes wrong.
The probability of a "disaster" of this type (during that very short saving time) is so infinitesimally small that does not justify these methods. And again, if you edit a very important document you could use it temporarily for that document. I have data losses some times in my "PC life" but those data are definitively lost because the reasons were others: the failures of HDDs. This is (this was; hopefully the HDDs will disappear soon) the real danger for our data.
The probability of a "disaster" of this type (during that very short saving time) is so infinitesimally small that does not justify these methods.
You may hold that personal opinion, fine, but many others, including most of those who make and use Geany and those who make GIO do not agree. And the anguish of those who lose their work is significant.
This is (this was; hopefully the HDDs will disappear soon) the real danger for our data.
Certainly will improve the power consumption, but reliability not so much, SSDs don't seem massively better than HDDs, Backblaze latest data has AFR of 0.98% for SSDs and 1.47% for HDDs, so an all SSD system isn't that much better (and the SSDs are newer than the HDDs, lets see what the trend over time is).
And mitigating drive failure is why I said RAID array, and I use a mirrored pair day to day, but of course thats double or more the power, take that environment. :grin:
and I lost ALL data from the disc, not only edited documents...
But you had a backup right? Oh dear .....
github-comments@lists.geany.org