Restore/Address Book Issue

A file level "Restore" failed with this error:

Code:

[...]
2010-12-13 03:40:52 -0500: Copying    
2010-12-13 03:53:04 -0500: could not copy /Volumes/HD 1/Users/artie/Library/Application Support/AddressBook/Address Book - 2010-09-19.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.abbu/Address Book - 2010-08-05.a; File name too long
2010-12-13 03:53:04 -0500: Bom copy exited with error 63
2010-12-13 03:53:04 -0500: 
2010-12-13 03:53:04 -0500: Could not restore - File name too long
2010-12-13 03:53:05 -0500: Could not restore - File name too long
2010-12-13 03:53:05 -0500:

The file that I assume is the one over which Disk Utility is tripping, though, shows in Finder as ~/Library/Application Support/AddressBook/Address Book - 2010-09-19.abbu, and Carbon Copy Cloner, on the other hand, has no problems with it.

Has anybody got a clue what the "extended" file name is about and, perhaps, how to "correct" it?

Edit: Hold everything... I just discovered that that file is an expendable backup generated from Address Book > File > Export > Address Book Archive.

I'll report back after I delete it and try the "Restore" again.

Remarkable...

I trashed the offending file, created a new backup, and tried to "Restore" again...

Code:

2010-12-13 06:54:44 -0500: Copying    
2010-12-13 07:07:44 -0500: could not copy /Volumes/HD 1/Users/artie/Library/Application Support/AddressBook/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.abbu/Address Book - 2010-12-13.a; File name too long
2010-12-13 07:07:44 -0500: Bom copy exited with error 63
2010-12-13 07:07:44 -0500: 
2010-12-13 07:07:44 -0500: Could not restore - File name too long
2010-12-13 07:07:45 -0500: Could not restore - File name too long
2010-12-13 07:07:45 -0500:

This time, though, the dates are all the same.

Time for a bug report, I think?

Trashed the offending file and the "Restore" completed with no problems.

As you've already discovered, the ".abbu" filename extension stands for "Address Book BackUp". Address Book makes a backup by duplicating the folder ~/Library/"Application Support"/AddressBook, giving the duplicate a name ending with ".abbu", and marking the duplicate as a package (so that Finder will display it as if it were a single file).

The "long" filename shows that you stored an Address Book backup inside the folder that it's supposed to be backing up. The first time you did that (on 2010-08-05) you got away with it, but the second time you did it (on 2010-09-19) the backup you created contained a backup of the previous backup.

That left your AddressBook folder with four copies of the address book data: the current in-use copy, a backup as of 2010-09-19, and two backups as of 2010-08-05. Do that again, and you'll have 8 copies of the data. The size of your AddressBook folder would double each time you made another backup. Pretty soon we'd be talking about huge amounts of disk space.

It's possible Address Book noticed the self-reference, and started making soft links to the previous backups rather than actually copying them. That would keep the disk space manageable, but appears to have created a link loop: a soft link pointing to itself or its parent.

When Disk Utility tries to copy such a link, it apparently fails to detect that it's a loop, and barfs. This merits a bug report to Apple. They can't fix it if you don't tell them about it. Other utilities either don't try to follow the link, or detect the loop and deal with it.

But in the meantime, your root problem is storing Address Book backups inside the AddressBook folder you're backing up. Move those .abbu files elsewhere (perhaps to the big bit bucket in the sky?), and in future find a more appropriate home for those backups. (I created a folder ~/Documents/Backups for holding AddressBook, Calendar, and other backups of this nature. Your predilections may differ.)

If you do keep the old backups, open each one (by selecting "Show Package Contents" from the contextual menu) and look for any nested backups (or aliases to same) and delete them. Or hide the problem by zipping up the backup (by selecting "Compress filename.abbu" from the contextual menu). But deleting these old backups may be simpler.

Great response; thanks!

I guess shouldn't have to do it, but I'll relocate my "storage bin." (Don't use the "cloud," though.)

> It's possible Address Book noticed the self-reference, and started making soft links to the previous backups rather than actually copying them. That would keep the disk space manageable, but appears to have created a link loop: a soft link pointing to itself or its parent.

> "open each one (by selecting "Show Package Contents" from the contextual menu) and look for any nested backups (or aliases to same)"

I was able to "Show Contents" of the 2010-12-13 backup, the one DU choked on most recently, 20 layers deep (at which point I quit trying)...your link loop, I guess.

Actually, though, the 2010-12-13 backup is an original...created after I trashed the one with 9-19 and 8-05. (It weighs in at twice the size of the original of which it's a backup.)

I've got documentation, so I'll file a bug report.

Edit: Bug report filed.