How to mountain AFP for backup target?

[Dewdman42]

I'm not sure what you mean by "backup on mount". Is that a SD feature I'm not aware of? Also I was poking around in launchd trying to find your existing SD schedules, but I couldn't find it.

[Dewdman42]

Looking around in the scheduler, I see the checkbox for "when you connect foobar to your macintosh". However it is greyed out. foobar is the name of the sparsebundle by the way, not the AFP volume.

[dnanian]

I know. Set it up to write to some local drive, just so you can see how we're doing it in launchd...

[Dewdman42]

I don't know, i have tried every conceivable possbile type of destination and always the backup on mount checkbox is greyed out.

[dnanian]

You've tried a local, directly connected destination that's ejectable?

[Dewdman42]

you didn't say ejectable before. Let me find a usb drive to try.

[Dewdman42]

ok, using USB let me do what you said. It created the launchd entry, which I look at, this entry seemed to indicate the following script get called:

~/Library/Application Support/SuperDuper!/Scheduled Copies/Backup on Mount.scpt

This appears to be a sym link to a generic script found in your application bundle

Backup on Mount.scpt -> /Applications/Utilities/Backup/SuperDuper!.app/Contents/Resources/Backup on Mount.scpt

Having a look at that generic script, I think the following line is probably the line I would need to call if I want to manually launch a backup job myself from launchd:

do shell script "env IMMEDIATE=YES open " & quoted form of POSIX path of (((scheduleFile as string) & ":Copy Job.app") as alias)

which works out essentially to calling this from the command line from within the folder where the scheduled script exists:

env IMMEDIATE=yes open Copy\ Job.app

Here's the question though, I don't know how to create this copy job to my network share without actually scheduling it. But I don't want SD to schedule it, I want to schedule it so that I can manually boot the AFP volume first. If I remove it from the schedule, then this copy job applet is removed and I can't launch it manually. if I leave it scheduled here, then it will be called twice, one of the times manually by me and one time by SD, which may or may not work depending on if the backup volume is currently mounted. Chicken or the egg problem.

How about if I modify:

Copy\ Job.applescript

to mount the volume, will that be ok? Any other suggestions?

If you had a way to provide a pre backup script that gets called BEFORE you attempt to check for the dest volume, then this would be a lot easier.

[dnanian]

Schedule it without actually setting a time OR backup on connect...

[Dewdman42]

or I notice there is a copy template inside your app bundle. Can I modify this:

on beforeRunningCopy()
	-- Put your own code here that should execute just before running the copy.

   do shell script"mymountcript.sh"

end beforeRunningCopy

Then create a new schedule and never worry about this again?

[dnanian]

Yes, but don't change the one in the app bundle; change the one in the scheduled copy bundle. Note that there's an on error and an on completion action, too. (I would have pointed you here, but you seemed to want to do it another way.)

[Dewdman42]

I'm not inclined to do it any particular way, just trying to make it work and hopefully in such a way that if I reinstall SD later I won't be scratching my head again trying to remember how to configure it again to do this.

I do notice however, when I manually launch your Copy Job.app inside the scheduled bundle, it is actually mounting the volume automatically without calling a pre script. I don't know why that doesn't happen normally when your scheduler launches it, but for some reason if I am able to launch it with the IMMEDIATE=yes from the command line, then the backup volume does get auto mounted.

However, when I tried to create a scheduled Copy Job without an actual schedule as you suggested, the Copy Job.app didn't get created. Its creates the bundle for it, but inside is only a Logs folder and sdss file.

The preferable solution would be to figure out why your Copy Job auto mounts when called immediate and fix it so that it will work when scheduled too. Next favorite solution is to have me schedule it myself to call your Copy Job.app IMMEDIATE=yes, but that only works if I can figure out how to even create that without also creating a SD schedule for it. The least favorite option in some ways is modifying the copy script because every time I change the schedule I will have to go in there and manually tweak that script. If I put it in the template then it would be good forever, as long as I'm always backing up to the same volume for everything. But all of those get lost if I reinstall SD. Fixing Copy Job.app to automount right is preferable solution.

[dnanian]

Check in your Keychain to see if the credentials for the mount are in the system keychain.

[Dewdman42]

I don't know man, suddenly now the auto mounting is working from your scheduler. I don't know why.

I will try that for a while and see if somehow I accidentally fixed it.

One question that might be related, I read somewhere else that AFP does not support more than one login id at a time. My Time Machine backup is going through AFP to my NAS with a different login id then what i use to mount shared AFP volumes. Its a ReadyNAS. They have it setup to temporarily mount a hidden AFP share using the id they want to use for it, then it backs up to a sparseimage there, then unmounts.

if its true that AFP can only support one login at a time (do you know?), then perhaps SD will fail to automount the AFP volume if time machine happens to be running at that moment?

[Dewdman42]

another possible solution might be to use launchd to monitor the dir where scheduled copy scripts do their logging. Then when a scheduled copy script starts to write to that dir, I can have launchd mount the volume for me.

But I dunno, it seems to be magically auto mounting now, so I will run with this for a while. maybe I needed to completely clear out the old scheduled copy script somehow... I dunno

[dnanian]

I don't know whether that's true or not, sorry (AFP). Sounds like it's working as it should now, though!