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

[Jason Oster]

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?)...
> 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" 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jason_oster.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20101105/8ed296b6/attachment.vcf>