Suppressing OS X mount fail errors
I'm trying to set up CCC on my wife's MBP to emulate the behaviour of Time Machine, i.e. runs totally silently.
I've set it to back up every hour, on the hour, to my Linux box, disabled the CCC progress dialogues, disabled Growl notifications, and set it to e-mail me each time it completes.
Everything is working just fine and dandy except for one small niggle. If the Linux box is down, or her MBP is not on our home LAN, an message pops up saying the the server could not be found. The style of the dialogue makes me think that it's generated by OS X rather the CCC.
Is there anyway to disable this? I'm guessing that OS X is throwing this up in response to CCC calling the API to connect to the server.
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Mike Bombich on 20 Jul, 2012 01:22 PM
Can you submit your logs to me for review? The easiest way to do this is from within CCC:
A screenshot of this error message might be helpful as well. I think you might be right, I think it could be coming from the OS.
Thanks,
Mike
3 Posted by parish on 20 Jul, 2012 04:35 PM
Hi Mike,
Log submitted - CCC Report ID: 10576
Screenshot attached
Thanks!
Support Staff 4 Posted by Mike Bombich on 20 Jul, 2012 05:09 PM
Yeah, that's from the OS. I can see that CCC is automatically skipping the task without presenting the error (presumably as you requested in the Settings tab). Unfortunately, there's nothing I can do to suppress the OS's message. I really wish I could, too, in fact I'd prefer to not have the OS's UI involved at all (e.g. if you change your network volume's password, the OS will then provide a username/password prompt).
Mike
5 Posted by parish on 20 Jul, 2012 05:36 PM
Thanks for confirming that Mike. Shame though. Wonder how TM manages to avoid such messages if it can't find the backup volume? I guess it either uses undocumented APIs or it has it's own code for mounting volumes??
Anyway, it's not the end of the world, but if you're ever poking around in the UI code I think it would be good if you could figure a way to create a "Technophobe Mode" where CCC is (damn, that message just popped up again while I was typing this lol) totally silent. That is probably the only area where TM is better than CCC. It doesn't bother me, or anyone else who's chosen to use CCC I imagine, but when you set it up on a Mac belonging to someone who is completely non-technical it would be good if they don't have to interact with it at all. That's where an animated menu bar icon, like TM, would be useful; that way, I could place it next to the clock and just tell my wife "if that little thing next to the clock is spinning round, wait until it stops before shutting down your laptop" - simple.
P.S. An idea for an icon - three C's inside one another and for animation have the inner one rotate clockwise, the centre one static, and the outer one rotate counter-clockwise.
6 Posted by sn on 03 Aug, 2012 06:53 PM
I hate to throw this in the ring, but Chronosync has that functionality; it just silently skips the task when it can't mount a share. I used to have this running in conjunction with CCC (which I much prefer, actually just bought a licence). Leaving it to Chronosync to try to mount the share, and CCC to do the actual copying when the share appears.
Me too I'd love it if that OS error message didn't come up!
Support Staff 7 Posted by Mike Bombich on 04 Aug, 2012 02:19 AM
CCC has this capability, and I believe that parish was using that (the option to "Silently skip this task if the source or destination is unavailable"). The problem is that CCC is trying to mount the volume at all, and that that attempt is failing. Within CCC, I'm not presenting any UI indicating that mounting the volume failed, the UI comes from the OS.
There is a workaround -- I could simply not try to connect to the server if the network connection is down. But this counters the paradigm that developers are encouraged to follow:
success = "Try the task"
if (!success)
// Deal with the error
vs:
try = "Might this task succeed?"
if (try)
// Try the task
The problem with the second paradigm is that things are constantly changing, and it's possible that by the time you get to the "try the task" phase, the conditions have changed and the outcome will be different from what you expect (I know that seems unlikely in this trivial example, but this is the basis of a "race condition" (http://en.wikipedia.org/wiki/Race_condition) and it's actually quite common). Long story short, we've learned to not make assumptions, rather to try to do something, then gracefully deal with the error if it doesn't succeed. Unfortunately, in this case, the application that isn't dealing gracefully with the error is the OS, not CCC.
Getting more specifically into network connectivity, things are even less cut-and-dry. For example, I can't just ask the system, "Do I have a network connection?" because the answer is "it's complicated". Instead, I get a list of "flags" that indicate the characteristics of the network connection:
kSCNetworkFlagsTransientConnection
kSCNetworkFlagsReachable
kSCNetworkFlagsConnectionRequired
kSCNetworkFlagsConnectionAutomatic
kSCNetworkFlagsInterventionRequired
kSCNetworkFlagsIsLocalAddress
kSCNetworkFlagsIsDirect
Some of those indicate that you have an active connection, others indicate that it will work if you try. Oh, and these don't actually say anything about the network connection per se, they're actually referring to whether you have a route to a specific host. So if you have a source on the local LAN and a destination across the Internet, things are yet more complicated.
Anyway, my point in all of this is that you could go to great lengths to make a guess about whether you'll get a connection to a network volume, but there's a chance you'd be wrong and not attempt a connection when it would have worked.
All that said, I can offer a compromise. I used to do the network connectivity check in the past. After years of "don't do that" at Apple's developer conferences, I finally changed that behavior about 18 months ago. Bringing it back was trivial. In the attached version of CCC, you can do the following to get the old behavior:
Let me know how that works for you.
Thanks,
Mike
8 Posted by sn on 04 Aug, 2012 01:10 PM
Hi Mike,
many thanks, much appreciated. I'll check it out!
Best,
sn
9 Posted by DK on 19 Sep, 2012 10:09 AM
This comment was split into a new private discussion: Suppressing OS X mount fail errors
Hi,
We have the same concern. We would like to use CCC for our users' (about 50) laptops to backup to our internal AFP server. Typically most people take their laptops home and having the OS X dialog pop-up 1/hr would get old quickly. So they'll be on a network, just not the right one.
A work around we have begun testing is to set the scheduled task to not start until way off into the future (years), then we have a launchd script initiate the task every hour. The script tests a couple of things to verify that it's on the proper LAN, then if everything checks out, it runs the task with the custom CCC kill signals (i.e. kill -USR2 $cccPID). We followed the Automator script posted in other threads.
An example test is to ping the AFP server via the bonjour name (e.g. afpserver.local) this shouldn't work if you're not on the correct LAN. We're starting to see if we can use 'nc' to test for connectivity to the open AFP port. ( /usr/bin/nc -z afpserver.local. 548 ) While this is not 100% reliable, we think it's okay for us. It's also a little ugly and would much prefer to have CCC handle everything by itself.
Would it be possible to build into CCC a check to see if the AFP (or whatever) share is up before trying to mount it? I know for instance 'mmap' has some scanning scripts they use to discover what AFP shares a server has available. (Sorry, I just know it exists, not how it works.)
Thanks!
Mike Bombich closed this discussion on 19 Sep, 2012 05:22 PM.