(GUID partition scheme, BTW, the dual boot is with Linux and I’m using rEFIt to choose OS at boot-time, since Apple so kindly withdrew BootCamp Beta in that oh-so-typical let’s-renege-on-our-advertising -promises-after-all-they’re-only-customers style.)

The clone system boots and generally runs OK but a fair few owners and permissions were wrong, including the Unix sticky-bit flags missing from here and there, and there are infuriating issues with icon associations, including the following somewhat frustrating effect (which only appears to affect certain apps):

The icons for files associated with VLC have turned, mostly, into the blank “file” default icon.

If I use file…info to change the app associated with, say, an avi file, its icon changes, If I click “change all” it changes back to the blank one, and no others change.

If I have my original system disc mounted, via a caddy, as well as the clone, then the icons appear and behave properly. Clearly the cloning process has managed to preserve a very persistent association with the original VLC icon’s inode, or that of some or other icon cache, and I’ve been unable to track it down.

I’ve tried deleting various cache files, ALL .DS_Store and Desktop DB/DF files, restarting the finder, logging out, rebooting, all the rest.

This is only vaguely related to the brokenness of asr, and any suggestions about where to look for the relevant evil cache or whatever would be highly off-topic (but very welcome via a link to a separate discussion or something)

I’m getting increasingly pissed off with Apple’s poorly documented and bewildering mess of overt, hidden, semi-hidden, inaccessible and whatever meta-data, and it comes as no real surprise to me that Apple’s own tools don’t deal properly with half of it. While unsurprising, though, it’s very disappointing, especially as they KNOW about it and have done for some time.

My asr version is 72, Tiger 10.4.11, by the way.

I wonder if my original software disc is early enough to have a less broken asr on it, and if my problems might be fixed by using that to clone my old drive to the new one?

I created two disk images and put some files in the first. Then I used asr to copy the files from the first disk image to the second.

1. No extended attributes were copied.
2. No BSD flags were copied.
3. No locked flags were copied (which are just a type of BSD flag).
4. Symlink ownership was not copied.

And it really messed up the Symlink ownership. One of symlinks had the owner of rob:dummy. When the symlink was copied, it became root:rob. How it did this is beyond my comprehension.

Come on Apple. Why don’t you fix these long-standing bugs!

Geek to Live: Complete, free Mac backup

File copying/synchronization software and your metadata (and data!) | iNik

So can anyone comment on the current state of Apple’s backup utilities in 10.4.11 and 10.5.1?

I’m still on Tiger right now and I use Disk Utility for the majority of my backups, although I have been comparing them with Super Duper!, CCC, and Chronosync lately. I’m not sure which one is the best, though DU has been producing bootable backups.

Is Disk Utility’s New Image from folder option better than it’s New Image from Device option? I’m wondering what other people’s experiences are with creating a sparse disk image and using Finder to drag files into it. Btw, Filevault puts your entire home directory inside and encrypted disk image. In theory this would allow you to preserve all your metadata simply by copying the disk image to another drive. Also, you could simply try putting the majority of your files in disk images (encrypted or not) in the first place, and working from there. That should allow complete metadata preservation, at the expense of some inconvenience in having to wait for them to load.

Maybe the best thing is to simply avoid using the types of metadata which are known to cause problems until Apple fixes these problems.

Instead, asr in block copy mode (what you call dev mode) works flawlessly, fortunately. I’ve successfully copied my startup volume to an external hd with Disk Utility’s Restore function: to do that, I had to boot from Leopard’s dvd (as far as I’ve understood from the badly written asr man page, the source disk must be unmounted for block copy to take place), set my startup disk as source, my external hd as destination and check “Erase destination” (a further requirement for block copy to occur).

Another solution, which you do not mention, is that the suggested way (from man page) to backup a volume (or a directory) is to use “Image from Folder…” in Disk Utility to create a read-only or compressed disk image that can then be restored by asr. That uses hdiutil, which does a file by file copy (as per hdiutil man page). In my tests, however, inodes and creation dates are not preserved and, if a folder is copied, Spotlight comments at the top level of the directory hierarchy are lost (this is not an issue if a volume is copied).

My conclusion (I’d like to hear others’ experience with Leopard) is that asr is a very good choice for backups at a device level, provided that block copy is used. For data in one’s home directory, in my opinion the best idea is just to create a blank disk image and, in the Finder, drag and drop a folder into it. The Finder preserves everything but inodes and the BSD arch flag (permissions should not be a problem for one’s own data). Even if inodes change, Finder aliases are properly dealt with.

Btw, any chance to see an updated article for Leopard?

sudo asr restore –source / –target “/Volumes/Boot RAID” –erase

and asr quickly responds:

Validating target…done Validating source…done

The target volume will not be bootable. Continue anyway? [yn]:

and indeed creates a volume which is not bootable. Any ideas what’s up with this?

asr version asr: version 68

Also, is it then determined that asr device mode will copy all meta data?

$ asr -v asr: version 64.6 $ _

$ asr -v asr: version 66

best regards N