On 6 November 2010 10:43, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
On Thu, 4 Nov 2010 17:53:47 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
So it seems that function doesn't handle disk exhaustion safely. (But this is no worse than before for Geany).
Before we had safe or unsafe file saving. Let's keep that choice, shall we? I can write the patch, it's only a few lines.
For more than 20 years now, the only safe save is to write the data into a temporary file in the same directory, and then rename it over the target file. Even if the rename fails, you still have the temporary file. That changes the onwership and permissions, which is exactly the behaviour of the safe g_file_set_contents().
The documentation of g_file_replace() may state "will try to replace the file in the safest way possible", but I don't believe in miracles, much less in ones from the glib developers.
While searching to report the bug (see below), I found that this isn't that simple. Actually, g_file_replace() itself seems quite safe, but g_file_replace_contents() isn't.
Well, it doesn't say much in the doc, but why would it not use g_file_replace and so be just as safe??
g_file_replace() use a probably correct backup strategy, and returns a stream to write to in a safe way. This stream will actually point to a temporary file (or likely, seems there are 2 different strategies), and this file will be moved automatically to the final place when the stream get closed/destructed.
And then we get the same permissions problem that glibs g_file_set_contents has which was where we came in....
The problem is that there is no API yet to abort the replacement, and so prevent the final move to be done.
Actually, this is safe if e.g. the caller crashes during write, or anything that prevents the stream to be closed, and so the file to be moved...
Perhaps you might like to file a bug against GIO. Perhaps first use gdb to break on that function just to be absolutely sure.
Perhaps. But bugs filed to gnome and kde may take years to resolve...
The bug is already reported, see https://bugzilla.gnome.org/show_bug.cgi?id=602412 Sadly, this bug was reported on 2009-11 and last activity was 2010-04...
Par for the course, if no one is worried enough to fix it then why should the Gnome guys, its open source after all ....
Le 04/11/2010 18:53, Nick Treleaven a écrit :
Also, if the argument for backups is set perhaps disk exhaustion is handled: http://library.gnome.org/devel/gio/2.25/GFile.html#g-file-replace-contents
More or less. The backup file will be kept, but the "original" might still be lost. The data isn't completely lost so, but the user might not notice the backup is here (and it will not be restored).
I thought the sequence with backup would be:
1. write new contents to temp file, uses space 2. if successful rename old file to backup, uses no space 3. rename temp file to filename, uses no space
so if the write fails for exhaustion the old file is still there but no backup, what we want.
If one of the renames fails the state could be confusing, with a temp file and no old file, or a backup and no new file but that needs a filesystem crash to lose metadata right in the rename, *very* rare especially with journaled filesystems.
Cheers Lex
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel