Target volume not unmounting

[greengrass]

OS X 10.5.8, SD 2.6.1

I too have recently begun to see SD fail to unmount the backup drive (directly connected via firewire) after a successful scheduled backup. This used to work perfectly. I can't say for certain when it started but my guess is after upgrading to 2.6 or 2.6.1.

I just tried forcing a backup clicking "Copy Now" from the Scheduled Copies window. The target drive was not mounted when I started. The copy completed successfully, SD quit but the target was still mounted. I'm attaching the last few lines of the log which indicates a dyld shared cache error. Could this be part of the problem? Does the error message require action? If so, what?

| 06:36:21 PM | Info | PHASE: 3. After Successful Copy
| 06:36:21 PM | Info | ...ACTION: Making G4iMac Clone bootable
| 06:36:21 PM | Info | ......COMMAND => Blessing OS X System Folder
| 06:36:22 PM | Info | Successfully blessed Mac OS X folder on G4iMac Clone
| 06:36:22 PM | Info | ......COMMAND => Blessing OS 9 System Folder
| 06:36:22 PM | Info | Did not bless Mac OS 9 System Folder on G4iMac Clone because it does not exist.
| 06:36:22 PM | Info | ...ACTION: Updating prebinding on G4iMac Clone
| 06:36:22 PM | Info | ......COMMAND => Updating boot cache on '/Volumes/G4iMac Clone'
| 06:36:31 PM | Info | update_dyld_shared_cache[99606] current cache invalid because /System/Library/PrivateFrameworks/QuickLookUI.framework/Versions/A/QuickLookUI has changed
| 06:37:00 PM | Info | Successfully updated boot cache on G4iMac Clone
| 06:37:00 PM | Info | ...ACTION: Restoring Spotlight state on G4iMac Clone
| 06:37:00 PM | Info | ......COMMAND => Restoring Spotlight search indexing state on G4iMac Clone
| 06:37:00 PM | Info | Copy complete.

[dnanian]

No, that cache logging is fine... was this particular schedule deleted and recreated after installing v2.6.x?

[greengrass]

I deleted the schedule and created a new one when I updated to 2.6. I don't remember if I did it again when upgrading to 2.6.1.

My previous note said SD quit. That was a mistake on my part. It didn't quit, and shouldn't have, because I ran the scheduled backup from the Copy Now button while SD was open.

[dnanian]

OK: so, the drives are marked for eject, but won't eject until SD! is quit.

[msbc]

Originally Posted by dnanian

OK: so, the drives are marked for eject, but won't eject until SD! is quit.

Both my scheduled copies have 'Quit SuperDuper!' under 'On successful completion'

[dnanian]

Yes, but a scheduled copy leaves SD! in the state it was in, regardless of that value: it leaves the UI & application as it was found.

[msbc]

Originally Posted by dnanian

Yes, but a scheduled copy leaves SD! in the state it was in, regardless of that value: it leaves the UI & application as it was found.

dave,

Just to clarify:
1. SD! is not running when my scheduled backups start
2. The first backup (Data -> L1 Data) mounts and unmounts
3. The second backup (System-> L1 System) - 1 hour later - mounts but does not unmount.

Would it be worth swapping the order of the 2 schedules to see if it's the second backup not unmounting?