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

[Jeff King <peff@peff.net>]

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

> 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