I am new to mlbackup/rsync and the concept of hard links, so I am a little confused after creating a backup data set via mlbackup.

So here's the scenario:

I am backing up "folder A" to "folder B". Inside "folder A", I have file "X", "Y", and "Z"; each file is 5mb therefore "folder A" is 15mb in size. I run mlbackup and the files are backed up to "folder B" for the first time. Now "folder A" and "folder B" are 15mb each.

Without any changes to "folder A", I run mlbackup again. A new "folder B" backup is created. It reads 15mb again (in Finder, Mac OSX 10.8).

Now I know the new "folder B" is just hard links to the original data, so I go to terminal and did a du -sh folder B and it reads only a couple of kb. This is to be expected, right? So my first "folder B" is 15mb, and second "folder B" is a few kb.

Now my question is this -- in Finder, both "folder B" are 15mb each. So say if I wanted my "folder B" backups to be located in an external drive that only has 16mb of free space, what will happen? According to Finder, the total of the two "folder B" will be 30mb. But we all know in reality it is only 15mb (from first "folder B") plus a few more kbs (second "folder B")?

I know this is a pretty confusing question, but I really want to understand how it all works. Please let me know if there is anything I can clarify further.

2 Answers 2


That is the expected behavior. The Finder does not check if files are hardlinks or real files and just adds the sizes. You do get the correct sizes with du as you already discovered.

You can copy the backup folder to an external volume that way, but it will grow in size to what the Finder shows you as it is not capable of copying the hardlinks as hardlinks. You can use rsync (and I recommend using the rsync 3.0.9 that comes bundled with mlbackup as it will take care of all the HFS+ metadata, compressed forks and other stuff.)

To answer your question in full, yes you can end up with backups on a volume that will give you a total size in the Finder that is larger than the volume itself. This is a known limitation of the Finder.

The concept of hard links is simply explained. Think of a file as a dog. Each directory that contains that file has a leash to the dog's collar. A hard link is just another leash to the same dog. As long as at least one leash is connected the file stays. Once all the leashes are detached the dog runs away, meaning the file got actually deleted. When you delete a hard-link the file stays in the file system as long as at least one link is established.

FYI: mlbackup uses rsync with the --hard-links option top copy files and does get a full score on the backup bouncer test.

MacLemon (Author of mlbackup)

  • So as a follow up question -- if I decided to use the rsync that's bundled with mlbackup, how do I run it so that the OSX doesn't use the default rsync? (I believe if I just type rysnc anywhere in the terminal it will just run the default instead of 3.0.9?) And thanks for the detailed explanation, very helpful indeed! Commented Jul 17, 2013 at 11:09
  • You can run it like any other command by calling it's full path. /usr/local/maclemon/bin/rsync. If you like you can just make an alias for it, for example by putting this line into your shell initialization. alias mlrsync="/usr/local/maclemon/bin/rsync".
    – MacLemon
    Commented Jul 17, 2013 at 15:19

If you use a dumb copy tool then you will need 30MB.

If you use a smarter tool that preserves hard links, and your external medium supports hard links then you be fine ... probably (16MB is cutting it a little fine when you consider that file size is not equal to disk usage due to block-rounding).

A "smarter" copy tool might be rsync with --hard-links set.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .