Re: checkout-index: unable to create file foo (File exists)

[Pete Wyckoff <pw@padd.com>]

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