Junio C Hamano <gitster@xxxxxxxxx> writes:
>> Hmm, I thought we turned off SIGPIPE when writing to filters these days.
>> Looks like we still complain if we get EPIPE, though. I feel like it
>> should be the filter's business whether it wants to consume all of the
>> input or not[1], and we should only be checking its exit status.
>>
>> -Peff
>>
>> [1] As a practical example, consider a file format that has a lot of
>> cruft at the end. The clean filter would want to read only to the
>> start of the cruft, and then stop for reasons of efficiency.
>
> Yes. Let's do these two. The preparatory patch is larger than the
> real change.
And this is the second one.
While preparing these, I noticed a handful of system calls whose
return values are not checked in the codepaths involved. We should
clean them up, but I left them out of these two patches, as they are
separate issues.
-- >8 --
Subject: [PATCH 2/2] filter_buffer_or_fd(): ignore EPIPE
We are explicitly ignoring SIGPIPE, as we fully expect that the
filter program may not read our output fully. Ignore EPIPE that
may come from writing to it as well.
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
convert.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/convert.c b/convert.c
index 9a5612e..0f20979 100644
--- a/convert.c
+++ b/convert.c
@@ -359,6 +359,8 @@ static int filter_buffer_or_fd(int in, int out, void *data)
write_err = (write_in_full(child_process.in, params->src, params->size) < 0);
} else {
write_err = copy_fd(params->fd, child_process.in);
+ if (write_error == COPY_WRITE_ERROR && errno == EPIPE)
+ write_error = 0; /* we are ignoring it, right? */
}
if (close(child_process.in))
--
2.4.1-413-ga38dc94
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html