[Geany-devel] Changed file saving implementation for systems with GIO

Lex Trotman elextr at xxxxx
Fri Nov 5 22:47:32 UTC 2010

On 6 November 2010 04:57, Jason Oster <jason.oster at campnavajo.com> wrote:
> On 11/05/2010 08:42 AM, Colomban Wendling wrote:
>>> But from an efficiency point of view its much more work.  Probably not
>>> a problem on a local filesystem, but on a remote filesystem it
>>> requires three transfers of the data instead of one, read the old file
>>> and write the backup then write the new file.  As I only use remote
>>> filesystems on fast networks I can't say how important this is likely
>>> to be, but for big files/lots of files it may be a problem, also I'm
>>> thinking web sites edited via ftp, ssh etc.  This seems to be the use
>>> case for most of the performance complaints.
>> Well, right. I didn't thought that copy is unlikely to be done by the
>> remote machine (is a filesystem/GVFS-backends clever enough to support
>> copies?)...


Also is the remote filesystem clever enough to support local copies??
EG NFS does not IIUC.


>> So yes, it would probably be a significant overhead on non-local files.
>> Needs some testing probably.
> At the risk of making an obvious suggestion, why not use "move/rename"

@ Jason,

If you move/rename to the backup you remove the original file, so it
would have to be created again (thats what gtk_set_contents does). But
the new file is created with different permissions from the original

And changing the permissions can be *very* annoying if it keeps taking
execute off your scripts each time you edit them :-( Thats what we are
trying to avoid.


> instead of "copy"?  (I searched the list archives and couldn't find
> anything.)  That eliminates efficiency concerns.  And the only problem I can
> think of is file locking; If a move/rename fails (perhaps the file is locked
> by another process?) then fall-back to copying the file contents.  If the
> file is locked, though, I wouldn't guarantee that writing the contents of
> the file would work, anyway.
>>> If making a backup file is selected when the file is opened then the
>>> write of the backup happens then, uses the data read for the open and
>>> doesn't need to happen at save time, it could even be asynchronous so
>>> long as it was checked for correct completion before saving.  This
>>> would reduce the user visible performance impact.
>> Theoretically yes, but I would not do that because another application
>> may have changed the file since we loaded it and we may not have noticed.
>> I think this looses a bit of the usefulness of a backup.
> Using move/rename avoids this concern.
>>> Personally I would implement both and let the user choose (especially
>>> as g_file_set_contents exists).
>> Why not. Fast&  reliable v.s. even more reliable.
>> But it needs to write two different code paths, and if we want to
>> support direct GIO API (which is probably a good idea IMHO, at least for
>> the GNOME desktop with remote FS) as well as standard C API, we need
>> about 4 code paths.
> That's one point I haven't researched: does GIO not support move/rename
> directly?  That would be a silly thing to overlook, but I'll admit the
> possibility.
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list