[Geany-devel] GIO saving made configurable?

[Enrico Tröger]

On Tue, 14 Jun 2011 10:28:00 +1000, Lex wrote:

>Hi Columban.
>
>
>On 14 June 2011 08:54, Colomban Wendling <lists.ban at herbesfolles.org>
>wrote:
>> Hi,
>>
>> During the phase of removing code that is not relevant anymore since
>> the dependency bump, I fatally came out to write_data_to_disk().
>>  Now we can assume we have GIO, it may seem sensible to drop
>> completely the C API file saving code...
>>
>> ...However, GIO saving seems to cause some problems on some complex
>> situations:
>>
>> https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3220784&group_id=153444
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3184594&group_id=153444&atid=787791
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3126535&group_id=153444&atid=787791
>>
>> (and maybe more -- at least one on IRC).
>>
>> So I'm wondering: do we really want to drop the C API-using code
>> path, or do we want to make it configurable (like safe file saving)?
>>
>> Well, since I'm not completely sure of what causes the problems and
>> what are the downsides (either I don't remember or I did not
>> participate to the discussion...), I prefer to ask you what do you
>> think/know/remember/whatever about this.
>>
>
>Having been involved in some of the previous discussions here is what
>I remember.
>
>The methods of saving files are:
>
>1. g_file_set_contents, saves to a temporary file and renames, our
>safe file saving setting.  Safe, but permissions can change.  On
>windows has to close the old file and delete it before renaming the
>temporary, on Unix just renames.  Thus won't work if running on Unix
>and accessing Windows files.
>
>2. g_file_replace, tries to do the same as g_file_set_contents but
>checks if it can change the permissions first and, if it can't, falls
>back to copying the old file to a temporary then truncating the old
>file and writing over it.  On slow remote filesystems this gives lousy
>performance as it transfers data three times not just once (subject of
>several complaints).  Because it has better knowledge of which
>filesystems are which, can work on windows files from Unix.  Not safe,
>unless set to provide a permanent backup, will still delete the
>temporary file even if writing the new file fails.  Option for keeping
>the backup is in Geany SVN version only.
>
>3. c library write, unsafe but works fast on all filesystems.
>
>At the moment the c library option is only available if compile time
>determines GIO is not available or the user configures to not use GIO.
>
>Looking at these methods, they each address differing situations.  As
>Enrico once said, 'who knew it was so hard to just write a file' :-).

This sentence still comes to my mind everytime we speak about GIO and
file saving here :(. If we all only could use local ext2/3 filesystems
with huge capacity, all these problems were gone and we could simply
use the C API as it worked for the past decades :D. But let's stop
dreaming and coming back to reality:


>So I would say that all three need to stay, and the choice between GIO
>and the c library needs to be made a preference not a compile time
>option.

I think so too.
I'm only afraid how to give this choice to the user. This needs to be
well documented and probably should go into a normal. not hidden pref
and so should be in the preferences dialog.


Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20110619/967cd11a/attachment.pgp>