From: Pete Wyckoff <pw@padd•com>
To: "Brian J. Murrell" <brian@interlinx•bc.ca>
Cc: git@vger•kernel.org
Subject: Re: checkout-index: unable to create file foo (File exists)
Date: Sun, 4 Nov 2012 17:10:18 -0500 [thread overview]
Message-ID: <20121104221018.GB9160@padd.com> (raw)
In-Reply-To: <k6ulre$bko$1@ger.gmane.org>
brian@interlinx•bc.ca wrote on Thu, 01 Nov 2012 16:25 -0400:
> When we use git on a network filesystem, occasionally and sporadically
> we will see the following from a git checkout command:
>
> error: git checkout-index: unable to create file foo (File exists)
>
> Through a very basic grepping and following of the source it seems that
> the core of the error message is coming from write_entry() in entry.c:
>
> fd = open_output_fd(path, ce, to_tempfile);
> if (fd < 0) {
> free(new);
> return error("unable to create file %s (%s)",
> path, strerror(errno));
> }
>
> So looking into open_output_fd() there is a call to create_file() which
> does:
>
> return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
>
> I am able to prevent the problem from happening with 100% success by
> simply giving the git checkout a "-q" argument to prevent it from
> emitting progress reports. This would seem to indicate that the problem
> likely revolves around the fact that the progress reporting uses SIGALRM.
>
> Given that O_CREAT | O_EXCL are used in the open() call and that SIGALRM
> (along with SA_RESTART) is being used frequently to do progress updates,
> it seems reasonable to suspect that the problem is that open() is being
> interrupted (but only after it creates the file and before completing)
> by the progress reporting mechanism's SIGALRM and when the progress
> reporting is done, open() is restarted automatically (due to the use of
> SA_RESTART) and fails because the file exists and O_CREAT | O_EXCL are
> used in the open() call.
>
> Does this seem like a reasonable hypothesis?
Fascinating problem and observations.
We've been using NFS with git for quite a while and have never
seen such an error.
> If it does, where does the problem lie here? Is it that SA_RESTART
> should not be used since it's not safe with open() and O_CREAT | O_EXCL
> (and every system call caller should be handling EINTR) or should the
> open() be idempotent so that it can be restarted automatically with
> SA_RESTART? If open(2) is supposed to be idempotent, it would be most
> useful to have a citation to standard where that is specified.
>
> If open() is not required to be idempotent, it's use with O_CREAT |
> O_EXCL and SA_RESTART seems fatally flawed.
man 7 signal (linux man-pages 3.42) describes open() as restartable.
Which network filesystem and OS are you using? The third option is
that there is a bug in the filesystem client.
-- Pete
next prev parent reply other threads:[~2012-11-04 22:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 20:25 checkout-index: unable to create file foo (File exists) Brian J. Murrell
2012-11-04 22:10 ` Pete Wyckoff [this message]
2012-11-05 15:25 ` Brian J. Murrell
2012-11-05 17:53 ` Pete Wyckoff
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121104221018.GB9160@padd.com \
--to=pw@padd$(echo .)com \
--cc=brian@interlinx$(echo .)bc.ca \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox