On Mon, Sep 10, 2007 at 12:05:57AM +0200, Aurelien Jarno wrote: [...] > >>> bash -c 'echo a; echo b > a' >&- > >>> > >>> is enough for me to reproduce the problem.
[both "a" and "b" seen in file "a".] > >> Guess you have a buggy libc, then. > > [...] > > > > I wouldn't be surprised if it has to do with the fix to debian > > bug #429021. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429021 > > (I'm CCing Dmitry who is the author of that change according to > > bugs.debian.org) > > > > I can reproduce the "bug" with glibc from etch, or even from sarge, so I > really doubt that it comes from this change. [...] Hi Aurelien. The reason I suspected that is that Andreas with a glibc-2.6.1 was not seeing the problem so that it could be because it was a debian issue. Also Pierre-Philippe says it is not in debian unstable from 1st of May 2007 (glibc-2.5 based). And the only diff on libio/fileops.c in glibc-2.6.1-2 is that fix for 429021, and the log for that bug talks of something very related. I could not reproduce the problem with a glibc-2.3.4 on an old RedHat system. That version of glibc was inbetween sarge's (2.3.2) and etch's (2.3.6). Andreas, could you please confirm which distribution of Linux you have and which version of the libc package? All in all, it would suggest that the change was introduced by debian if not in the fix for 429021. To sum up: glibc's fflush seems to empty its buffer upon a unsuccessful fflush() (a fflush(3) where the write(2) fails) on - debian unstable glibc 2.5 (according to Pierre-Philippe) - Andreas' glibc 2.6.1 - Some RedHat glibc 2.3.4 (according to me) - Solaris 7 system libc (not glibc) - HPUX 11.11 system libc (not glibc) And it seems not to empty it in - debian unstable 2.6.1-2 (according to me and Pierre-Philippe) - debian etch (2.3.6?) according to Aurelien - debian sarge (2.3.2?) according to Aurelien Best regards, Stéphane
