Target volume not unmounting

[dnanian]

Is it consistent in its failure? That is, does it always fail to Daily/Weekly/Monthly but not for others?

[Michael@wengam]

Not sure I understand the question. These three schedules are the only SD! backups I run to real internal hard drives. And all three now leave their target drives mounted after the SD! run.

My drives are actually called OSX_metal, Daily_OSX_metal, Weekly_OSX_metal and Monthly_OSX_metal

They occupy the four hard drive bays of my MacPro

[dnanian]

Ah, internal drives. OK, quite different, and will look at it. I think we actually disable eject of drives that do not indicate they're ejectable in Finder (no eject symbol).

[Michael@wengam]

I guess I could also run the same 'unmount drives' script that I run at login, after the SD! run (actually, it is an AppleScript that calls a Unix command). But I get confused by having pre- or post-run scripts, especially updating schedules, and I would prefer if the application could do this natively.

[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.

[msbc]

Originally Posted by dnanian

Ah, internal drives. OK, quite different, and will look at it. I think we actually disable eject of drives that do not indicate they're ejectable in Finder (no eject symbol).

Dave,

Ahh, this might be the cause. My drives are external connected with eSata - so they don't show as ejectable in Finder - they have to be dragged to Trash to unmount. Did you change this unmount logic because it did previously unmount my eSata drives.

[dnanian]

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

[dnanian]

The eject logic was moved internal to SD, and is pickier about what it will and won't eject. I've logged a bug against it for internal drives (and eSATA is likely treated similarly).

[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'

[msbc]

Originally Posted by dnanian

The eject logic was moved internal to SD, and is pickier about what it will and won't eject. I've logged a bug against it for internal drives (and eSATA is likely treated similarly).

Thinking about it now, this may not be the issue. Both my scheduled backups are to the same eSata external drive - each a separate partition - and the data backup unmounts. The system backup does not.

[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?

[dnanian]

Well... if the first backup mounts and unmounts, that means that SD! quit when it was done with that copy. The second backup ran entirely after the fact... and SD! was open when it completed?