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

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

From
Jeff King <peff@peff.net>
Date
Oct 5, 2017, 11:23 UTC
Message-ID
<20171005112355.lsoqxybgsovpqriy@sigill.intra.peff.net>
In-Reply-To
<20171005104407.65948-3-lars.schneider@autodesk.com>
On Thu, Oct 05, 2017 at 12:44:07PM +0200, lars.schneider@autodesk.com wrote:
Show 6 quoted lines
> From: Lars Schneider <larsxschneider@gmail.com>
> 
> If we are checking out a file and somebody else racily deletes our file,
> then we would write garbage to the cache entry. Fix that by checking
> the result of the lstat() call on that file. Print an error to the user
> if the file does not exist.

My gut tells me this is the right thing to be doing, but this commit message gives very little analysis. Let's see if we can talk it out a bit.

Aside from bizarre lstat failures, the plausible reason for seeing this is that somebody racily deleted the file. I.e.,:

  1. We wrote the file.
  2. They deleted it.
  3. We ran lstat() on it and found that it went away.

But imagine that the race went the other way, and (3) happened before (2). Then we'd actually get a real index entry, but the file would appear deleted to anybody who checks the filesystem against the stat data.

So I guess my question is: is step 3 an integral part of the checkout procedure, or is it simply an opportunity to refresh the index (since we know we just wrote out the content)?

If it's an integral part, then I agree that the error return you add here is the right thing to do. But if it's just an index refresh, then I wonder if we should report a successful checkout, but mark the entry as stat-dirty.

I dunno. It's pretty philosophical, and I have a feeling that nobody really cares all that much in practice. Certainly the error return seems like the easiest fix.

Show 11 quoted lines
> diff --git a/entry.c b/entry.c
> index 5dab656364..2252d96756 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -355,7 +355,8 @@ static int write_entry(struct cache_entry *ce,
>  	if (state->refresh_cache) {
>  		assert(state->istate);
>  		if (!fstat_done)
> -			lstat(ce->name, &st);
> +			if (lstat(ce->name, &st) < 0)
> +				return error("unable to get status of file %s", ce->name);

We could probably be a bit more specific about the situation, since the user will see this message with no context. Maybe something like:

  unable to stat just-written file %s

or something. We should probably also use error_errno(). I'd bet if this ever triggers that it's likely to be ENOENT, but certainly if it _isn't_ that would be interesting information.

-Peff
Previous: lars.schneider@autodesk.comNext: Junio C Hamano
Message 3 of 26 in “fix temporary garbage in the cache entry”
  1. 0/2 fix temporary garbage in the cache entrylars.schneider@autodesk.com, Oct 5, 2017
  2. 2/2 entry.c: check if file exists after checkoutlars.schneider@autodesk.com, Oct 5, 2017
  3. Jeff KingOct 5, 2017
  4. Junio C HamanoOct 6, 2017
  5. Jeff KingOct 6, 2017
  6. Junio C HamanoOct 6, 2017
  7. Jeff KingOct 6, 2017
  8. Junio C HamanoOct 6, 2017
  9. Lars SchneiderOct 8, 2017
  10. 1/2 entry.c: update cache entry only for existing fileslars.schneider@autodesk.com, Oct 5, 2017
  11. Jeff KingOct 5, 2017
  12. Junio C HamanoOct 5, 2017
  13. Jeff KingOct 5, 2017
  14. Junio C HamanoOct 5, 2017
  15. Jeff KingOct 6, 2017
  16. Lars SchneiderOct 8, 2017
  17. Jeff KingOct 9, 2017
  18. 1/3 write_entry: fix leak when retrying delayed filterJeff King, Oct 9, 2017
  19. Junio C HamanoOct 10, 2017
  20. Simon RuderichOct 10, 2017
  21. Jeff KingOct 10, 2017
  22. Simon RuderichOct 10, 2017
  23. 2/3 write_entry: avoid reading blobs in CE_RETRY caseJeff King, Oct 9, 2017
  24. Junio C HamanoOct 10, 2017
  25. 3/3 write_entry: untangle symlink and regular-file casesJeff King, Oct 9, 2017
  26. Junio C HamanoOct 10, 2017

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.