A "public beta" mount/unmount surprise for you.

[dnanian]

Attached is a small preview from the next version of SuperDuper: a public beta of the new "schedule driver" that will automatically mount and unmount backup volumes without any manual intervention.

Note: the script will only automatically mount when you've got a backup directly targeted at a local volume. It does not handle the case where you have a sparse image stored on an unmounted local volume: at script time, I just don't have enough information to be able to handle that situation reliably. (Of course, SuperDuper! will continue to mount the intermediate volume automatically when you store the imag eon a network drive.)

Note that there may be some cases where identically named volumes don't work as expected: there's little I can do about that at present -- but this should improve most normal cases, while not degrading existing cases any further. (As you might expect, we never want to have regressions with a change like this.)

A small ZIP of the script is attached to this message. Unzip it, and then place the file inside SuperDuper!'s Resources folder, in the application bundle, replacing the one that's already there.

To get there, control-click on SuperDuper!, and choose "Show Package Contents". Then, navigate to Contents, then Resources, and there you'll find the existing "Copy Job Script.template".

Replace that with this one, and then (this is important) re-create your scheduled copies.

You can then unmount your backup drive, and it should automatically mount/copy/unmount if it's unmounted -- if mounted, it won't unmount at the end.

Enjoy, and let me know how it works for you.

[Pendragon]

Works as advertised on a DP 800/1.25 GB RAM, 10.4.6. Thanks Dave!

[dnanian]

OK, one success. That's good, at least!

[Michael@wengam]

This worked OK on my Quicksilver 733 Mhz PowerMac with 1 Gb RAM, OS 10.4.6, a Seritek/1S2 controller card and two 250 GB Hitachi SATA drives. A Smart Backup from the first partition on one drive to the matching partition on the other (originally unmounted) disk took 14 minutes to transfer only 300 MB of changed files out of 74 GB. After the backup the second drive got unmounted and the computer put itself to sleep. Just what I want! Thank you.

Q1: Is there an Applescript or something I can load as a startup item to automatically unmount the second drive for every day use unless SuperDuper calls for it?

Q2: I also want to automatically backup my laptop drive to a sparse disk image on the third partition of the desktop's startup drive. Is this the thing you are warning won't work? This partition is normally mounted anyway because it is on the startup disc. Following the instructions in the manual, I can have both computers scheduled to wake up at the same time, then SuperDuper will automatically connect to the desktop, mount the disk image and run a Smart Backup. SuperDuper on the laptop then unmounts the sparse image and sleeps the laptop, but it doesn't 'release' the file sharing connection to the desktop, and the desktop therefore will not sleep. As a result I find the desktop awake with all fans running the following morning and the laptop sleeping. My question is: how can I force the laptop to disconnect from file sharing to the desktop when the scheduled Smart Backup has finished? I suppose I could tell SuperDuper to completely shut down the laptop after the backup, but is there another way that would leave the laptop just sleeping?

[dnanian]

Hi, Michael.

If you want to create a little program that will unmount a drive, you'd use Script Editor to create an Applescript application with the following content:

tell application "Finder" to eject disk "the-disk-name"

Save that as an application, and then set it as a startup item.

For your 2nd issue, you can save a disk image to a local drive that's mounted, no problem. The case I'm warning about is that we won't mount/unmount the volume an image is stored on.

Finally, what you could do for your last issue is schedule the copy, then uncheck the checkbox. Locate the scheduled copy in the Library/Application Support/SuperDuper!/Scheduled Copies folder. Control-click the settings package there, and show package contents. Edit the "Copy Job.applescript" with script editor, and add an eject statement for the network job in the "after copy" area at the top. It'd look just like the above, but with the network drive name.

Save the script, then go back to SuperDuper! and double-click the entry in the Scheduled Copies window. Check the box, and we'll compile the script for you. That should do it.

[Michael@wengam]

Thanks, Dave. My applescript, saved as an application, ran without any visible result. But the Finder menu command "Eject volume-name" is anyway greyed out.

tell application "Finder"
eject "volume-name"
end tell

I can eject/unmount the volume by dragging its disk icon to the trash, however.

[dnanian]

For "volume-name", you want to actually substitute the name of the volume you're trying to eject...

[Michael@wengam]

I think I have done that in my actual script (where OSX_silver_B is one of the partitions I want to unmount):

tell application "Finder"
	eject "OSX_silver_B"
end tell

[dnanian]

If you just "run" that in Script Editor, does it eject the volume?

[Michael@wengam]

Nope. It remains mounted. Disk Utility and drag-to-trash are the only things that successfully unmount it.

I am curious why 'Eject OSX_silver_B", for example, is greyed out in the Finder's menu command. It is the same story for all my SATA partitions and two ATA drives working as a single RAID volume.

And, by the way, System Profiler 4.1.1 seems to know nothing of my two SATA drives. This is even though I am booted off one of them, and they get the full information breakdown in Disk Utility, where I partitioned them. In System Profiler, however, the two ATA drives running together as a RAID do appear under Hardware-->ATA; the SATA Seritek PCI card has a basic listing under Hardware-->PCI Cards; but under Hardware-->Serial-ATA I just see the phrase "No information found."

[dnanian]

OK. Internal partitions must not allow for simple ejection like this. What you'll have to do instead is crib from my script, and do something like:

		tell application "Finder"
			try
				set diskID to my getDiskIDByName("the-volume-name")
				
				if diskID is not equal to "" then
					do shell script "diskutil unmount " & diskID as string
				end if
			end try
		end tell

In your own script, copy my definition of "getDiskIDByName" and paste it in.

I don't know why it doesn't know about your SATA drive -- that's just weird...

[Michael@wengam]

I think I will need to learn more about AppleScript to understand and implement your suggestion -- my attempts so far failed.

[dnanian]

What did you try, Michael?

[Michael@wengam]

Er, I tried replacing "the-volume-name" with "OSX_silver_B", and I tried using 'eject' instead of 'diskutil unmount' -- I think they both gave compiling errors before I even got them into a script.

I noticed that the 'diskutil unmount' command does unmount my partitions when used in Terminal, so I played around with the following shell script, and sort of have it working as an executable Login item:

#!/bin/sh

diskutil unmount /Volumes/OSX_silver_B
diskutil unmount /Volumes/OS9_silver_B
diskutil unmount /Volumes/Backups_silverB
diskutil unmount /Volumes/OSX_silver_RAID

exit

Its a bit inelegant (leaves the Terminal window open). I sort of feel there must be a reason why people try to do this as an AppleScript.

Also I am wondering now if I really should explicitly define which partitions I want unmounting. Because, if I ever have to start up from a clone, I would rather mount the partitions on its disk and not mount those on the 'original' disk.

[dnanian]

That seems fine, Michael. My AppleScript uses diskutil/disktool to accomplish its task: AppleScript it used for ease of parsing, etc... but "do shell script" does what you'd think...