[Geany-devel] Safe file saving - permissions issue

[Lex Trotman]

On 2 April 2010 03:07, Nick Treleaven <nick.treleaven at btinternet.com> wrote:

> On Thu, 1 Apr 2010 12:41:13 +0100
> Nick Treleaven <nick.treleaven at btinternet.com> wrote:
>
> > > 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)?
> > >
> > > I'm going to start working on it; if this is OK, I'll send a patch
> ASAP.
> >
> > BTW There is another problem that file saving should solve - not
> > losing existing file data when there is no space to save the new file.
> > Does g_file_replace_contents() handle this problem? (g_file_set_contents
> > () does handle this but as you mention has other problems).
>
> According to the docs for g_file_replace, which g_file_replace_contents
> uses internally, this case may be handled:
>
> "This will try to replace the file in the safest way possible so that
> any errors during the writing will not affect an already existing copy
> of the file. For instance, for local files it may write to a temporary
> file and then atomically rename over the destination when the stream is
> closed."
> http://library.gnome.org/devel/gio/unstable/GFile.html#g-file-replace
>
> Hopefully it still keeps permissions if the rename is done(!)
>

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.
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..
But it does leave the old file unharmed on out of space :-)

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.

Cheers
Lex


> Regards,
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20100402/077d39ee/attachment.html>