Time Machine/HFS question

[David Mackler]

On Mar 4, 2008, at 7:57 PM, Justin C. Walker wrote:

> Thanks, Chris and David,
>> However, if a volume is accessed over the network (even if it is  
>> formatted HFS+) the client machines don't see it as an HFS+ volume  
>> but rather as an AFP volume (which does not support directory  
>> hardlinks or extended attributes). To get around this Time Machine  
>> creates a .sparsebundle disk image on the AFP volume containing a  
>> HFS+ filesystem. Time Machine creates its .backupd structure on the  
>> HFS+ filesystem contained within the mounted disk-image in that case.
>
> I think I'm still puzzled :-}
>
> From your first mail, Chris, it sounded like access to remote drives  
> is possible only when the server is 10.5.  In my setup, there are  
> two 10.4 systems, including the main server hosting the firewire  
> drive, and one 10.5 system.

TM only creates the .backupdb directory when directly connected on the  
client, not when network mounted.

> The only way the ".backupdb" could have been set up is when the  
> firewire drive was mounted on the 10.4 system, correct?

Yup.

> I only physically attached this drive to the 10.5 system for a few  
> brief periods, one begin before 10/29 (when I was trying to get the  
> drive to work :-}), and once a couple of weeks ago (post 10.5.2  
> upgrade).  There wasn't enough "connect" time in the first case to  
> create the 6 "2007-10-29-*" directories (they were apparently  
> created over a period of about 5 hours, based on timestamps).  Is  
> there a way to verify which system the drive was connected to when  
> these directories were created (memory being somewhat fallible :-})?

Perhaps, if I were able to still think clearly instead of merely  
reciting what I already know. I don't suppose you have a system.log  
that goes back that far, do you? That's the problem with memory  
crutches, isn't it. Without our crutches, well… ;-)

> As for the "sparsebundle", it is not a disk image, it's a real  
> directory.  Based on the timestamps on the "bands" in this  
> directory, it had to have been connected to a 10.5 system for quite  
> a spell, if I understand your comment (it can only be served from a  
> 10.5 system, and is used only to handle remote 10.5 clients).  Is  
> that correct?

Yes… and no. It's a wacky expansion of the sparse disk image. Instead  
of one monolithic file, the new leopard way is to create a directory  
of smallish files, that will mount as a single file-based disk image.  
In other words, they took the single file holding a sparse disk image  
and chopped it into pieces, keeping them all in a directory. The idea,  
I believe, that freeing empty space allows those band files to be  
deleted, so that a sparsebundle can not only grow, but shrink.

> If so, I'm really confused, because this firewire drive was  
> physically attached to the Mac Pro (10.4) during the period that  
> these "bands" were created.  I think I only once moved the drive to  
> the laptop (10.5), and then only briefly.

So yeah, those bands were created when it was mounted through the  
network.

You still have the mystery of how TM created that sparse bundle when  
hosted on a tiger server. It shouldn't happen (tm). well, unless you  
applied one of the various hacks floating about like flotsam and jetsam.


> Again, thanks for your explanations.  Is any of this documented?  I  
> checked ADC, but nothing obvious popped out (overviews and API  
> discussions were all I saw).

Heh. man hdiutil has a nice discussion of sparse images and bundles.  
Beyond that, I haven't a clue.