Hi,
Lex Trotman a écrit :
2010/4/2 Алексей Антипов <1a_antipov@mail.ru mailto:1a_antipov@mail.ru>
As goes from GLib sources, the final replace strategy is backend-dependent. For local files: (from GLib sources, gio/glocalfileoutputstream.c, handle_overwrite_open): /* We use two backup strategies. * The first one (which is faster) consist in saving to a * tmp file then rename the original file to the backup and the * tmp file to the original name. This is fast but doesn't work * when the file is a link (hard or symbolic) or when we can'tI don't understand why it fails with a hard link, all files *are* hard links so that means it would never work, do you understand what they mean?
I think they mean it would break the links, which is actually true: hard links points to the file's data, then a simple rename() does NOT break the link, and then the hard links would not point to the newly created file. Of course, it is not a problem if the file have only one link (simple file) since there is only one entry point.
I don't understand why the C library calls fopen and fwrite call GIO, for file systems supported natively on the platform they should directly perform actions on that file system, for others they would have to go via fuse and the path you have shown, unless GVFS is taking over the whole file system and forcing all file system operations via itself :-( very bad if so. Impacts performance, reliability and maintainability.
I think too that GVFS have nothing to do here, only a "real" or FUSE FS, nothing more. But I might be wrong.
Geany also needs to be portable so it needs to handle GIO when available and non-GIO when not and windows with similar levels of competence.
Yes, but I think it should not prevent a specific improvement if it worth it (e.g. if it fixes a real problem that can't be fixed reliably with more generic code). I mean "similar" should be taken only as "don't let one be bad", not "don't let one be amazing".
If there are problems in the backends I would not expect Geany to compensate for them.
Of course not (I think).
I think the best way is to use GIO when possible, since it is meant for that; and it is unrealistic to handle each and every limitation of filesystems from inside a program (like geany or whatever). What if an unknown remote FS doesn't support feature X or Y (or not the way they may be expected to) we rely on? The only viable solution is a specific handling of this kind of cases. What a better place than an IO abstraction layer? But of course then, the point is the trust (and actual correctness) in the IO layer. Even if GIO have probably many bugs (as each and every program or library), I think it could be trusted: 1) it is an IO layer, then it is its role; 2) it is an active project that (should) fix the defects when found; 3) well... as said above, could we better trust our own code? I mean, GIO is not a funky joke made by drunk peoples, and it is not only used by two monkeys on a starship: bugs will be found and fixed.
Of course this doesn't apply if the IO layer doesn't support the needed feature (actually, safe file saving with correct permissions).
That's my two pounds... but consider I didn't go deep in the subject and it may be a somewhat wrong consideration, don't take this as if said after months of tests, thoughts and audit.
Regards, Colomban