sparseimage can no longer be mounted by SD
 

I have a serious problem. My sparseimage can no longer be mounted by SuperDuper. However, it can be mounted by Finder. What is going on? Is it because I force-quit SD a couple days ago when I didn't want it to run a scheduled backup? The existing sparseimage is grayed out when I try to build a new backup script!

[Note: I tried to send this error report via SuperDuper and it was unable to. It asked if I want to send via my email app.]

| 09:42:26 AM | Info | SuperDuper!, 2.6.2 (87), path: /Applications/SuperDuper/SuperDuper!.app, Mac OS 10.4.11 build 8S165 (ppc)
| 09:42:26 AM | Info | Started on Mon, Jun 14, 2010 at 9:42 AM
| 09:42:26 AM | Info | Source Volume: SG Mac OS X, mount: /, device: /dev/disk1s12, media: WDC WD1600JB-00FUA0, interconnect: Internal ATA, file system: "Journaled HFS+", OS: 10.4.11 (8S165), capacity: 63.87 GiB, used: 55.37 GiB, directories: 149263, files: 731168, ejectable: NO, ACLs: Disabled
| 09:42:26 AM | Info | Target Image: /Volumes/Barracuda-1500GB/SG Mac OS X.sparseimage, name: SG Mac OS X
| 09:42:26 AM | Info | Copy Mode : Smart Update
| 09:42:26 AM | Info | Copy Script : Backup - all files.dset
| 09:42:26 AM | Info | Transcript : BuildTranscript.plist
| 09:42:28 AM | Info | PHASE: 1. Prepare to Copy Files
| 09:42:28 AM | Info | ...ACTION: Preparing SG Mac OS X
| 09:42:28 AM | Info | ......COMMAND => Verifying the integrity of volinfo.database
| 09:42:28 AM | Info | volinfo.database OK
| 09:42:28 AM | Info | ......COMMAND => Enabling permissions on SG Mac OS X
| 09:42:28 AM | Info | Refreshing Disk Arbitration ...
| 09:42:28 AM | Info | ......COMMAND => Verifying that permissions are enabled for SG Mac OS X
| 09:42:29 AM | Info | Permissions on '/' are enabled.
| 09:42:29 AM | Info | ...ACTION: Mounting SG Mac OS X
| 09:42:29 AM | Info | ......COMMAND => Preparing SG Mac OS X
| 09:42:29 AM | Info | ......COMMAND => Setting ownership and access modes for '/Volumes/Barracuda-1500GB/SG Mac OS X.sparseimage'
| 09:42:29 AM | Info | ......COMMAND => Mounting SG Mac OS X
| 09:42:32 AM | Info | /dev/disk6 Apple_partition_scheme
| 09:42:32 AM | Info | /dev/disk6s1 Apple_partition_map
| 09:42:32 AM | Info | /dev/disk6s2 Apple_HFS /Volumes/SG Mac OS X 1
| 09:42:32 AM | Info | ......COMMAND => Mounting SG Mac OS X
| 09:42:41 AM | Info | Waiting for SG Mac OS X to mount.
| 09:42:43 AM | Info | Waiting for SG Mac OS X to mount.
| 09:42:45 AM | Info | Waiting for SG Mac OS X to mount.
| 09:42:47 AM | Info | Waiting for SG Mac OS X to mount.
| 09:42:49 AM | Info | Waiting for SG Mac OS X to mount.
| 09:42:49 AM | Error | Failed to mount SG Mac OS X

Looks like you need to eject the image, open the /Volumes folder (with Finder's "Go to Folder" command) and remove the "SG Mac OS X" folder you'll find there (not a link/alias, but a folder).

Then, restart your Mac and try again.

OK, after re-selecting a grayed out sparseimage in the destination panel, I was able to re-create the backup script. SD mounted the problem sparseimage. Here's the weird thing: The destination sparse image no longer has a matching name. The number 1 is appended to the volume name. It seems that SD is still keeping track of the original sparseimage somehow.

I'll do as you suggested.

I just tried stopping the backup script while in its "preparing the target volume" stage. It gave me the warning "Stopping now will leave [Volume Name] in and unknown state." I am guessing my force-quitting of SuperDuper a couple days ago was the reason that the sparseimage could no longer be mounted by SD. Retrospect does allow one to both pause and quit a back-up session gracefully.

The "unknown state" warning is over, um, stated. It's trying to say that you won't know what has and hasn't been copied, that things won't be unmounted automatically, that copies with a midpoint result (e.g. a read-only image) will still have that partial product stored on the drive.

Dave wrote via email:

"Generally, force quitting programs when they're not actually unresponsive is unwise. But that wasn't really what was wrong here."

Well, then I wonder what did go wrong. Why did my SuperDuper backup script fail to mount my sparseimage? I tried it several times, even after rebooting. It was not a case of my external USB drive going offline, as far as I know. I hope the problem does not recur.

What was wrong was the bad mount point, as far as I can tell. That's why we needed to clear that up, above. Mount points, though, are managed by the system... not by us.