On 3 April 2010 13:20, Colomban Wendling
<lists.ban@herbesfolles.org> wrote:
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't
>
>
> I 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.
Yes, its badly worded :-) what is meant is that if a file has more than one hard link, all the other links continue to point to the original data. For mine this is correct and expected behaviour so "won't work" comment threw me.
> 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.
I'd say we are right, gio local file handling uses fopen and fwrite, it would be an infinite loop if they were re-directed.
> 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".
Agree, I should have said to the same minimum level of competence.
> 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.
oh, have you seen the code then, millions of extraterrestrial space monkeys and typewriters come to mind :-)
seriously though you are correct.
Of course this doesn't apply if the IO layer doesn't support the needed
feature (actually, safe file saving with correct permissions).
At least for local filesystems g_file_replace will try to copy permissions to the temporary file and if that does not work will fall back to copying the content to the backup file, truncating the original file and writing to that, so in most cases it should end up with the initial permissions. But if the write then fails how do you find and restore the backup???
g_file_replace therefore solves the initial problem with using g_file_save_contents for safe file saving :-) and is what Alexey's patch does, thanks
Cheers
Lex
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