From: Jim Meyering Date: Mon, 26 Mar 2007 20:37:21 GMT Subject: Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. Message-ID: <87fy7ru4fy.fsf@rho.meyering.net> In-Reply-To: <7v8xdjwxr4.fsf@assigned-by-dhcp.cox.net> Junio C Hamano wrote: > Jim Meyering writes: > >> I stumbled across this in the context of the fchmod 0444 patch. >> At first, I was going to unlink and call error like the two subsequent >> tests do, but a failed write (above) provokes a "die", so I made >> this do the same. This is testing for a write failure, after all. >> >> Signed-off-by: Jim Meyering >> --- >> sha1_file.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/sha1_file.c b/sha1_file.c >> index 0897b94..42aef33 100644 >> --- a/sha1_file.c >> +++ b/sha1_file.c >> @@ -2155,7 +2155,8 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer, >> inflateEnd(&stream); >> >> fchmod(local, 0444); >> - close(local); >> + if (close(local) != 0) >> + die("unable to write sha1 file"); >> SHA1_Final(real_sha1, &c); >> if (ret != Z_STREAM_END) { >> unlink(tmpfile); >> -- >> 1.5.1.rc1.51.gb08b > > Hmph. Not catching error from close() is wrong, so this is an > improvement, but it still leaves tmpfile on the filesystem, > doesn't it? > > Looking at write_sha1_file(), which is in a sense more important > than this function, it is worse. We should also detect error > from close(), nuke the temporary file and return an error there. That was my thought, too, as I said, above. I assumed whoever decided a write failure was worth calling "die", also wanted to leave behind the corrupt temporary file. In retrospect, I shouldn't have assumed. Of course, if that's not the case, they both should unlink the temporary.