ghost files

Carlos A. M. dos Santos unixmania at gmail.com
Mon Aug 15 01:49:50 UTC 2011


On Sun, Aug 7, 2011 at 3:08 AM, deeptech71 at gmail.com
<deeptech71 at gmail.com> wrote:
> as of recent times, some git rebase operations fail unexpectedly with
> an error: "cannot create .git/index.lock: file exists". an
> investigation session was something like the following:
> $ ls -l .git
> the index.lock file is not in the shown list.
> $ ls -l .git/index.lock
> the file is listed! it's a regular file, its size is ~60KiB.
> $ cat .git/index.lock
> some file content is shown.
> $ mv .git/index.lock .git/someplace
> moving fails with: index.lock: file does not exist.
> $ ee .git/index.lock
> some file content is shown, which i edit and save. then the
> .git/index.lock file really disappears (cat, direct ls, ee, mv, etc.
> do not find the file), and the content i put in the .git/index.lock
> file via ee is now in .git/index.
>
> H$X!!!!!111
>
> i still have some git rebase operations (which are notably
> disk-active) fail from time to time with "impossible" reasons (for
> example: something like "cherry picking failed", or something like
> "cannot move git-rebase-new to git-rebase-todo: file does not exist").
>
> i'd note that the hard drive is kind of old (>7 years), and i recently
> had the power cut during port build operations twice, although the
> (UFS) filesystem is fsck-clean.
>
> has anyone experienced anything like this?
> what is the possibility of a filesystem/kernel bug or fsck bug?

Do not start supposing that this is a filesystem/kernel bug so early.
I have seen similar mysterious messages @work, with Git servers
running on Linux, so I'm inclined to believe that it is a software
issue.

-- 
"The flames are all long gone, but the pain lingers on"


More information about the freebsd-current mailing list