threads / patch / 7411

patchsha1_file.c (write_sha1_from_fd): Detect close failure.

Subject: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure.

## tl;dr

5 messages between Mar 26, 2007 and Mar 26, 2007. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Jim Meyering· Mar 26, 2007, 13:57 UTC · lore

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 <jim@meyering.net>
---
 sha1_file.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Show changes to sha1_file.c +2 −2

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· Mar 26, 2007, 20:33 UTC · re: Jim Meyering · lore

Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure.

Jim Meyering <jim@meyering.net> writes:

Show 26 quoted lines

> 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 <jim@meyering.net>
> ---
>  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· Mar 26, 2007, 20:37 UTC · re: Junio C Hamano · lore

Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure.

Junio C Hamano <junkio@cox.net> wrote:

Show 36 quoted lines

> Jim Meyering <jim@meyering.net> 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 <jim@meyering.net>
>> ---
>>  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· Mar 26, 2007, 20:42 UTC · re: Junio C Hamano · lore

Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure.

On Mon, 26 Mar 2007, Junio C Hamano wrote:

Show 7 quoted lines

> 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· Mar 26, 2007, 20:44 UTC · re: Nicolas Pitre · lore

Re: [PATCH] sha1_file.c (write_sha1_from_fd): Detect close failure.

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