On Sun, 23 May 2010, Jeff King wrote:
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.
(Yes, I was refering to those lines)
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.
$ git diff-files --name-only
$ # no output at all
$ git ls-files -o | xxd
0000000: 615f 6669 6c65 0a a_file.
$ ls|xxd
0000000: 615f 6669 6c65 0a a_file.
For completeness:
$ git ls-files
$ git ls-files -c
$ git ls-files -d
$ git ls-files -m
$ git ls-files -s
$ git ls-files --directory
$ git ls-files -u
$ git ls-files -k
$ git ls-files -t
$ git ls-files -o -t
? a_file
$ git ls-files --full-name -o
a_file
$ git ls-files -s a_file
$ # nothing
However:
$ pwd
/home/tpo/src/projects/abook/bar
$ ls
a_file
$ realpath a_file
/mnt/mhddfs/home/tpo/src/projects/abook/bar/a_file
Which is because:
$ ls -l /home/tpo/|grep src
lrwxrwxrwx 1 tpo tpo 24 2008-08-14 10:29 src -> /mnt/mhddfs/home/tpo/src
The 'name' trail might be the right one though, because mhddfs will
distribute its files on different backing filesystems (I thin depending on
where it still has space left). However I 'stat'ed all files below the
working directory (including a_file and .git*) and they're all on the same
device.
*t