#!/bin/sh
osascript "/Library/Scripts/Eigene Scripts/DropDMG.scpt"
and give it execute permission. The first one uses DropDMG’s command-line tool. The second one runs the AppleScript that you already created.
Use Automator.
Update to Mac OS X 10.5, which lets you save an AppleScript as
a shell script.
The DropDMG app. is placed in a subfolder of the application folder. Does it have to be right in the application folder?
Thanks Michael for your instructions! I opted for #2 b): shell script in conjunction with Applescript and that worked - well only once…
Although I still got an error message from SD!: “Failed to run shell script…” SD! on that first attempt created the sparseimage (which was created from scratch - on an empty external volume) and successfully handed over to DropDMG which then created the compressed, encrypted dmg. By Setting “Always run with root access” and “Quit when done” within DropDMG the whole process ran automatically. DropDMG was activated and successfully created the compressed, encrypted dmg. The log in the main window of DropDMG pointed out: 24.07.08 17:11 Converted to “BackUp_Mozy.dmg”.
Both the sparseimage created by SD! (1.27GB) and the dmg created by DropDMG (1.15 GB) sat side-by-side on the partition “Archiv 2” of the external drive.
When I afterwards tried to “smartupdate” the sparseimage using SD!'s built-in script to incrementally backup (or rewrite) the sparseimage (which is meant to be part of my future auto-backup-procedure), I got the following error-message: “Failed to run the shell script dropdmg” and the SD! logfile pointed out the following error:
| Error | 2008-07-24 17:48:02.014 osascript[3827] *** _NSAutoreleaseNoPool(): Object 0x334390 of class NSPathStore2 autoreleased with no pool in place - just leaking
By the way, I tried the smartupdating twice, just to make sure I didn’ get a onetime error and got the same error-report on the second attempt, too.
Will the shell script (and the associated Applescript) prompt DropDMG to overwrite an existing, previously created dmg which is still in place?
Sorry to trouble you again but I’m somehow still a little stuck here…
When I afterwards tried to “smartupdate” the sparseimage using SD!'s built-in script to incrementally backup (or rewrite) the sparseimage (which is meant to be part of my future auto-backup-procedure), I got the following error-message: “Failed to run the shell script dropdmg” and the SD! logfile pointed out the following error:
| Error | 2008-07-24 17:48:02.014 osascript[3827] *** _NSAutoreleaseNoPool(): Object 0x334390 of class NSPathStore2 autoreleased with no pool in place - just leaking
This might be due to a bug in osascript. Please try the other shell script that I suggested.
Will the shell script (and the associated Applescript) prompt DropDMG to overwrite an existing, previously created dmg which is still in place?
No. DropDMG never overwrites an existing file that has a different name than the source image.
I think I’m doing something fundamentally wrong here. I just can’t get this to work.
I’m utterly sorry to keep you busy with my problem and very much thank you for your patience!
I used the shell script (2.a) as you suggested but keep getting an error message from SD! once the sparseimage has been smartupdated.
In order to make sure I’m not messing up anything with the script, here is how I proceeded about creating the shell script:
Open textedit and create new file
#!/bin/sh
1. dropdmg --config-name "BackUp_Mozy" "/Volumes/Archiv 2/BackUp_Mozy_DiskImage.sparseimage"
in there
Save the file as “dropdmgmozy” without extension
Open Terminal and write
chmod +x /Library/Scripts/Eigene\ Scripts/dropdmgmozy
then Enter to give the file executable permission (I dragged the file into the Terminal and made sure there is a blank between the x and the first / )
Open SD! and attach the shell script in the advanced option pane “Run shell script after copy completes”.
When I run SD! with the smartupdate option to update the sparseimage that already exists on the volume “Archiv 2” of the ext. HD, SD! incrementally updates the sparseimgae but gives me an error-message at the end that states “| Error | /Library/Scripts/Eigene Scripts/dropdmgmozy: line 2: dropdmg: command not found”
Odd enough, DropDMG is executed (I made sure the app. was closed when I started the SD! smartupdate) but doesn’t create the dmg as set in the shell script.
By the way I plan to erase the dmg that has been created by DropDMG with a Hazel rule once it has been updated to the online backup server in order to make sure the dmg will always have same name thus keeping the whole process automatic. That in fact means I’ll be using 4 pieces of software (of which DropDMG, Hazel and SD! are truly fantastic applications) to fully automate the procedure 
When I run SD! with the smartupdate option to update the sparseimage that already exists on the volume “Archiv 2” of the ext. HD, SD! incrementally updates the sparseimgae but gives me an error-message at the end that states “| Error | /Library/Scripts/Eigene Scripts/dropdmgmozy: line 2: dropdmg: command not found”
It sounds like you need to choose Install “dropdmg” Tool from the DropDMG menu.
Odd enough, DropDMG is executed
That is odd. Given the above error, I would not expect it to launch DropDMG. Are you sure you don’t have another script that did that?
I installed the DropDMG tool and checked in the Terminal wether it is available… Seems o.k. to me (see png).
I still get an error message from SD!:
| Error | 2008-07-27 23:39:23.775 osascript[4964] *** _NSAutoreleaseNoPool(): Object 0x3347a0 of class NSPathStore2 autoreleased with no pool in place - just leaking
Is the way I created the shell script (as I indicated above at #27) proper ?
in a minor state of despair
| Error | 2008-07-27 23:39:23.775 osascript[4964] *** _NSAutoreleaseNoPool(): Object 0x3347a0 of class NSPathStore2 autoreleased with no pool in place - just leaking
What happens if you execute dropdmgmozy manually from Terminal?
Is the way I created the shell script (as I indicated above at #27) proper ?
I think so.
When I exec dropdmgmozy manually from the terminal I get a whole bunch of “just leaking” reports (see png).
However, DropDMG is executed and writes the dmg.
Apparently there is something wrong with my shell script which in turn keeps SD! from executing it and giving an error message instead.
When I exec dropdmgmozy manually from the terminal I get a whole bunch of “just leaking” reports (see png).
I think those are the result of some third-party drivers that you’ve installed, the Logitech Scroll Enhancer.
Apparently there is something wrong with my shell script which in turn keeps SD! from executing it and giving an error message instead.
It shouldn’t be necessary to use “exec”. You should be able to just enter “/Library/Scripts/Eigene\ Scripts/dropdmgmozy” in Terminal. Perhaps it would help to put the full path to “dropdmg” in the shell script, i.e.:
#!/bin/sh
/usr/bin/dropdmg --config-name "BackUp_Mozy" "/Volumes/Archiv 2/BackUp_Mozy_DiskImage.sparseimage"
Although I would think that /usr/bin would already be in SuperDuper’s path.
Michael,
thanks so much for your investigation and the link to apple discussions! I’d probably have never found out about this malbehaviour of the Logitech Software by myself.
I knew the Logitech Software had its glitches and that a lot of people complain about it - but that it even corrupts scripts is downright outrageous.
I am using a Logitech keyboard/mouse combo of which both devices depend on the software. If I was going to use Steermouse or any other replacement I had to switch my keyboard too (which I actually like a lot - at least more than Apples keyboards).
I guess I will have to check out a replacement for the keyboard, uninstall all Logitech drivers and then get back to the backup wokflow issue (which will then probably work flawlessly).
Once again thanks a lot for your elaborated and patient support!
BarryWood:
One thing to be wary of is that if you have updated DropDMG, when your shell script attempt to run you will get a dialog box asking you if you wish to grant keychain access the new version of DropDMG. If this happens your automated backup will stall.
DropDMG 3.0 uses Mac OS X’s code-signing so that you don’t have to grant keychain access for each new version.
