git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
PWPete Wyckoff <pw@padd.com>
Date
Nov 4, 2012, 22:10 UTC
Message-ID
<20121104221018.GB9160@padd.com>
In-Reply-To
<k6ulre$bko$1@ger.gmane.org>
brian@interlinx.bc.ca wrote on Thu, 01 Nov 2012 16:25 -0400:
Show 35 quoted lines
> 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.

Show 9 quoted lines
> 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
Previous: Brian J. MurrellNext: Brian J. Murrell
Message 2 of 4 in “checkout-index: unable to create file foo (File exists)”
  1. Brian J. MurrellNov 1, 2012
  2. Pete WyckoffNov 4, 2012
  3. Brian J. MurrellNov 5, 2012
  4. Pete WyckoffNov 5, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.