<br><br><div class="gmail_quote">On 2 April 2010 03:07, Nick Treleaven <span dir="ltr"><<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, 1 Apr 2010 12:41:13 +0100<br>
Nick Treleaven <<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.com</a>> wrote:<br>
<br>
> > Btw, the bugs with GVFS didn't appear with GNOME 2.26 (and probably before), so I think we can safely use fopen() and fprintf()/fwrite() there. Then, your proposal about version separation (use GIO with GLib>=2.16 and fopen()/g_file_set_contents() with other) is extremely attractive. Do you know if there is a way to get GLib version at runtime, not at compile-time (so that there is no need to rebuild all the packages for different versions)?<br>

> ><br>
> > I'm going to start working on it; if this is OK, I'll send a patch ASAP.<br>
><br>
> BTW There is another problem that file saving should solve - not<br>
> losing existing file data when there is no space to save the new file.<br>
> Does g_file_replace_contents() handle this problem? (g_file_set_contents<br>
> () does handle this but as you mention has other problems).<br>
<br>
</div>According to the docs for g_file_replace, which g_file_replace_contents<br>
uses internally, this case may be handled:<br>
<br>
"This will try to replace the file in the safest way possible so that<br>
any errors during the writing will not affect an already existing copy<br>
of the file. For instance, for local files it may write to a temporary<br>
file and then atomically rename over the destination when the stream is<br>
closed."<br>
<a href="http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace" target="_blank">http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace</a><br>
<br>
Hopefully it still keeps permissions if the rename is done(!)<br></blockquote><div><br>I would doubt it :-( its creating the new temporary file then renaming that to the original name.  This leaves it with the permissions of the temporary file ie those of a new file.<br>
It might work if it copies the attributes of the old file to the temporary first, but thats a backend dependent action since permissions depend on the filesystem..<br>But it does leave the old file unharmed on out of space :-)<br>
<br>The problem is that remote file systems (most anyway)  do not actually have an atomic rename and delete operation.  In fact many actually have race conditions when you try to remove the old file and then rename the temporary as a non-atomic pair of operations.  So just because it seems to work for one application doesn't mean it will allways work for it with a different remote file system.  Something like that can be the cause of an empty file.<br>
<br>Cheers<br>Lex<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
Regards,<br>
Nick<br>
_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
</div></div></blockquote></div><br>