"Log Jam"

[dnanian]

You haven't really told me what's failing (the other logs, as I tried to say, are in the Logs folder you'll see when you Cmd+click the title bar; if there are no other logs, the problem occurs before we even get to run).

[Nick]

Originally Posted by tdenson

Well that worries me, why have I only got one log file then.
There is something very unintuitive about all this. I have been using SD for 3 years and in all that time I have never mastered scheduled copies. They always seem to fail even when I can run the same source and destination manually. This is true on 3 different machines I manage. I have given up trying to schedule and always run manually. Am seriously considering going elsewhere to find a product I can get to work.

I would agree with you that SD! isn't as easy to use as it could be. Despite the obvious effort put in to writing the User's Guide, it's not at all easy to figure out how to use SD!, beyond the basics. IMO, this is in large part due to what appears to be a shortcoming in a lot of design efforts: The Guide appears to have been written by someone who has a deep understanding of the product, but a much less better understanding of the more-general user audience—that is, an understanding of the perspective of the less technically experienced user. Imagine if you will trying to read an instruction manual for a kitchen appliance that was written by the engineer who designed the appliance and who assumes that the average home consumer understands—much less cares about—BTU, watts, grounding, RFI, and other technical considerations of the appliance's design. To the engineer, these terms and concepts may appear to be basic enough to throw around when discussing and explaining the appliance's operation; but for most consumers, that is a baseline level of understanding and familiarity that far exceeds theirs.

Having said that, I will quickly follow up with two comments;

1. This forum, and Dave's constant presence, more than compensate for any User's Guide shortcomings or unintuitive product usability: I have yet to experience user support that approaches the level provided here.

2. You will not likely find a competing product that is better—i.e., more effective, more reliable, less invasive, more current, and easier to use (yes, even if only at the most-basic level)—than SD!.

[tdenson]

Originally Posted by Nick

I would agree with you that SD! isn't as easy to use as it could be. Despite the obvious effort put in to writing the User's Guide, it's not at all easy to figure out how to use SD!, beyond the basics. IMO, this is in large part due to what appears to be a shortcoming in a lot of design efforts: The Guide appears to have been written by someone who has a deep understanding of the product, but a much less better understanding of the more-general user audience—that is, an understanding of the perspective of the less technically experienced user. Imagine if you will trying to read an instruction manual for a kitchen appliance that was written by the engineer who designed the appliance and who assumes that the average home consumer understands—much less cares about—BTU, watts, grounding, RFI, and other technical considerations of the appliance's design. To the engineer, these terms and concepts may appear to be basic enough to throw around when discussing and explaining the appliance's operation; but for most consumers, that is a baseline level of understanding and familiarity that far exceeds theirs.

Having said that, I will quickly follow up with two comments;

1. This forum, and Dave's constant presence, more than compensate for any User's Guide shortcomings or unintuitive product usability: I have yet to experience user support that approaches the level provided here.

2. You will not likely find a competing product that is better—i.e., more effective, more reliable, less invasive, more current, and easier to use (yes, even if only at the most-basic level)—than SD!.

Thanks for that reassurance

[tdenson]

Originally Posted by dnanian

You haven't really told me what's failing (the other logs, as I tried to say, are in the Logs folder you'll see when you Cmd+click the title bar; if there are no other logs, the problem occurs before we even get to run).

Currently, the only line on the scheduled copy window is red and there are no log files.

(few minutes later)
I have just set a scheduled backup to run two minutes hence, which it did successfully. But I have done this before - every time I watch a backup it works, however when unattended it never seems to happen. I got to wondering whether it's because the machine might be asleep, so I set another one to go in a couple of minutes and put the machine to sleep. OK, it didn't wake up the machine but as soon as I woke the machine up manually SD then ran it's scheduled backup successfully. All I know is whenever I try and do the same in the middle of the night it fails every time - and as I have said before on 3 different machines in 3 different physical locations.
I will persevere.

[tdenson]

Incidentally, having run two scheduled backups in the last few minutes I still have only one log file. What I did was to edit the scheduler entry to change the time of the backup - would this cause all previous log files for that entry to be deleted ?

[dnanian]

As is explained in the "Scheduling" section of the User's Guide, the backup will not run if the Mac is asleep. You would need to set a wake event for one minute before the scheduled copy time.

As far as old logs go, it's quite possible that changing the time will recreate the settings package and thus clear the old logs, yes.

[tdenson]

Originally Posted by dnanian

As is explained in the "Scheduling" section of the User's Guide, the backup will not run if the Mac is asleep. You would need to set a wake event for one minute before the scheduled copy time.

As far as old logs go, it's quite possible that changing the time will recreate the settings package and thus clear the old logs, yes.

But you miss my point. I said that the backup worked fine automatically after the machine was woken up without any intervention from me, but I'm not seeing that in practice.

[dnanian]

I understand you did say that, but I can't see how that could have happened, barring some event I'm unaware of: the backups will not occur if the mac is asleep, nor will they 'catch up' and run when the Mac wakes (unless they had started before the sleep, and then they'd continue at wake).

[tdenson]

I've just checked another of my machines and I think it is actually doing a daily backup successfully, however I can only see the one log file for the most recent backup. What am I missing with these log files ?

[dnanian]

Again, to see the other logs, should you need to see others, Cmd+Click on the title of a log and choose the logs folder... that will show the other runs of this settings 'file'.

[tdenson]

Originally Posted by dnanian

Again, to see the other logs, should you need to see others, Cmd+Click on the title of a log and choose the logs folder... that will show the other runs of this settings 'file'.

Finally, I see how to get other logs. However, it is not at all intuitive to have to drill down into one particular log to then get access to other logs. This is where I have been struggling. I've been cmd clicking the scheduled copies window instead, and I think this is also where Nick previously in this thread was having the same misconception.

[Nick]

Originally Posted by dnanian

Again, to see the other logs, ... Cmd+Click on the title of a log and choose the logs folder... that will show the other runs of this settings 'file'.

Right-clicking (Cntrl+Click) works as well.

[sjk]

I suspect/hope "improved logfile management" is already on the list for possible future SD! releases. Access to anything but the current logfile requires more tech-savviness than I'm sure plenty of customers have.

[Nick]

Originally Posted by tdenson

Finally, I see how to get other logs. However, it is not at all intuitive to have to drill down into one particular log to then get access to other logs. This is where I have been struggling. I've been cmd clicking the scheduled copies window instead, and I think this is also where Nick previously in this thread was having the same misconception.

Yes indeed, it's not at all intuitively obvious. The difficulty is (I believe) that while this way of gaining access to the location logically follows from the application's technical design, it's not a user-friendly approach. IOW, another layer (GUI) between the app and the user, designed from the user's perspective, would be helpful.

[dnanian]

No, not really. In general, most users don't need to get at these other logs, which are usually used for diagnostic purposes. A non-technical user doesn't generally need to review them.