Re: Deletion of git repo causes incorrect block count on HFS+ case-sensitive

From: David Aguilar <davvid@gmail.com>
Date: Mar 13, 2013, 22:14 UTC
Message-ID: <CAJDDKr6q4kz0oFtukmnOc3heWyRS8TfgKjEkgNmqdZdMxEeENg@mail.gmail.com>
In-Reply-To: <B6ED348A-2168-42F5-B6EC-81D7E62805ED@me.com>

On Wed, Mar 13, 2013 at 11:45 AM, Ismail Tabtabai <itabtabai@me.com> wrote:

Show 5 quoted lines

> Hello,
>
> When I delete a git repo that I have cloned on my machine using 'rm -rf repo-name' I get an incorrect block count when I attempt a Disk Repair.
>
> I am running OS X 10.8.2 on a user installed SSD. The git version is 1.8.1.5.

This is not a git issue.

I would recommend inspecting your hardware; this could be a disk going bad.

There's not much git can do to fix a broken HFS+ filesystem or faulty hardware. If anything, it's an HFS+ / Apple bug, though that is less likely than a bad disk.

If you haven't already, you should probably start doing backups. I hope that helps.

Show 33 quoted lines

> Checking file systemChecking Journaled HFS Plus volume.
> Detected a case-sensitive volume.
> Checking extents overflow file.
> Checking catalog file.
> Incorrect block count for file pack-8c0dc1a398a22c58ea1eba09de3ee9d935ad1ea3.pack
> (It should be 4865 instead of 12244)
> Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack
> (It should be 5889 instead of 12245)
> Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack
> (It should be 6220 instead of 12245)
> Incorrect block count for file pack-286c1444bc32ee2ed0af1d15070e0e31f22ba0a8.pack
> (It should be 7937 instead of 12246)
> Checking multi-linked files.
> Checking catalog hierarchy.
> Checking extended attributes file.
> Checking volume bitmap.
> Volume bitmap needs minor repair for orphaned blocks
> Checking volume information.
> Invalid volume free block count
> (It should be 85306183 instead of 85282114)
> Repairing volume.
> Rechecking volume.
> Checking Journaled HFS Plus volume.
> Detected a case-sensitive volume.
> Checking extents overflow file.
> Checking catalog file.
> Checking multi-linked files.
> Checking catalog hierarchy.
> Checking extended attributes file.
> Checking volume bitmap.
> Checking volume information.
> The volume avicenna was repaired successfully.
> Volume repair complete.Updating boot support partitions for the volume as required.

It looks like it repaired itself.  bad blocks?

-- 
David