{"thread":{"id":"23885","subject":"Bug? file at the same time being deleted and not registered","startedAt":"2010-05-23T21:09:53Z","lastAt":"2010-05-24T14:46:44Z","messageCount":9,"participants":["Tomas Pospisek","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142168","messageId":"alpine.DEB.2.00.1005232245220.18372@tpo-laptop","threadId":"23885","inReplyTo":null,"subject":"Bug? file at the same time being deleted and not registered","fromName":"Tomas Pospisek","fromEmail":"tpo_deb@sourcepole.ch","sentAt":"2010-05-23T21:09:53Z","receivedAt":"2010-05-23T21:09:53Z","isPatch":false,"sender":{"key":"tpo_deb@sourcepole.ch","avatar":null},"body":"(I'm not subscribed, so please in case do Cc: me)\n\nShort version:\n==============\n\n  $ # we're on a mhddfs backed filesystem here, that doesn't support hardlinks\n  $ mkdir bar\n  $ cd bar/\n  $ git init\n  Initialized empty Git repository in /mnt/mhddfs/tmp/bar/.git/\n\n  $ touch a_file\n  $ git add a_file\n  $ git commit a_file -m bla\n  [master (root-commit) ca0ce50] bla\n   0 files changed, 0 insertions(+), 0 deletions(-)\n   create mode 100644 a_file\n\n  $ git status\n  # On branch master\n  # Changes to be committed:\n  #   (use \"git reset HEAD <file>...\" to unstage)\n  #\n  #       deleted:    a_file\n  #\n  # Untracked files:\n  #   (use \"git add <file>...\" to include in what will be committed)\n  #\n  #       a_file\n\nSo we have a file that was committed, that git thinks it's scheduled to be\ndeleted and at the same time is untracked. Doesn't make any sense, does \nit?\n\nThis happens only on the mhddfs backed filesystem. The same procedure \nworks well in /tmp or on plain ext3.\n\nHere's the strace of the commit step (from a identical try):\n\n    http://pastebin.com/htUmWYGh\n\nJan 'jast' Krüger from the git IRC channel spotted in that strace the fact \nthat the 'link' call is failing.\n\nIn that case IMHO git should complain and let the user know, that \nsomething went wrong and it can't proceed meaningfully.\n\n\nLong version:\n=============\n\n  $ mkdir bar\n  $ cd bar/\n  $ ls -la\n  total 8\n  drwxr-xr-x 2 foo foo 4096 2010-05-23 22:51 .\n  drwxr-xr-x 2 tpo tpo 4096 2010-05-13 19:27 ..\n\n  $ git init\n  Initialized empty Git repository in /mnt/mhddfs/tmp/bar/.git/\n\n  $ git status\n  # On branch master\n  #\n  # Initial commit\n  #\n  nothing to commit (create/copy files and use \"git add\" to track)\n\n  $ touch a_file\n  $ git status\n  # On branch master\n  #\n  # Initial commit\n  #\n  # Untracked files:\n  #   (use \"git add <file>...\" to include in what will be committed)\n  #\n  #       a_file\n  nothing added to commit but untracked files present (use \"git add\" to\n  track)\n\n  $ git add a_file\n  $ git status\n  # On branch master\n  #\n  # Initial commit\n  #\n  # Changes to be committed:\n  #   (use \"git rm --cached <file>...\" to unstage)\n  #\n  #       new file:   a_file\n  #\n\n  $ git commit a_file -m bla\n  [master (root-commit) ca0ce50] bla\n   0 files changed, 0 insertions(+), 0 deletions(-)\n   create mode 100644 a_file\n\n  $ git status\n  # On branch master\n  # Changes to be committed:\n  #   (use \"git reset HEAD <file>...\" to unstage)\n  #\n  #       deleted:    a_file\n  #\n  # Untracked files:\n  #   (use \"git add <file>...\" to include in what will be committed)\n  #\n  #       a_file\n"},{"id":"142170","messageId":"20100523234459.GA8285@coredump.intra.peff.net","threadId":"23885","inReplyTo":"alpine.DEB.2.00.1005232245220.18372@tpo-laptop","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-23T23:44:59Z","receivedAt":"2010-05-23T23:44:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, May 23, 2010 at 11:09:53PM +0200, Tomas Pospisek wrote:\n\n> So we have a file that was committed, that git thinks it's scheduled to be\n> deleted and at the same time is untracked. Doesn't make any sense,\n> does it?\n> \n> This happens only on the mhddfs backed filesystem. The same procedure\n> works well in /tmp or on plain ext3.\n> \n> Here's the strace of the commit step (from a identical try):\n> \n>    http://pastebin.com/htUmWYGh\n> \n> Jan 'jast' Krüger from the git IRC channel spotted in that strace the\n> fact that the 'link' call is failing.\n> \n> In that case IMHO git should complain and let the user know, that\n> something went wrong and it can't proceed meaningfully.\n\nIf you mean this (from your strace):\n\n  link(\".git/objects/df/tmp_obj_cL0wfQ\", \".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078\") = -1 ENOSYS (Function not implemented)\n\nNote that it is immediately followed by:\n\n  rename(\".git/objects/df/tmp_obj_cL0wfQ\", \".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078\") = 0\n\nIOW, git tries the hard-link first, then falls back to the rename. If\nthe rename also fails, git does complain. So I don't think that is your\nproblem.\n\nI would guess your real problem is that when we traverse the directory\nstructure and see \"a_file\", for some reason git is not connecting that\nwith the index entry for \"a_file\". In the past, problems like this are\nusually due to filesystems which munge the filename behind git's back.\nI.e., if you do \"touch foo\" you get some file whose name _looks_ like\n\"foo\" but is not bit-for-bit compatible. HFS will do this when\nnormalizing utf8 characters, but I don't think we've ever seen it on\nanything as plain as \"a_file\".\n\nCan you try running the output of \"git diff-files --name-only\" and \"git\nls-files -o\" through xxd or something that would show individual bytes?\nMy suspicion is that the \"a_file\" shown in each may not be bit-for-bit\nidentical.\n\n-Peff\n"},{"id":"142180","messageId":"alpine.DEB.2.00.1005240932130.7107@tpo-laptop","threadId":"23885","inReplyTo":"20100523234459.GA8285@coredump.intra.peff.net","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Tomas Pospisek","fromEmail":"tpo@sourcepole.ch","sentAt":"2010-05-24T08:02:14Z","receivedAt":"2010-05-24T08:02:14Z","isPatch":false,"sender":{"key":"tpo@sourcepole.ch","avatar":null},"body":"On Sun, 23 May 2010, Jeff King wrote:\n\n> On Sun, May 23, 2010 at 11:09:53PM +0200, Tomas Pospisek wrote:\n>\n>> So we have a file that was committed, that git thinks it's scheduled to be\n>> deleted and at the same time is untracked. Doesn't make any sense,\n>> does it?\n>>\n>> This happens only on the mhddfs backed filesystem. The same procedure\n>> works well in /tmp or on plain ext3.\n>>\n>> Here's the strace of the commit step (from a identical try):\n>>\n>>    http://pastebin.com/htUmWYGh\n>>\n>> Jan 'jast' Krüger from the git IRC channel spotted in that strace the\n>> fact that the 'link' call is failing.\n>>\n>> In that case IMHO git should complain and let the user know, that\n>> something went wrong and it can't proceed meaningfully.\n>\n> If you mean this (from your strace):\n>\n>  link(\".git/objects/df/tmp_obj_cL0wfQ\", \".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078\") = -1 ENOSYS (Function not implemented)\n>\n> Note that it is immediately followed by:\n>\n>  rename(\".git/objects/df/tmp_obj_cL0wfQ\", \".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078\") = 0\n>\n> IOW, git tries the hard-link first, then falls back to the rename. If\n> the rename also fails, git does complain. So I don't think that is your\n> problem.\n\n(Yes, I was refering to those lines)\n\n> I would guess your real problem is that when we traverse the directory\n> structure and see \"a_file\", for some reason git is not connecting that\n> with the index entry for \"a_file\". In the past, problems like this are\n> usually due to filesystems which munge the filename behind git's back.\n> I.e., if you do \"touch foo\" you get some file whose name _looks_ like\n> \"foo\" but is not bit-for-bit compatible. HFS will do this when\n> normalizing utf8 characters, but I don't think we've ever seen it on\n> anything as plain as \"a_file\".\n>\n> Can you try running the output of \"git diff-files --name-only\" and \"git\n> ls-files -o\" through xxd or something that would show individual bytes?\n> My suspicion is that the \"a_file\" shown in each may not be bit-for-bit\n> identical.\n\n  $ git diff-files --name-only\n  $ # no output at all\n\n  $ git ls-files -o | xxd\n  0000000: 615f 6669 6c65 0a                        a_file.\n  $ ls|xxd\n  0000000: 615f 6669 6c65 0a                        a_file.\n\nFor completeness:\n\n  $ git ls-files\n  $ git ls-files -c\n  $ git ls-files -d\n  $ git ls-files -m\n  $ git ls-files -s\n  $ git ls-files --directory\n  $ git ls-files -u\n  $ git ls-files -k\n  $ git ls-files -t\n  $ git ls-files -o -t\n  ? a_file\n  $ git ls-files --full-name -o\n  a_file\n  $ git ls-files -s a_file\n  $ # nothing\n\n\nHowever:\n\n  $ pwd\n  /home/tpo/src/projects/abook/bar\n  $ ls\n  a_file\n  $ realpath a_file\n  /mnt/mhddfs/home/tpo/src/projects/abook/bar/a_file\n\nWhich is because:\n\n  $ ls -l /home/tpo/|grep src\n  lrwxrwxrwx  1 tpo tpo     24 2008-08-14 10:29 src -> /mnt/mhddfs/home/tpo/src\n\n\nThe 'name' trail might be the right one though, because mhddfs will \ndistribute its files on different backing filesystems (I thin depending on \nwhere it still has space left). However I 'stat'ed all files below the \nworking directory (including a_file and .git*) and they're all on the same \ndevice.\n\n*t"},{"id":"142182","messageId":"20100524082430.GA18755@coredump.intra.peff.net","threadId":"23885","inReplyTo":"alpine.DEB.2.00.1005240932130.7107@tpo-laptop","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-24T08:24:30Z","receivedAt":"2010-05-24T08:24:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 24, 2010 at 10:02:14AM +0200, Tomas Pospisek wrote:\n\n> >Can you try running the output of \"git diff-files --name-only\" and \"git\n> >ls-files -o\" through xxd or something that would show individual bytes?\n> >My suspicion is that the \"a_file\" shown in each may not be bit-for-bit\n> >identical.\n> \n>  $ git diff-files --name-only\n>  $ # no output at all\n\nHrm, I had originally thought that your \"git status\" output showed\na_file as deleted in the working tree, which is why I suggested\ndiff-files. But looking at your output again, I see that it is scheduled\nfor deletion. In other words, the index entry has been removed entirely,\nas if \"git rm --cached a_file\" had been issued.\n\nSo I think I was on the wrong track with the filename-munging, then.\nSorry to lead you astray. But the problem is that your index is missing\nor bogus, which is even weirder.\n\nLooking at your strace dump, I see it writing out the index (it writes\nto index.lock and then renames it into place). Can you take a look at\nyour .git/index file? It should be 104 bytes and look something like:\n\n  $ xxd .git/index\n  0000000: 4449 5243 0000 0002 0000 0001 4bfa 367d  DIRC........K.6}\n  0000010: 0000 0000 4bfa 367d 0000 0000 0000 0900  ....K.6}........\n  0000020: 0099 801d 0000 81a4 0000 03e8 0000 03e8  ................\n  0000030: 0000 0000 e69d e29b b2d1 d643 4b8b 29ae  ...........CK.).\n  0000040: 775a d8c2 e48c 5391 0006 615f 6669 6c65  wZ....S...a_file\n  0000050: 0000 0000 1f80 d668 c07b 5955 8678 4360  .......h.{YU.xC`\n  0000060: 8215 6238 89be 9b4d\n\nIt won't match byte-for-byte because there is stat information in there,\nbut you should see a_file.\n\nIf it's empty or 32 bytes, then that explains what status is reporting\n(but the question still remains how we got into that state).\n\n-Peff\n"},{"id":"142183","messageId":"alpine.DEB.2.00.1005241027580.8425@tpo-laptop","threadId":"23885","inReplyTo":"20100524082430.GA18755@coredump.intra.peff.net","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Tomas Pospisek","fromEmail":"tpo@sourcepole.ch","sentAt":"2010-05-24T08:29:02Z","receivedAt":"2010-05-24T08:29:02Z","isPatch":false,"sender":{"key":"tpo@sourcepole.ch","avatar":null},"body":"On Mon, 24 May 2010, Jeff King wrote:\n\n> On Mon, May 24, 2010 at 10:02:14AM +0200, Tomas Pospisek wrote:\n>\n>>> Can you try running the output of \"git diff-files --name-only\" and \"git\n>>> ls-files -o\" through xxd or something that would show individual bytes?\n>>> My suspicion is that the \"a_file\" shown in each may not be bit-for-bit\n>>> identical.\n>>\n>>  $ git diff-files --name-only\n>>  $ # no output at all\n>\n> Hrm, I had originally thought that your \"git status\" output showed\n> a_file as deleted in the working tree, which is why I suggested\n> diff-files. But looking at your output again, I see that it is scheduled\n> for deletion. In other words, the index entry has been removed entirely,\n> as if \"git rm --cached a_file\" had been issued.\n>\n> So I think I was on the wrong track with the filename-munging, then.\n> Sorry to lead you astray. But the problem is that your index is missing\n> or bogus, which is even weirder.\n>\n> Looking at your strace dump, I see it writing out the index (it writes\n> to index.lock and then renames it into place). Can you take a look at\n> your .git/index file? It should be 104 bytes and look something like:\n>\n>  $ xxd .git/index\n>  0000000: 4449 5243 0000 0002 0000 0001 4bfa 367d  DIRC........K.6}\n>  0000010: 0000 0000 4bfa 367d 0000 0000 0000 0900  ....K.6}........\n>  0000020: 0099 801d 0000 81a4 0000 03e8 0000 03e8  ................\n>  0000030: 0000 0000 e69d e29b b2d1 d643 4b8b 29ae  ...........CK.).\n>  0000040: 775a d8c2 e48c 5391 0006 615f 6669 6c65  wZ....S...a_file\n>  0000050: 0000 0000 1f80 d668 c07b 5955 8678 4360  .......h.{YU.xC`\n>  0000060: 8215 6238 89be 9b4d\n>\n> It won't match byte-for-byte because there is stat information in there,\n> but you should see a_file.\n>\n> If it's empty or 32 bytes, then that explains what status is reporting\n> (but the question still remains how we got into that state).\n\nThere's no .git/index file there:\n\n  $ ls -l .git/\n  total 36\n  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 branches\n  -rw-r--r-- 1 tpo tpo    4 2010-05-23 21:36 COMMIT_EDITMSG\n  -rw-r--r-- 1 tpo tpo   73 2010-05-23 21:36 description\n  -rw-r--r-- 1 tpo tpo   23 2010-05-23 21:36 HEAD\n  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 hooks\n  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 info\n  drwxr-xr-x 3 tpo tpo 4096 2010-05-23 21:36 logs\n  drwxr-xr-x 7 tpo tpo 4096 2010-05-24 09:26 objects\n  drwxr-xr-x 4 tpo tpo 4096 2010-05-23 21:36 refs\n\n*t\n"},{"id":"142184","messageId":"20100524084932.GA21051@coredump.intra.peff.net","threadId":"23885","inReplyTo":"alpine.DEB.2.00.1005241027580.8425@tpo-laptop","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-24T08:49:33Z","receivedAt":"2010-05-24T08:49:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 24, 2010 at 10:29:02AM +0200, Tomas Pospisek wrote:\n\n> >If it's empty or 32 bytes, then that explains what status is reporting\n> >(but the question still remains how we got into that state).\n> \n> There's no .git/index file there:\n> \n>  $ ls -l .git/\n>  total 36\n>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 branches\n>  -rw-r--r-- 1 tpo tpo    4 2010-05-23 21:36 COMMIT_EDITMSG\n>  -rw-r--r-- 1 tpo tpo   73 2010-05-23 21:36 description\n>  -rw-r--r-- 1 tpo tpo   23 2010-05-23 21:36 HEAD\n>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 hooks\n>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 info\n>  drwxr-xr-x 3 tpo tpo 4096 2010-05-23 21:36 logs\n>  drwxr-xr-x 7 tpo tpo 4096 2010-05-24 09:26 objects\n>  drwxr-xr-x 4 tpo tpo 4096 2010-05-23 21:36 refs\n\nThanks. That means \"git status\" is at least reporting the right thing.\nNow we just need to figure out why, when the strace of commit shows it\nbeing written and renamed into place, the index file is missing.\n\nI tried setting up a simple mhddfs mount to reproduce your problem, but\neverything works fine for me. What version of mhddfs are you using? I'm\nusing version 0.1.28. I wonder if git is somehow triggering an mhddfs\nbug. Looking through the svn logs for mhddfs, between 0.1.27 and 0.1.28,\nthere is a commit with message \"fixed rename bug\".\n\n-Peff\n"},{"id":"142188","messageId":"alpine.DEB.2.00.1005241125210.3664@tpo-laptop","threadId":"23885","inReplyTo":"20100524084932.GA21051@coredump.intra.peff.net","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Tomas Pospisek","fromEmail":"tpo@sourcepole.ch","sentAt":"2010-05-24T09:26:44Z","receivedAt":"2010-05-24T09:26:44Z","isPatch":false,"sender":{"key":"tpo@sourcepole.ch","avatar":null},"body":"On Mon, 24 May 2010, Jeff King wrote:\n\n> On Mon, May 24, 2010 at 10:29:02AM +0200, Tomas Pospisek wrote:\n>\n>>> If it's empty or 32 bytes, then that explains what status is reporting\n>>> (but the question still remains how we got into that state).\n>>\n>> There's no .git/index file there:\n>>\n>>  $ ls -l .git/\n>>  total 36\n>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 branches\n>>  -rw-r--r-- 1 tpo tpo    4 2010-05-23 21:36 COMMIT_EDITMSG\n>>  -rw-r--r-- 1 tpo tpo   73 2010-05-23 21:36 description\n>>  -rw-r--r-- 1 tpo tpo   23 2010-05-23 21:36 HEAD\n>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 hooks\n>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 info\n>>  drwxr-xr-x 3 tpo tpo 4096 2010-05-23 21:36 logs\n>>  drwxr-xr-x 7 tpo tpo 4096 2010-05-24 09:26 objects\n>>  drwxr-xr-x 4 tpo tpo 4096 2010-05-23 21:36 refs\n>\n> Thanks. That means \"git status\" is at least reporting the right thing.\n> Now we just need to figure out why, when the strace of commit shows it\n> being written and renamed into place, the index file is missing.\n>\n> I tried setting up a simple mhddfs mount to reproduce your problem, but\n> everything works fine for me. What version of mhddfs are you using? I'm\n> using version 0.1.28. I wonder if git is somehow triggering an mhddfs\n> bug. Looking through the svn logs for mhddfs, between 0.1.27 and 0.1.28,\n> there is a commit with message \"fixed rename bug\".\n\nIt's version 0.1.28-1 from Ubuntu.\n\n*t\n"},{"id":"142196","messageId":"alpine.DEB.2.00.1005241228100.5304@tpo-laptop","threadId":"23885","inReplyTo":"20100524084932.GA21051@coredump.intra.peff.net","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Tomas Pospisek","fromEmail":"tpo@sourcepole.ch","sentAt":"2010-05-24T10:32:19Z","receivedAt":"2010-05-24T10:32:19Z","isPatch":false,"sender":{"key":"tpo@sourcepole.ch","avatar":null},"body":"On Mon, 24 May 2010, Jeff King wrote:\n\n> On Mon, May 24, 2010 at 10:29:02AM +0200, Tomas Pospisek wrote:\n>\n>>> If it's empty or 32 bytes, then that explains what status is reporting\n>>> (but the question still remains how we got into that state).\n>>\n>> There's no .git/index file there:\n>>\n>>  $ ls -l .git/\n>>  total 36\n>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 branches\n>>  -rw-r--r-- 1 tpo tpo    4 2010-05-23 21:36 COMMIT_EDITMSG\n>>  -rw-r--r-- 1 tpo tpo   73 2010-05-23 21:36 description\n>>  -rw-r--r-- 1 tpo tpo   23 2010-05-23 21:36 HEAD\n>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 hooks\n>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 info\n>>  drwxr-xr-x 3 tpo tpo 4096 2010-05-23 21:36 logs\n>>  drwxr-xr-x 7 tpo tpo 4096 2010-05-24 09:26 objects\n>>  drwxr-xr-x 4 tpo tpo 4096 2010-05-23 21:36 refs\n>\n> Thanks. That means \"git status\" is at least reporting the right thing.\n> Now we just need to figure out why, when the strace of commit shows it\n> being written and renamed into place, the index file is missing.\n>\n> I tried setting up a simple mhddfs mount to reproduce your problem, but\n> everything works fine for me. What version of mhddfs are you using? I'm\n> using version 0.1.28. I wonder if git is somehow triggering an mhddfs\n> bug. Looking through the svn logs for mhddfs, between 0.1.27 and 0.1.28,\n> there is a commit with message \"fixed rename bug\".\n\nOh wow (trying to reproduce the bug just from the strace). It's mhddfs. \nLook:\n\n$ touch bla\n$ touch bla.lock\n$ echo asdf > bla.lock\n$ mv bla.lock bla\n$ ls\n$ # nothing here\n\nThat's a quite catastrophic bug in mhddfs :-((( ! Argh.\n\nMoving this over to mhddfs.\n\nThanks a lot Jeff!\n*t\n"},{"id":"142204","messageId":"alpine.DEB.2.00.1005241642040.5109@tpo-laptop","threadId":"23885","inReplyTo":"alpine.DEB.2.00.1005241228100.5304@tpo-laptop","subject":"Re: Bug? file at the same time being deleted and not registered","fromName":"Tomas Pospisek","fromEmail":"tpo@sourcepole.ch","sentAt":"2010-05-24T14:46:44Z","receivedAt":"2010-05-24T14:46:44Z","isPatch":false,"sender":{"key":"tpo@sourcepole.ch","avatar":null},"body":"On Mon, 24 May 2010, Tomas Pospisek wrote:\n\n> On Mon, 24 May 2010, Jeff King wrote:\n>\n>> On Mon, May 24, 2010 at 10:29:02AM +0200, Tomas Pospisek wrote:\n>> \n>>>> If it's empty or 32 bytes, then that explains what status is reporting\n>>>> (but the question still remains how we got into that state).\n>>> \n>>> There's no .git/index file there:\n>>>\n>>>  $ ls -l .git/\n>>>  total 36\n>>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 branches\n>>>  -rw-r--r-- 1 tpo tpo    4 2010-05-23 21:36 COMMIT_EDITMSG\n>>>  -rw-r--r-- 1 tpo tpo   73 2010-05-23 21:36 description\n>>>  -rw-r--r-- 1 tpo tpo   23 2010-05-23 21:36 HEAD\n>>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 hooks\n>>>  drwxr-xr-x 2 tpo tpo 4096 2010-05-23 21:36 info\n>>>  drwxr-xr-x 3 tpo tpo 4096 2010-05-23 21:36 logs\n>>>  drwxr-xr-x 7 tpo tpo 4096 2010-05-24 09:26 objects\n>>>  drwxr-xr-x 4 tpo tpo 4096 2010-05-23 21:36 refs\n>> \n>> Thanks. That means \"git status\" is at least reporting the right thing.\n>> Now we just need to figure out why, when the strace of commit shows it\n>> being written and renamed into place, the index file is missing.\n>> \n>> I tried setting up a simple mhddfs mount to reproduce your problem, but\n>> everything works fine for me. What version of mhddfs are you using? I'm\n>> using version 0.1.28. I wonder if git is somehow triggering an mhddfs\n>> bug. Looking through the svn logs for mhddfs, between 0.1.27 and 0.1.28,\n>> there is a commit with message \"fixed rename bug\".\n>\n> Oh wow (trying to reproduce the bug just from the strace). It's mhddfs. Look:\n>\n> $ touch bla\n> $ touch bla.lock\n> $ echo asdf > bla.lock\n> $ mv bla.lock bla\n> $ ls\n> $ # nothing here\n>\n> That's a quite catastrophic bug in mhddfs :-((( ! Argh.\n>\n> Moving this over to mhddfs.\n\nOK, I'm waering sackcloth and ashes. The problem was a config fault of \nmine - one of the backing fs/partitions was included *twice* in the mhdffs \nfs setup in /etc/fstab. And as of now mhdffs doesn't detect a user \ncomposing the mhddfs filesystem in a braindammaged way.\n\nhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582888\n*t\n"}]}