when reprograming signals (using e.g. sigaction) and disabling SA_RESTART, so that write isn't restarted on EINTR, fputs/fwrite/... may end up losing their local buffer. attached is a patch fixing the problem.
Created attachment 1894 [details] proposed fix
This patch turns out to be a seriously bad idea, because no other libcs preserve the stdio buffer state on error. At least bash, zsh, and rpc.mountd in all released versions of nfs-utils are known to fail with this patch applied, with rpc.mountd failing in such a way that NFS service appears to entirely fail because no fhs can be validated. (Also several of glibc's own tests fail.) Ideally you'd think it would be better: it's avoiding data loss. But a lot of programs are *expecting* data loss in this situation, and avoiding it makes them misbehave...
Subject: Re: FILE* operations are not robust enough with signals On Sat, Sep 22, 2007 at 11:40:58PM +0000, nix at esperi dot org dot uk wrote: > > ------- Additional Comments From nix at esperi dot org dot uk 2007-09-22 19:40 ------- > This patch turns out to be a seriously bad idea, because no other libcs > preserve the stdio buffer state on error. At least bash, zsh, and rpc.mountd in > all released versions of nfs-utils are known to fail with this patch applied, > with rpc.mountd failing in such a way that NFS service appears to entirely fail > because no fhs can be validated. (Also several of glibc's own tests fail.) > > Ideally you'd think it would be better: it's avoiding data loss. But a lot of > programs are *expecting* data loss in this situation, and avoiding it makes > them misbehave... Have you any evidence of that ? Because it definitely does not makes sense to me. Debian has the patch, and we didn't saw any of those problem show up yet.