On Wed, 03 Nov 2010 00:26:00 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 02/11/2010 19:11, Nick Treleaven a écrit :
Hi list, To workaround bug(s) in GVFS, I've now changed the file saving implementation for systems with GIO in SVN trunk. See also:
http://lists.uvena.de/geany-devel/2010-November/003412.html
Please help test this. File permissions should be preserved after saving, and disk space exhaustion should now be handled without losing the previously saved file.
Interesting change, let's see what happens now -- this said I don't use remote files often so I will probably not notice any change...
Actually I should have been clearer - this change affects local files too. I'll list the fixes now:
permissions - was a bug only if using use_safe_file_saving pref, which is usually off anyway.
disk exhaustion - was a bug for local files and probably remote files.
file corruption - were bug(s) in GVFS for remote files, at least one is fixed in newest GVFS; our workaround will hopefully prevent corruption even with a broken GVFS.
Just to mention (I just saw that the question raised in the original thread, sorry not to have seen it before): you actually need to release GFiles with g_object_unref(). I'd thought it would be quite obvious -- you create an object, you destroy it -- but seems not :)
It wasn't clear an object was being created when I checked the docs originally. I just looked at the object hierarchy for GFile and it descends from GInterface, not GObject. Is g_object_unref () callable on a GInterface? I guess so but it would be nice to find some concrete information about it ;-)
Also, the docs for g_file_new_for_path don't mention releasing resources, but the docs for g_file_get_parent *do* say to call g_object_unref. Both functions return a GFile. Is this a bug in the docs for g_file_new_* ?
So, here's a (very) small patch for this.
I haven't applied it just yet, I'll wait for your reply to the above issue ;-)
Nick