Re: fsync in glib/gio

[Morten Welinder <mortenw gnome org>]

This is crazy.

People are actually advocating that thousands upon thousands of applications
need to be changed.

Yes, POSIX allows this particular idiotic behaviour.  So what?  It probably also
allows free() to do nothing, yet no-one in their right mind would want that.  Or
maybe you would be upset if the code fragment

    const char *s = "x";
    int i = (s+1)-s;

formatted your hard drive.  Yes, the C standard really does allow that
to happen.
(C99 section 6.5.6 #9, if you really want  the details.)    I don't
know about you,
but I would return the compiler with a big "Broken!" label if that happened.

The mere fact that a standard allows an idiotic implementation doesn't mean
we should play ball with it.  The same standard also allows sane
implementations.

We could litter fsync() calls all over, but...

1. It describes a semantic that isn't really what we want.  In fact,
there is no way
    to get exactly the semantics we want with POSIX.   We have to ask for the
    please-wait-for-the-disk semantics we don't want.  That's a sure
way of getting
    sluggish programs.

2. Shell scripts, Makefiles, and other languages without explicit
fsync control will
    kill really you.  Instead of...

        foo <file >file.new
        mv file.new file

    ...you get to write...

        foo <file >file.new
        sync
        mv file.new file

    Performance might be affected.

3. Auditing and changing thousands of programs?  Expect bugs.

We already break the strict letter of POSIX and the C standard in
fifty different ways.
If someone shows up with an environment that doesn't behave as we want, we
say "sorry, no ball".  Just add stupid file systems to the list.

Morten