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

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

[Jim Meyering]

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

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

[Junio C Hamano]

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.

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

[Jim Meyering]

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

> 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.

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

[Nicolas Pitre]

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

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

[Nicolas Pitre]

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