Re: [PATCH 1/2] sequencer: factor out rewrite_file()

From: "René Scharfe" <l.s.r@web.de>
To: Simon Ruderich <simon@ruderich.org>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Ralf Thielow <ralf.thielow@gmail.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 1/2] sequencer: factor out rewrite_file()
Date: Wed, 1 Nov 2017 14:00:11 +0100	[thread overview]
Message-ID: <22afeefa-cdd5-cd32-0a7c-6bad4de79f05@web.de> (raw)
In-Reply-To: <20171101110715.e4s7td2weisog4wt@ruderich.org>

Am 01.11.2017 um 12:10 schrieb Simon Ruderich:
> On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
>> +static int rewrite_file(const char *path, const char *buf, size_t len)
>> +{
>> +	int rc = 0;
>> +	int fd = open(path, O_WRONLY);
>> +	if (fd < 0)
>> +		return error_errno(_("could not open '%s' for writing"), path);
>> +	if (write_in_full(fd, buf, len) < 0)
>> +		rc = error_errno(_("could not write to '%s'"), path);
>> +	if (!rc && ftruncate(fd, len) < 0)
>> +		rc = error_errno(_("could not truncate '%s'"), path);
>> +	close(fd);
> 
> We might want to check the return value of close() as some file
> systems report write errors only on close. But I'm not sure how
> the rest of Git's code-base handles this.

Most calls are not checked, but that doesn't necessarily mean they need
to (or should) stay that way.  The Linux man-page of close(2) spends
multiple paragraphs recommending to check its return value..  Care to
send a follow-up patch?

René