Why doesn't hdiutil command line for imaging the boot volume work anymore?

Question

Why doesn't hdiutil command line for imaging the boot volume work anymore?

I've used a command in this form for many years in various OS X versions to make a backup disk imageof my boot volume in sparseimage format. My boot volume's name is "Hard Disk".

sudo hdiutil create -srcdir / -format SPARSE '/Volumes/another_volume/Hard Disk Backup'

Now when I tried it in 10.6.6, the process began normally, the sparseimage file was created at the destination as expected and continued until the point where the image should have been finished, then the disk image disappeard and this error appeared in the Terminal window:

"2011-01-17 10:41:53.238 copy-helper[654:903] copy error (canceling): /Volumes/Hard Disk 1/usr/local/bin/apr-1-config: Operation not supported
could not access /Volumes/Hard Disk 1/usr/local/bin/apr-1-config - Operation not supported"

Why did something called "/usr/local/bin/apr-1-config" need to be accessed?

What is causing this error? At what point in history did this operation stop being supported?

MacBook Pro 17 Inch Mid-2009, Mac OS X (10.6.4)

Posted on Jan 17, 2011 9:24 AM

Reply

Answer 1

Top-ranking reply

Kappy

Level 10

361,867 points

Jan 17, 2011 9:57 AM in response to Community User

Have you examined the man pages for hdiutil to see if the command has been changed since last you used it? I took a quick look, and it looked like srcdir was not shown, just srcfolder, but then you may have just been abbreviating.

Questions about Unix should generally be posted in the Unix sub-forum of OS X Techologies forum. This is really not the proper venue. I can ask the moderators to move it if you like.

Reply

Answer 2

Jan 17, 2011 10:10 AM in response to Kappy

Man says srcdir is a synonym. Yes, it's OK to move the post. Thanks.

Reply

Answer 3

Kappy

Level 10

361,867 points

Jan 17, 2011 10:15 AM in response to Community User

Will do. You may have better success there. I'm not a very knowledgeable Unix programmer.

Reply

Answer 4

Jan 17, 2011 11:45 AM in response to Community User

Have a look at the specified file itself, with the Terminal.app command:


ls -le@ /Volumes/Hard Disk 1/usr/local/bin/apr-1-config
ls -le@ /usr/local/bin/apr-1-config

The second will probably work, but... That file is something that appears to have been installed locally, and probably the Apache Portable Runtime?

And FWIW, that -srcdir switch is a synonym for -srcfolder on the hdiutil command.

Reply

Answer 5

Jan 17, 2011 8:42 PM in response to Community User

I now realize that this problem is an old issue which has emerged once again after quite some time. Existing in my nested /usr/local directories are symbolic links that appear to have some characteristic or characteristics that cause hdiutil to choke on them. If I manually recreate the symbolic links for a single directory inside /usr/local, and specify that as my "-srcfolder", the process is completed without error. Unfortunately, it's not the case that the symbolic links are broken. They aren't. They work just fine. So what I need is a script that will find all symbolic links in /usr/local and in subdirectories thereof, delete them and replace them with new ones. Or I need to find out exactly what difference exists between the symbolic links I create today using "sudo ln -s" and those that exist on my system inside "/usr/local" which cause the failure of "hdiutil create", then find a way to make the necessary modification to each of the troublesome symbolic links.

Reply

Answer 6

Jan 17, 2011 9:45 PM in response to Community User

Here's the result for a normal symbolic link (one that doesn't interfere with the hdiutil operation):

MYMAC1:local me$ ls -le@ /usr/local/bin/rec
lrwxr-xr-x 1 root wheel 18 Jan 17 19:24 /usr/local/bin/rec -> /usr/local/bin/sox

Here's the result for one of the problematic symbolic links:

MYMAC1:local me$ ls -le@ /usr/local/lib/libasprintf.0.dylib
lrwxr-xr-x+ 1 me staff 23 Sep 17 2009 /usr/local/lib/libasprintf.0.dylib -> libasprintf.0.0.0.dylib

Can I run removexattr() on my /usr/local directory with XATTR_NOFOLLOW enabled to correct the problem with these symbolic links? What would the precise command be? Thanks.

Message was edited by: llee

Reply

Answer 7

Jan 18, 2011 5:38 AM in response to Community User

I'd guess that those links aren't compatible with the folder-based sparse UDSP mechanisms, but then I'd also log a bug report to Apple here.

I'd likely next go to a sparsebundle format next and (failing that) switch to a -srcdevice copy here, given your use of +-srcfolder /+ and selecting the root directory.

I don't have the cycles available to dig through the +man hdiutil+ pages and the +hdiutil create -help+ pages and run some tests for these combinations. (I usually snag a copy via the DVD once in a while, and use mysqldump and related tools to target backups of specific areas of the server disks. Most of the client boxes use Time Machine, which eliminates the hassles for those.)

Reply

Answer 8

Jan 19, 2011 6:30 PM in response to Community User

Can't mark my own solution as the answer, I guess, but, nevertheless, this is how I solved it.

1. I borrowed an executable called "fsaclctl" from a Leopard system and placed it in /usr/sbin.

2. I ran the following command:

sudo fsaclctl -p /usr/local -d 2>/dev/null

Reply