[Geany-devel] Safe file saving - permissions issue

[Colomban Wendling]

Hi,

Lex Trotman a écrit :
> 
> 
> 2010/4/2 Алексей Антипов <1a_antipov at mail.ru <mailto:1a_antipov at 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.

> 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