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.
<<attachment: jason_oster.vcf>>
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
