# [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. 5 messages from 2007-03-26 to 2007-03-26. Participants: Jim Meyering, Junio C Hamano, Nicolas Pitre. Thread: https://gitlist.dev/t/7411 ## Jim Meyering, 2007-03-26 13:57 Subject: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. Message-ID: <874po8umyk.fsf@rho.meyering.net> URL: https://gitlist.dev/e/874po8umyk.fsf%40rho.meyering.net ``` 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 ``` ## Junio C Hamano, 2007-03-26 20:33 Subject: Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. Message-ID: <7v8xdjwxr4.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xdjwxr4.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <874po8umyk.fsf@rho.meyering.net> ``` 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. ``` ## Jim Meyering, 2007-03-26 20:37 Subject: Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. Message-ID: <87fy7ru4fy.fsf@rho.meyering.net> URL: https://gitlist.dev/e/87fy7ru4fy.fsf%40rho.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. ``` ## Nicolas Pitre, 2007-03-26 20:42 Subject: Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.83.0703261636410.3041%40xanadu.home In-Reply-To: <7v8xdjwxr4.fsf@assigned-by-dhcp.cox.net> ``` On Mon, 26 Mar 2007, Junio C Hamano wrote: > 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. Actually, the temp file is always left there whenever there is an error or die() is called or CTRL_C is issued. I don't think it is worth bothering with the removal of temp files given all the cases that would have to be considered, and most probably not exercised that often (increasing their likelihood of bing buggy). Instead, teaching git-purge about those tmp files might be a better idea. Nicolas ``` ## Nicolas Pitre, 2007-03-26 20:44 Subject: Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure. Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.83.0703261644200.3041%40xanadu.home In-Reply-To: ``` On Mon, 26 Mar 2007, Nicolas Pitre wrote: > Instead, teaching git-purge about those tmp files might be a better > idea. git-prune that is. Nicolas ```