PDA

View Full Version : Sparseimage date anomaly; Do sleeping Macs work? & UI suggestions


DrDan in MA
02-11-2006, 03:29 PM
OK it's grab-bag time :)

I have a PB (running Panther 10.3.9) with a hardwired ext HD with 2 partitions, one of which I use as the repository of a sparseimage file being deposited there from a copy of SD! writing across the LAN from a Mac Mini (MM) running Tiger (10.4. 4).

WHen I look at the LatestMMbackup.sparseimage file from my own PB/Panther, it shows the date of a full backup ofthe MM (which was first done yesterday AM) and a size (say. 12 Gb at that time). From the Tiger machine looking across the LAN at that same ext HD partition running on my Panther, and after a SD! run from say, 5:17AM earlier this morning, that exact same LatestMMbackup.sparseimage file shows a date of 5:17AM and a size of 13Gb, reflecting the Gig of docs and apps that we added to that hard disk yesterday. Strange. The SD! log on the MM matches the time that the backup was done. The important thing, I guess, is that when the MM is where we're looking from, we can verify the time of the last backup from the Finder level.

Still it would be nice to be able to verify time-of-latest-write from the Panther box, which was the target of the over-the-LAN backup from Tiger. Any thoughts on why Panther doesn't follow suit with Tiger on this?

(This may simply be a result of OSX-version conflict, with Tiger being "better" than Panther.)

=====

Next: I searched the manual and this BBS for where I read something about this, to no avail -- I just couldn't recall the key words that I thought must have been used. So please pardon any repetition.

I'm probably not the first to note a corollary to the need to "wake up" the Mac prior to a scheduled SD! run. That all has been working fine, but last night I tried a little experiment on the MM, which has two accounts. Using my own acct there, I scheduled a machine wake-up at 0329 and an SD! backup over-the-LAN of the MM's entire HD to begin at 0330. I then switched contexts to my wife's account and went to bed.

In the morning, to my not-too-great surprise, the hoped-for backup out of my account had not taken place. This was, I believe, because that process was asleep at the time. I have no way of knowing whether the machine "woke up" at 0329 but I do know that the SD run that I had scheduled in MY process (that was not on-screen and hence "logically asleep") did not take place.

Counterexample to the notion that sleeping Panthers can't take any action: I just did a small experiment. While Eudora was running in my account, I set it to give audio feedback of the arrival of new mail, and then switched to an alternate test account I have on my PB. I then asked my wife to send me email, which was duly received by my background process's Eudora and announced over my PB's speakers -- all while my Eudora process was "running as me" in the background. So, assuming that the Mac DID awaken at 0329, the SD run was not launched as scheduled by me at 0330.

Perhaps the diff is that the mechanism for launching SD! works when its account is in the foreground, but not in the background?

One workaround would be simply to schedule SD! runs at 0330 to the same target disk from BOTH of the MM accounts, so that whose-ever account was logged in and virtually on-screen (though sleeping) would be run when the machine awakens at 0329. ...?

Thoughts?

=====

Finally, a couple UI suggestions:

(1) -- I'd be interested in the differences in writing speed traceable to WiFi vs. direct-connect. Perhaps have the log file contain occasional (or one summary) bit/sec copy rates?

(2) -- The SCHEDULE button always proposes a new item, when that may not be the reason, the majority of time, for the user's pressing that button -- In my own case, 90% of the time, it is to SEE WHAT IS IN the schedule, and not necessarily to SPAWN A NEW SCHEDULED ITEM. For that reason (for me of course) it's irritating when I do call up the sched to have to "brush aside" the PICK-a-WEEK-DAY-and-TIME screen to get to inspect the currently scheduled runs or to look at the log of a recent run. Imho (of course) it would be better to have a big SCHEDULE NEW ITEM button that could be clicked, at the same priority level as the SHOW LOG of last run and DELETE and EDIT buttons now there.

Th-th-that's all, folks!

dnanian
02-11-2006, 05:28 PM
Regarding Panther/Tiger dates -- sorry, no idea. Sounds like a bug that was fixed.

---

For scheduled backups: your account has to be in front, screen unlocked, with the machine awake for the backup to happen. Since it was not, it didn't work... we need access to the screen, or the system won't let us start SuperDuper.

---

As for the suggestions:

1) It does, right at the bottom:

| 05:57:48 PM | Info | Evaluated 1431954 items occupying 167.08 GB (185068 directories, 1234363 files, 12523 symlinks)
| 05:57:48 PM | Info | Copied 16485 items totaling 3.32 GB (647 directories, 2671 files, 13167 symlinks)
| 05:57:48 PM | Info | Cloned 163.83 GB of data in 1629 seconds at an effective transfer rate of 102.99 MB/s

2) The list of Scheduled Copies is separate from the "Main Window". So, when you make changes there, they don't affect the list of scheduled items.

If you want to look at that list, choose the "Scheduled Copies" item from the Window menu. To see what's going to happen for a given run, click it and the text (below) will update. To edit its schedule, click "Edit..."

To change what a scheduled copy is going to do, as opposed to when it's going to do it, you need to delete and re-create it.

DrDan in MA
02-11-2006, 06:45 PM
OK, now you've done it. SEVEN stars.

:D Now stop being such an excellent app! :D

dnanian
02-11-2006, 07:03 PM
Three more and I quit!