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

[Lex Trotman]

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?)...

@Columban,

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

Cheers
Lex

>> 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
file.

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.

Cheers
Lex

> 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
>
>