Incorrect # of ACLs
 

I've been using SuperDuper! for some time to smart-backup my iMac (G5 iSight) to a WD MyBook, but I've only recently started playing with booting from that drive and restoring the backup to the internal drive (in preparation for test-installing Leopard and iLife 08). During these last few sessions I've had to repair both disks because Disk Utility shows the error "Incorrect number of Access Control Lists" after backup/restore operations in both directions. The last time I repaired the internal drive after restoring from the external (using erase and copy), I noticed at the end of the repair that it reported there should have been 2 instead of 595454 (ACLs).

I know there is a check box in the advanced options for copying the ACLs during the backup, but I couldn't find a reference to this option in the user guide. It was checked by default. What does it do, and should I uncheck it?

Thanks for your help.

Try turning the ACL option off, actually. I'm not quite sure why you have ACLs on for your Tiger drive...

OK, I will, thanks for the quick reply.

The topic has been getting some discussion in several threads (here's one example) on the Apple forums.

Better put the hammer down, Dave, and get a Leopard-compatible version of SD out quickly before even more users foul up their backups and subsequently their boot drives when they clone it back.

You don't need a public relations mess on your hands caused by people using 2.1.4 with Leopard. Or at least, start hitting the forums and explain exactly what is incompatible. Your brief note on the home page that "SuperDuper! 2.1.4 is not yet fully Leopard compatible" (without specifics) isn't explicit enough to keep people from trying it anyway.

The above has nothing to do with Leopard, actually. Pointy Kitty's running with Tiger.

Using ACLs in Tiger for shared iTunes folder
 

Hi guys. I'm seeing this error ("Incorrect number of Access Control Lists") upon running Disk Utility on my backup drive. (Backing up an iMac G5.)

David wondered why anyone would have ACLs on their Tiger drive. In my case, it's because I'm using ACLs to control multi-user access to a shared iTunes folder, as explained here:

http://ad.hominem.org/log/2005/07/acl.php

AFAIK, I only have an ACL set up on one folder (/Users/Shared/iTunes).

I suspect that one ACL is not being copied properly, which means that if I boot from the backup the shared iTunes setup I have may not work properly. However, unfortunately I can't complete a full Disk Utility verification on the backup disk because it exits with the ACL error, meaning I don't know if any other underlying issues exist. (None are reported so far.)

I should be upgrading to a new iMac soon with Leopard, so I'll take my chances for now that the backup will work properly if the need arises.

Hope this extra information sheds some light on the issue.

Joe

Running 2.5?

Yes, 2.5. Should have mentioned that in the last post. :-P

The only thing I can suggest is that the ACL implementation/calls in Tiger are generally less reliable than those in Leopard... the ACL should copy fine.

I just started getting this error on one of my backups. In the past an erase and copy fixed it. I'm getting the same error when running a disk verify on the source and I have not restored from a backup. This means the target is just a faithful clone of the source (complete with ACL errors). I'm not sure if the ACL errors on the source were somehow caused by SD's calls to metadata copying (which wouldn't be SD's fault, but could be causing a tiger but to surface), or happened in some other way and SD is just innocently copying.

I'm going to have to bring the server off line to repair the source, then run an erase and copy to get back on track.

Here is a feature request for the future of SD, its not an easy one, but would ad huge value. It would be great if SD could verify the volume integrity as part of the clone. I don't mean just calling Apple's diskutil, I mean writing your own volume verification stuff and integrating it into SDcopy. This could be another option, with choices on what to do if problems are found (halt copy, repair, etc).

In my backup script I automatically run diskutil verifyVolume on the target after SD runs, but if there is some problem (like the above) I only know it after it has already been copied to my target. If the source is the boot drive, there is no good way to run verify or repair the volume prior to SD running.

I know that writing some disk utility stuff from scratch is far from trivial, and may well be considered outside the scope of SD, but you DO have good knowledge and understanding of the low level file system inner-workings, and I think it would add value to the app in that Users could no that the integrity of the backup was ensured (like repair disk permissions but X 10).

I was bit hard once by SD faithfully cloning disk errors that went unnoticed through my three week offsite rotation (I have SD run nightly, onto one of three disks that are rotated offsite weekly).

Sorry that I wandered off-topic.

-Preston

BTW, Tiger Server, SD 2.5 - plans to move to leopard this summer...

I really don't think that's a terribly practical thing for us to do, Preston: it's sort of what Disk Utility and Disk Warrior are for -- and Disk Warrior is quite well regarded in this space...

I never said it was practical :D

As I said, easily out of scope, and way more than I would want to tackle in your shoes. But there is no way to integrate DW practically into an automated backup routine.

Keep up the great work.

-P