Re: Bug? file at the same time being deleted and not registered
- From
- Tomas Pospisek <tpo@sourcepole.ch>
- Date
- May 24, 2010, 08:02 UTC
- Message-ID
- <alpine.DEB.2.00.1005240932130.7107@tpo-laptop>
- In-Reply-To
- <20100523234459.GA8285@coredump.intra.peff.net>
On Sun, 23 May 2010, Jeff King wrote:
Show 30 quoted lines
> 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)
Show 13 quoted 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