When the partition is full, attempting to save a file in Geany results in a complete file loss.
Geany version : 1.36 System : Ubuntu Linux 20.04 LTS
To reproduce :
1. Fill some partition until there is no space left on it. For example : fallocate -l 100G bigfile
2. Edit a text file located in the full partition and add some character to it
3. Try to save the file. Geany says there is no space left on device and gives some actions to try. Cancel and exit Geany
4. The edited file size is now 0KB and the data in it are completely lost
See https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving
Which saving method are you using? Any method other than use_atomic_file_saving is likely to result in the behaviour you describe as indicated in the reference above.
duplicate of #1895 and others
Closed #2494.
See https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving
Which saving method are you using? Any method other than use_atomic_file_saving is likely to result in the behaviour you describe as indicated in the reference above.
No I don't have use_atomic_file_saving set.
Why not simply checking that the remaining space is greater than the current file size and only allow to save in that case?
Why not simply checking that the remaining space is greater than the current file size and only allow to save in that case?
Because that information is not available cheaply, portably for all filesystem types and platforms Geany is available on, if a save fails just save somewhere else and see what the problem is, it could be lots of things not just out of space.
And as a further example of the problems with the approach, something as "simple" as free space on a plain vanilla ext4 partition is complicated by the fact that its a delayed allocation journalling file system, so free space is only accurate just after a full filesystem sync and no other file system activity has occurred.
So to get accurate space available before a save there would need to be nothing else using the filesystem, otherwise the available space can change between when its synced (which is very expensive) then space checked, and when the file is written, and so the write can still fail.
Small inaccuracies like that don't matter when there is plenty of space, but when space is tight and you really need the accuracy its not available except possibly in specific and expensive conditions.
Why not simply checking that the remaining space is greater than the current file size and only allow to save in that case?
Because that information is not available cheaply, reliably, and portably for all filesystem types and platforms Geany is available on, if a save fails just save somewhere else and see what the problem is, it could be lots of things not just out of space.
There is no way to think that when exiting an editor after it says there is no more space left on device, that editor will *null out* your precious file! So expecting that the user will save his data elsewhere before exiting is clearly not the correct way...
There is no way to think that when exiting an editor after it says there is no more space left on device, that editor will null out your precious file! So expecting that the user will save his data elsewhere before exiting is clearly not the correct way...
The user just requested that the file be overwritten when they said "save". Clearly the content of their "precious" file doesn't matter any more, its the contents of the Geany buffer that the user wants to save that is important.
And as the wiki article says, failing to save does not alter the Geany buffer, its still available to save somewhere else, whatever the reason the save failed. Save to a usb stick, save to a different drive, just save that precious buffer, and don't worry about the old file, they already said to overwrite it.
The user just requested that the file be overwritten when they said "save". Clearly the content of their "precious" file doesn't matter any more, its the contents of the Geany buffer that the user wants to save that is important. And as the wiki article says, failing to save does not alter the Geany buffer, its still available to save somewhere else, whatever the reason the save failed. Save to a usb stick, save to a different drive, just save that precious buffer, and don't worry about the old file, they already said to overwrite it.
Okay, but the user *does not know that the original file was destroyed*. There are cases where the file was only slightly modified (in my case I added only one line to the file), and one says: okay, there was a problem when saving, but at least my original file is safe, let's quit Geany and see what happened. An what happened is that the original file is now empty.
But I don't even understand why I have to argue here. That's simple: data loss in a software *must be avoided*, period (excepted in case of hardware problems, of course).
You can set the atomic file saving setting (and only that one, see the wiki article) to get the best chance of avoiding data loss.
But the process that provides atomic file saving doesn't work everywhere (like on some network storage systems or windows systems) and it introduces other problems like ownership and protection issues.
Those issues are not a function of Geany or the library that provides the atomic write code, its the way the operating system works, and all other editors will have the same problem.
But these issues atomic save causes keep annoying users all the time, not just on the (should be) rare occasion that writing fails.
The GIO_unsafe option attempts to fix those issues, but the workarounds add complexity and risk of data loss because it may not be able to use the atomic save technique. But for most cases it "just works" and on most systems, and thats why its the default.
That's simple: data loss in a software must be avoided, period (excepted in case of hardware problems, of course).
To be clear, running out of disk part way through writing the file _is_ a hardware problem. Your hardware doesn't have a big enough disk :)
To be clear, running out of disk part way through writing the file is a hardware problem. Your hardware doesn't have a big enough disk :)
I don't agree with you...
I did some tests in a VM with geany and some other editors and the same situation. Here are the results: - geany => nulls out the original file - xfw (from xfe file manager) => nulls out the original file - mousepad => truncates the original file - kate => truncates the original file - gedit => preserves the original file
So, as you see there are differences between the editor implementations. Among the five tested editors, gedit does the best job. It warns that the partition is full and it doesn't change the original file.
Why not doing the same as gedit? I think gedit relies on gio operations...
Another point: you could check the available space using statvfs() before attempting to save the file. I think you said this way is not accurate, why?
No, gedit does not use GIO _unmodified_, it carries a workaround to the GIO issue (which leaves a truncated file in some cases, its described in the wiki article), and that workaround depends on the internal workings of GIO AFAICT.
That may be fine for something like gedit where it is part of the Gnome infrastructure and tightly coupled with GIO versions, but its harder for separate apps that may be installed on systems with differing versions of GIO. You can find all these discussions if you search the issues and mailing list archives, its all been discussed before.
Anyway nobody has ported the GIO patch from gedit to Geany so its portability and supportability is a moot point. Contributors on all those other editors have clearly have not considered it worth the effort either, the same as Geany contributors.
`statvfs` has two problems:
1. as I said above, for file systems that use delayed allocation (including ext4) the free space number may be inaccurate.
2. its racey, after Geany does a statvfs there is nothing stopping some other process using the free space before Geany can write it.
OK, thanks for the explanations... However, you should at least modify the error message in geany so that the user is warned (in red) to save its file on another partition before exiting geany.
Thanks for politely listening to the explanations, some people are so angry they lost data (sort of understandable immediately after it happens) that they simply won't listen.
However, you should at least modify the error message in geany so that the user is warned (in red) to save its file on another partition before exiting geany.
Sure, pull requests are welcome.
github-comments@lists.geany.org