git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jáchym Barvínek" <jachymb@gmail.com>, git@vger.kernel.org
Subject: Re: Confusing git messages when disk is full.
Date: Wed, 15 Feb 2017 16:51:51 -0500	[thread overview]
Message-ID: <20170215215151.a5chtxyjhbe3og4p@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqk28r2kk4.fsf@gitster.mtv.corp.google.com>

On Wed, Feb 15, 2017 at 01:47:23PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > On Sun, Feb 12, 2017 at 05:37:30PM +0100, Jáchym Barvínek wrote:
> > If FETCH_HEAD failed to write because of a full disk (or any other
> > reason), then the right thing is for "git fetch" to write an error to
> > stderr, and git-pull should not continue the operation at all.
> >
> > If we're not doing that, then that is certainly a bug.
> 
> One suspect would be store_updated_refs().  We do catch failure from
> fopen("a") of FETCH_HEAD (it is truncated earlier in the code when
> the --append option is not given), but all the writes go through
> stdio without error checking.
> 
> I wonder if this lazy patch is sufficient.  I want to avoid having
> to sprinkle
> 
> 	if (fputs("\\n", fp))
> 		error(...);
> 
> all over the code.

Heh, I was just tracking down the exact same spot.

I think that yes, the lazy check-error-flag-at-the-end approach is fine
for stdio.

I tried to reproduce the original problem on a full loopback filesystem,
but got:

  fatal: update_ref failed for ref 'ORIG_HEAD': could not write to '.git/ORIG_HEAD'

I suspect you'd need the _exact_ right amount of free space to get all
of the predecessor steps done, and then run out of space right when
trying to flush the FETCH_HEAD contents.

> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index b5ad09d046..72347f0054 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -868,7 +868,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
>   abort:
>  	strbuf_release(&note);
>  	free(url);
> -	fclose(fp);
> +	if (ferror(fp))
> +		rc = -1;
> +	if (fclose(fp))
> +		rc = -1;
>  	return rc;

Yeah, I think this works. Normally you'd want to flush before checking
ferror(), but since you detect errors from fclose, too, it should be
fine.

We probably should write something stderr, though. Maybe:

  if (ferror(fp) || fclose(fp))
	rc = error_errno("unable to write to %s", filename);

-Peff

  reply	other threads:[~2017-02-15 21:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-12 16:37 Confusing git messages when disk is full Jáchym Barvínek
2017-02-15 21:32 ` Jeff King
2017-02-15 21:47   ` Junio C Hamano
2017-02-15 21:51     ` Jeff King [this message]
2017-02-15 22:28       ` Junio C Hamano
2017-02-15 22:32         ` Jeff King
2017-02-15 22:50           ` Junio C Hamano
2017-02-15 23:18             ` Jeff King
2017-02-16 10:10               ` Andreas Schwab
2017-02-16 16:44                 ` Jeff King
2017-02-16 21:31                   ` [PATCH] tempfile: avoid "ferror | fclose" trick Jeff King
2017-02-17  8:00                     ` Michael Haggerty
2017-02-17  8:07                       ` Jeff King
2017-02-17 10:42                         ` Michael Haggerty
2017-02-17 20:54                           ` Jeff King
2017-02-17 21:07                             ` Jeff King
2017-02-17 21:17                             ` Junio C Hamano
2017-02-17 21:21                               ` Jeff King
2017-02-17 21:42                                 ` Junio C Hamano
2017-02-17 22:10                                   ` Jeff King
2017-02-17 22:40                                     ` Junio C Hamano
2017-02-17 23:39                                       ` Jeff King
2017-02-17 23:52                                         ` Junio C Hamano
2017-02-17 23:54                                           ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170215215151.a5chtxyjhbe3og4p@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jachymb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).