PDA

View Full Version : Bizarro script behavior


RobLewis
07-29-2005, 01:10 PM
I read the manual and wanted to create a script to back up my OS X Server mail data. So I started with the "Exclude all files.dset" script, then added commands to copy /var/imap and /var/spool/imap, which is where OS X Server Admin tells me that the mail database and store are located.

So I run the script (copying to a disk image), and while it runs a bunch of apparently randomly-selected filenames are displayed (none having anything to do wil mail), and when it's finished I open the disk image and it's empty.

So what the hey is going on here???

P.S. I have a sparse image of my boot drive, created by SuperDuper, on an external FireWire drive. Can I restore it by booting from the FireWire drive and running SD? Will permissions etc. be set correctly? If I need to convert it to an ASR-compatible image, how do I do that?

dnanian
07-29-2005, 01:59 PM
Hi, Rob.

I'd have to see your script to be sure, but it sounds to me like you might have put the volume in front of the directory name... if you could send the script to me at the support email, I'll take a look.

(The filenames displayed are the ones being evaluated, not copied -- don't worry about that. We've reworked the status display in v2.0 to be a lot clearer...)

Regarding the sparse image, yes -- you can restore it, no problem, using SD! or even disk utility. Permissions will be set properly, and you don't need to convert to ASR.

RobLewis
07-29-2005, 02:17 PM
Script on the way via email…

dnanian
07-29-2005, 03:15 PM
Great, Rob.

What I replied (via email, but this is for everyone's benefit) is that the script looked just fine. I think what's going on is the well-known Finder bug where it doesn't always show things that were copied "behind its back".

If you log out and in, relaunch the Finder or check in Terminal, you should see your copy actually worked.

RobLewis
07-30-2005, 12:49 AM
Well, actually, one problem turned out to be that one of my partitions is formatted as case-sensitive, which apparently SD! doesn't (yet) support.

dnanian
07-30-2005, 07:24 AM
We can copy case-sensitive volumes, Rob: SuperDuper! just doesn't run properly *from* a case-sensitive volume.

This bug is corrected in v2.0.

RobLewis
07-30-2005, 08:48 PM
We can copy case-sensitive volumes, Rob: SuperDuper! just doesn't run properly *from* a case-sensitive volume.

This bug is corrected in v2.0.

By the way, for what it's worth, Disk Utility refused to restore my sparse images. After I converted them to read-only images (in DiskUtil), they restored OK. Good thing I have a big auxiliary hard drive to work with.

And how's this for a totally misleading error message: I tried to restore an image of the Users folder and got the message "error 19—operation not supported by device". Guess what this REALLY means: Disk Utility apparently won't restore over an existing folder with the same name. I trashed the existing folder and it worked.

Sadly I couldn't use SD! for any of this because of the problem with starting it up from a case-sensitive drive.

dnanian
07-30-2005, 09:37 PM
Ah, that's probably because you didn't mount the sparse image (using Disk Utility) before trying to restore from its volume.

DMGs can be restored "directly", but Sparse Images need to be mounted first...

Very strange/interesting error from Disk Utility... ooof.

If you want to run SuperDuper! from a case sensitive volume, create a small sparse image that isn't case sensitive and copy SD! to it. Then, mount that image and run SD! from there...