Incorrect Number of File Hard Links.

The drive has malfunctioned and ideally should be replaced. You might choose to tolerate one such malfunction in the life of the drive. If the same thing ever happens again, replace the drive immediately. Meanwhile, make sure you have plenty of backups.

Not likely to be a disk problem. This error can be caused by the system not be shutdown correctly or if an application crashes or otherwise closes incorrectly.

A file on the disk can have multiple names or links to it. The file system keeps track of the total number of links to a file, the link count. When you run a file system check the actual number of names is compared to the link count if they don't match you get that message.

As long as Disk Utility reports that it was able to repair the link count you are good to go.

Regards

One of the misconceptions that circulate on this site is the idea that a journaled HFS volume can be corrupted by a forced unmount, as for example in a system crash or a power failure. This is false. With filesystem journaling, when the volume is remounted after a forced unmount, the directory is automatically repaired, and files are restored to their previous state, using redundant information (the journal) stored on the drive. This is very well established technology, and for all practical purposes, it always works, unless the journal itself is corrupt due to a hardware failure in the drive. So if the directory of a journaled volume is found to be corrupt, the storage device hosting the volume has thrown at least one unrecoverable hardware error.

People who don't understand journaling will tell you to repair the corrupt volume with Disk Utility (if possible), or with Disk Warrior otherwise, and then go on using the drive as if everything is fine. That might have been good advice years ago, before the introduction of HFS journaling, when it was common for volumes to be corrupted as the result of forced unmounting. Today, because forced unmounts no longer cause that kind of corruption, it's relatively rare – or should be – and when it does happen, the implications are different.

My opinion is that when a drive throws such a severe error that a volume directory not only can't be restored by journal replay, but also can't be repaired by Disk Utility, that drive should no longer be trusted with data. It should be taken to a recycling center.

But even if you do choose to go on trusting the drive, if you have backups, you shouldn’t try to scavenge the directory with Disk Warrior. You should erase the volume and restore the data from your backups. Doing that is faster, safer, and cheaper than using DW. DW should be reserved for those situations where there are no backups, and even then, the drive should still be erased, or preferably retired, after the data is recovered.

Deric Horn, the head of filesystem engineering at Apple, gave a presentation at WWDC 2012 in which he stated, with regard to journaled HFS (starting at offset 3:18 in the recording) "The journal means that you can pull power at any time, and your filesystem is still intact. The shouldn't be any data corruption or any volume corruption on that disk." You can hear that presentation by registering for a free developer account and going to this page:

WWDC 2012 Session Videos - Apple Developer

Look for "What's New In The Filesystem" near the bottom of the page.

If a poster on this site knows more about HFS than the Apple developer in charge of it, then Horn should be fired, and the ASC poster should get his job. Until that happens, I suggest you believe what Horn says.

The addition of journaling has changed the situation somewhat. Filesystems are not the same as they were 10 years ago let alone 35. When I can find the time I'll have to look at the video, wish there was a transcript for it would make things easier.

However I stand by the crux of my comments. A single fixable error, especially something like a file hard link count from fsck or Disk Utility is not something that is going to cause me to go out and swap my drive. If there are no other problems, nothing being logged to the syslogs, no system or application crashes, then it is safe to take a wait and see approach.

But each person has to find their own comfort level with these types of transient errors. What works for me could make someone else nervous. I can say that in all the time I've been at this following my advice has never caused me to lose data. But as I wrote each person has to find there own level of comfort.

mrsone,

You've gotten two very different answers to your problem with the disk check. Of course neither post addressed your primary issue, your system freezing.

I won;t bother offering any advice on that or on the disk situation as you say you will make an appointment with Apple to look into this.

Please post back the results of your dealings with Apple. I am really interested in knowing if the procedure now for any disk error is to replace the drive.

good luck

regards

Thanks for the update.

Keep an eye on the disk, monitor the console logs now and again to see if anything shows up.

You might want to try running Disk Utility's verify disk again in a week or so to see if that problem or any other pops up.

As for the freezing issue, glad to her it seems to be better. Again the console logs can be a help in this, If the system freezes note the time and then look in the logs for anything that might have been logged around that time.

good luck

regards

The very nice gentleman that I spoke to told me that basically it was a filesystem error related to software.

The very nice gentleman did not know what he was talking about, like most of the people who answer the phone for AppleCare.

I unexpectedly found myself with no space let on my SSD (MBA 2011 with 256GB SSD and Lion 10.9). I knew I should have about 30GB. Ran disk verify and got message "Incorrect Number of File Hard links". I did as iOS instructed and booted into recovery mode and ran disk repair. That appeared to work, but after rebooting I ran disk verify and the error remained. Tried it again and surprise, I got the same result. Disk Repair did not solve the problem, but it seemed to think that it had!

Having read Linc Davis comments, I was not very confident as I decided to try the very nice gentleman's advice at AppleCare given to mrsone. I reinstalled iOS and then reran disk verify. No message about hard links, but now I got "Invalid Directory Count, should be 44,292 instead of 44,293.

Ran Disk Repair and then verify gave the same message, but with a different number of diretories. Tried again and the number changed again - always differing by 1. It looked like I had lost 5 diretories. So I decided to complete the advie from the very nice gentleman and restored from a back up. I chose a TM backup from about 24 hours prior since I thought that would likely have rpedated the error and I knew I had modiied only one file in the interim and I was able to save a copy.

What a slow process. But just before the New Year blew in, I had a restored machine with no errors reported by disk verify. Very nice to finally get proof that the TM backups actually did work and will be there to rescue me! (Reminds me of a client in 1986 who had been diligently making daily tape backups, but when it came time to restore from them, discovered that the tape machine was defective and all the backups were blank. Good idea to check your backups periodically).

I'd also like to thank Linc Davis for his comments above on journaling. That gives me greater confidence in the Apple system and comfort over possible power issues.

...

As for the freezing issue, glad to her it seems to be better. Again the console logs can be a help in this, If the system freezes note the time and then look in the logs for anything that might have been logged around that time.

This is good advice.

I am a log junkie, and always have 'tail -f' running on a few log files in my screen session.

However, some months ago I was experiencing a similar freeze issue. It nearly always happened at night. There was nothing in the logs at this point; they just ended, and I had to do a hard power-off. I figured some OS or kernel bug, maybe triggered by the screensaver--that was usually frozen on screen if it wasn't blanked.

Then one time I was logged in from my linux system and had these logs running, and in the morning saw this:

Jun 21 23:14:39 original-mac kernel[0]: Failed to issue COM RESET successfully after 3 attempts. Failing... Jun 21 23:14:39 original-mac kernel[0]: disk0s3: no such device. Write failed: Broken pipe Sun Jun 22 10:44:08 EDT 2014 -- end ssh, with status 255

I replaced the hard drive shortly thereafter; no problems since.

When it loses contact with the disk, it's not going to log any messages...

If you start to suspect the disk, log your messages over the network.

(Hopefully you won't have any network problems.)

I had this issue too, my system is MacBook Air (13-inch, Mid 2013) SSD 256Gbs, OS X Yosemite 10.10.2.

The Disk Utility reported:

Verifying file system.Using live mode.Checking Journaled HFS Plus volume.Incorrect number of file hard linksChecking catalog hierarchy.Checking extended attributes file.File system check exit code is 8.Error: This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility.

I restarted with Command + R to have it fixed successfully, but this appeared shortly after normal using.

I went to Apple Genius Bar for help, them checked my hardware, found no problem, they helped me format and reinstall OS X Yosemite 10.10.2, the problem still appeared after returning home, then I disabled FileVault and decrypted the disk, restarted to recovery mode to fix again. Now it has been about more than12hrs from the the last fix, and it seems was fixed, and I wonder if it was caused by the FileVault, by the way I had Paragon NTFS for Mac installed, will this be a problem too?

Later, I will turn on FileVault to find out if it would appear again.

Thanks, Neffect. Worked for me.

As a note for future travelers: it is possible to "corrupt" filesystem from userland. This happened recently with fish shell and how it uses /tmp, see https://github.com/fish-shell/fish-shell/issues/1859

They've filed a bug with Apple and also here:

http://openradar.appspot.com/radar?id=6387155723091968

A quote from the thread:

"I speculate that whatever clears the contents of /tmp does it in a way that messes up hard link counts"

So in addition to hard drive failure this might a combination of OSX bug and the way some software use /tmp.

You are welcome, I'm Effect, This is my another ID, I came back to look for the help again, because I found it on my new Macbook pro, I believe it might be a OS X system bug, this problem still appears on my new macbook, it might be related to some of the apps I use, maybe some apps will trigger this bug. I called my friends who were using macbook to, they don't have this issue.

I think maybe you can keep an eye on it, run Disk Utility some time to be sure it does work for you.