brian@xxxxxxxxxxxxxxx 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
--
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