[Geany-devel] Changed file saving implementation for systems with GIO
jason.oster at xxxxx
Fri Nov 5 17:57:23 UTC 2010
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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 303 bytes
Desc: not available
More information about the Devel