Shirt Pocket Discussions

Shirt Pocket Discussions (
-   General (
-   -   Copy Fails in SDv2.1 due to ACL entries (

glenn 05-11-2006 06:58 PM

Copy Fails in SDv2.1 due to ACL entries
I've been attempting to clone an external drive with one volume that's used as a data drive for an OS X 10.4 Server. The Mac server is a PowerMac G4 dual 1.25GHz system running 10.4.6 Server.

About 2 weeks ago the SuperDuper Cloning process began failing with this error:

| 03:15:12 AM | Info | /Volumes/Data/FileServer
| 05:37:16 AM | Error | SDCopy(29569) malloc: *** vm_allocate(size=8421376) failed (error code=3)

Dave, the developer has told me the failures are most likely due to some bad ACL entries. When I reviewed the destination or (cloned drive's ACL entries) only about 50 to 100 folders at the top level had any ACL entries. All of the other cloned files had only standard Unix permissions. Almost all of the source drive's files and folders have ACL entries attached to them.

This external data drive has 400GB worth of data, several hundred thousand files and folders. So a couple questions for you:

Has anyone experienced this type of error when using a similar type setup? If so, how were you able to resolve it?

Note: I've ran DiskWarrior v3.03 on this external volume and Apple's Disk Utility and there were no directory problems found.

Thanks for any input you may have!

PS - SD works fine when cloning the boot volume on this system. Other than this problem I love the product and recommend it wholeheartedly!

prestonholmes 05-19-2006 08:06 PM

Seen this too
I've seen this exact problem. I'd have to do a complete copy with ACLs turned off, then restore that again to the main drive so that I knew it had no corrupted ACLs. Then I'd have to reset all the ACLs manually, then everything would work for awhile, until the same error would creep up.

In the end I gave up on backing up the ACL data, and have a prebackupscript that turns off ACLs, and a post backupscript that turns them back on (using fsaclctl).

I was just losing too much sleep with the files themselves not getting backed up because of this. I also have a cron task that emails me a commanline disk verify everymorning on the backup.


dnanian 05-19-2006 08:32 PM

Most of our users are successfully backing up with ACLs enabled. There are some combination of ACLs that are causing problems with the Apple-provided API that we used to copy the ACLs. It always manifests itself in this way.

In the vast majority of cases, the ACLs are clearly corrupt on the source (duplicated in a complex pattern, with many inherited groups), but in Glenn's case -- and I guess yours, Preston [I thought you had managed to find the problem] -- the API crashes with a memory error.

ACLs are brand new to OSX in Tiger, and it seems there are cases where the OS doesn't properly handle copying them. Unfortunately, we've been unable to reproduce the situation here, and it's quite rare, so it's difficult to nail down the exact combination of items that causes the API failure... frustrating for you and us, believe me!

prestonholmes 05-24-2006 08:56 PM

Well I'm wondering how many people are making extensive use of ACLs

SD is backing up a file share with home and group folders with about 100 users, we have group projects that require ACLs.

I'm guessing the reason this problem doesn't come up more often is because people just aren't using them extensively...

(the "solution" was the disable - like I said, it wasn't worth the anxiety of not having data backups to have ACLs backed up properly...)

For data backups, we've SD has been flawless.


dnanian 05-24-2006 10:28 PM

Understood, of course. It's frustrating for us, too. We recently found a memory leak while investgating the source code of one of the Apple APIs (it's nice to have the Darwin source available). It's a hard one to replace, because it's pretty low level...

All times are GMT -4. The time now is 07:10 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.