On 6 November 2010 04:57, Jason Oster <[email protected]> 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 > [email protected] > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > > _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
