[...]
It is unsafe due to a long standing bug where a failure deletes the copy of the original data without copying it back to the original file, so you are left with a truncated original file and no backup of the original data. You still have the new data in the Geany buffer of course. But it regularly has caught people out if they closed the buffer after a failure assuming they had the original data safe.
Uh, just checked the code and it really seems to be the case. Might fix that if I have time.
That would be great, but it would still be "some time" before the fix propagates to all machines using GIO so we could not rely on it until then.
If the write of the new data to the file failed, I wonder if the copy of the old data back would work? But worst case it should at least leave the copy around.
- It is now possible to set
use_gio_unsafe_file_saving=true use_atomic_file_saving=true
and to users it's unclear which of the options will be actually used (it's the use_atomic_file_saving case because it's checked first in the code).
Yeah, an enum not a set of bools would be better, IIUC the current system grew all the options over time rather than being planned. For sure cleaning it up would be good.
- The fallback "ordinary" file saving when
use_gio_unsafe_file_saving=false use_atomic_file_saving=false
doesn't bring any benefit compared to the two above
It just overwrites the file, nothing else, one data transfer, fast, no rename, works on *all* filesystems, keeps the files metadata. Whilst its not in any way "safe" its got the best performance.
OK, might make sense to keep it then.
Jiri
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel