Re: Bug? file at the same time being deleted and not registered

From: Jeff King <peff@peff.net>
Date: May 23, 2010, 23:44 UTC
Message-ID: <20100523234459.GA8285@coredump.intra.peff.net>
In-Reply-To: <alpine.DEB.2.00.1005232245220.18372@tpo-laptop>

On Sun, May 23, 2010 at 11:09:53PM +0200, Tomas Pospisek wrote:

Show 16 quoted lines

> So we have a file that was committed, that git thinks it's scheduled to be
> deleted and at the same time is untracked. Doesn't make any sense,
> does it?
> 
> This happens only on the mhddfs backed filesystem. The same procedure
> works well in /tmp or on plain ext3.
> 
> Here's the strace of the commit step (from a identical try):
> 
>    http://pastebin.com/htUmWYGh
> 
> Jan 'jast' Krüger from the git IRC channel spotted in that strace the
> fact that the 'link' call is failing.
> 
> In that case IMHO git should complain and let the user know, that
> something went wrong and it can't proceed meaningfully.

If you mean this (from your strace):

  link(".git/objects/df/tmp_obj_cL0wfQ", ".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078") = -1 ENOSYS (Function not implemented)

Note that it is immediately followed by:

  rename(".git/objects/df/tmp_obj_cL0wfQ", ".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078") = 0

IOW, git tries the hard-link first, then falls back to the rename. If the rename also fails, git does complain. So I don't think that is your problem.

I would guess your real problem is that when we traverse the directory structure and see "a_file", for some reason git is not connecting that with the index entry for "a_file". In the past, problems like this are usually due to filesystems which munge the filename behind git's back. I.e., if you do "touch foo" you get some file whose name _looks_ like "foo" but is not bit-for-bit compatible. HFS will do this when normalizing utf8 characters, but I don't think we've ever seen it on anything as plain as "a_file".

Can you try running the output of "git diff-files --name-only" and "git ls-files -o" through xxd or something that would show individual bytes? My suspicion is that the "a_file" shown in each may not be bit-for-bit identical.

-Peff