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
