bug#80513: du should fflush every now and then

Hi Paul,

Paul Eggert <[email protected]> writes:

> A recently-installed coreutils change[1] had a good idea about
> avoiding locks, but the part that substituted ferror for fflush was
> problematic. That fflush had been in du.c for decades, and was put in
> because people want to run 'du' and see its output quickly as disk
> usage is discovered; they don't want to wait for a stdio output buffer
> to fill (or for du to exit) before seeing usage so far. Even with
> today's flash drives and faster file systems this can still be an
> issue, as hard drives are still in widespread use and network file
> systems can have nontrivial latency.

Oops, sorry.

I had made that change thinking that the addition of fflush was recent.
I was thinking of this commit from January:

    $ git diff 19d2d707f76d3ed6d609b9032f2729eaa5df9f51^! src/du.c
    diff --git a/src/du.c b/src/du.c
    index 1565c9078..a38c96174 100644
    --- a/src/du.c
    +++ b/src/du.c
    @@ -406,7 +406,9 @@ print_size (const struct duinfo *pdui, char const *string)
             }
         }
       printf ("\t%s%c", string, opt_nul_terminate_output ? '\0' : '\n');
    -  fflush (stdout);
    +  if (fflush (stdout) != 0)
    +    write_error ();
    +
     }

But the change here was just checking the result of fflush. I guess I
shouldn't place all my trust in my memory. :)

> The du change differs from other recent changes involving ferror vs
> fflush in id and groups, as those programs don't have the relatively
> slow I/O that du does.
>
> Simplest is to go back to using fflush, which I did by installing the
> attached.

I agree.

> A fancier approach I've seen other programs use, is to call fflush
> only if a second or so has passed since the last fflush. That might be
> overkill here, though.

Likewise, I think that is overkill here.

Going to mark this one as done, as I think it is uncontroversial.

Thanks,
Collin