You should not create a sparse file larger than the partition that it is contained in, or larger than the amount of disk space that you can reserve on the disk if the sparse file is going to grow. It would be possible to “recompact” a sparse file, but any utility that does that would need to make a new sparse file and do a copy of all the non-sparse blocks in the original file (which is going to require a lot of disk space for the target).

Sparse files are more useful for dumping out core dumps and kernel dumps where the memory segments are themselves sparse and therefore it is more efficient to represent the files on disk as being sparse. Those images would also not typically be written to after they were created and would not grow. As a unix system admin for the past 15+ years or so, the use of sparse files like this strikes me as being a bit goofy — although it does make creating the sparse bundle much quicker than needing to write out 100-200GBs.

Just keep in in mind that whatever argument you give it as a size, it will eventually consume, just not right away. This isn’t a problem, this is just working exactly as advertised if you understand what sparse files are and how they work.

You could try to resize the sparse bundle via Disk Utility or create a new, bigger sparse bundle and copy the files (although I’m not sure if this works).

My new hard drive (the one which has the sparsebundle on it and is attached to the AirPort Extreme) is 1TB. What is going to happen if my backups add up to the capacity? Is time machine expanding the capacity, up to the capacity of the drive? Or is it starting to delete old backups although there is 0.5TB still available on the drive?

Please help!

you mention that

“There is a possibility to reclaim unoccupied space via hdiutil. However, as Time Machine does not utilize it I will ignore this possibility here.” and “Regularly delete old backups in Time Machine manually and reclaim freed space via hdiutil. Most complicated but also the most flexible solution.”

would you have a hint as to how this is done? i.e. what is the terminal command to use to free that space? thanks a lot, as i am not very versed in terminal…

It sounds like the formula for calculating free space in a mounted
sparse image is flawed in Leopard. Instead of adding the free
space from the containing volume to the free space inside the
image, Leopard uses the _minimum_ of free space in the Volume
and the mounted image. I can imagine that the erroneous free
space calculation results in certain processes running out of
space when there is really enough space. Perhaps higher level software is using a correct free space calculation and then gets stopped while trying to write a file for which there is really enough free space. Maybe the lower level image management/driver code likely throws an error thinking there isn’t enough space?

Does this make sense?

My problems has to do with trying to maintain backups from two different desktop macs on the same hard drive which is network mounted via an Airport Extreme. Perhaps the free space showing in Finder is leading me to believe there is room for all backups while Time Machine thinks it’s out of space due to this free space calculation error?

10.5: How to delete objects from Time Machine backups
Wed, Nov 14 ‘07 at 7:30AM PST • Submitted by iGrouch
This is a something that Apple has hidden away, leaving some Mac users out there to go through all sorts of lengths to remove items from their Time Machine backups.

The solution is really easy, though.

Open time Machine. Go to the top level — the first window; the one with your hard drive. Navigate to the backup you want to delete and use the Actions menu (gear icon) in the Finder’s toolbar. It has an option to delete the backup. Also, when using the Actions menu, with a file or folder selected, there is an option to delete all instances of the file/folder from all backups.

While I’m glad the “new” software from Apple fixes the from the problem from this point forward, it’s not clear or likely that it will go box and update the free space to agree with the Capacity - Used = Free. In other words, despite deleting Time Machine bakcup files (/Backups.backupb//{folder1,…,folderN), when free space was down to 40 GB (on a 600 GB drive), with 200 GB of other files, the free space is still only 40 GB! This suggests not using a drive for Time Machine to keep any other data, at the least.

So I’ll find another drive on which to move the data I need (200 GB), reformat, and then think about using Time Machine again. While the visual part of Time Machine is a nice way to understand the timeframe backups, there’s no easy way to reclaim the free space or need to understand why, without some technical background.

Thanks very much for posting the findings, information, and fixes, and good news for those who want to continue using Time Machine. I’m now going to use a Time Capsule and not put anything else on it. If Apple had spent just a little more time testing these boundary conditions, instead of leaving it to the customer, we all may not have had to suffer the discovery and lost of time and data. Pushing out a complex feature like this without fully flushing out such a major problem is just silly.

Thanks for the clear explanation of how the sparse images make Time Machine delete all the old backups.

I’ve been running Time Machine against an SMB share for a while now (since the beginning of January) and this was my last outstanding issue. However, I was pleasantly surprised to find out that the latest Time Machine and AirPort Updates v1.0 fixes the problem. Apple have changed Time Machine so it now compacts the sparse bundle after it deletes each old backup.

Cheers,

Adam

Du solltest vor dem Artikel noch einen Hinweis auf die deutsche Übersetzung einfügen. Habe mich soeben durch das Englisch gekämpft und hernach erst den deutschen Artikel entdeckt.

Danke für die Infos!