Message |
|
Steven M. Alper wrote:You mean like Apple's Address Book's alarm: Repeat in 1 minute; 5 mines, 30 minutes, 1 hour, 1 day, 1 week... etc.? That would be fine, although I think it should be a separate button on the activity d.b. so that you don't have to go through another screen if you really do want to completely cancel at this point.
I was considering two interfaces: If the action was canceled, an additional "Reschedule..." button would appear in the confirmation dialog. Click it and the "Run At..." dialog would appear. Alternatively, I'm considering adding these kinds of "power user" features to some contextual pop-up menus, rather than cluttering up the core interface. If you right/command+clicked on a running action, "Cancel and Reschedule..." would be one of the options.
Of course, the other way around, if the user left the pause "hanging indefinitely" they'd always have the activity d.b. floating around to remind them.
Assuming they haven't closed it.
|
|
|
Steven M. Alper wrote:1. Could QR play more fairly with the other children? Share the CPUs in a less monopolistic fashion?
That's the job of the operating system. QRecall just does its thing. It's up to the kernel to balance the load amongst multiple processes. That said, there are number of ways in which QRecall can be less of a burden on system resources. Significant ones have already been done, which you'll see in the next release. Others I'm still experimenting with.
2. Could QR's activity monitor gain a "Pause" button, obviating the need to remember to launch QR and manually start a canceled action?
A "pause" button is interesting, but I'm worried the process could be left hanging indefinitely. What would you think about a "reschedule" button that would appear if you cancel an action?
|
|
|
Steven M. Alper wrote:Although no other app was able to handle the situation, is there perhaps a way to design QR to exit more gracefully in such a situation?
Sadly, no. QRecall (like every other application) is at the mercy of the operating system. If an application makes a system call and that call fails to return, there's nothing—short of killing the process—that can be done about it. You took the only course of action available.
|
|
|
On my MacBook Pro I do notice that the hard drive is significantly slower than in my desktop machines. A few applications that fly on my G5 seem to crawl on my MBP, even though my MPB has more (CPU) horsepower and just as much RAM. When I put my ear to the MBP, I can hear the drive just trashing about. I haven't really noticed any slowdown with QRecall because I run my captures at night.
|
|
|
Most performance degradation is due to swapping. The amount of RAM you have can have much more impact on performance than CPU or even drive speed.
|
|
|
Thanks for the update. I'll check into that.
|
|
|
In my defense, I was writing a user manual not a UNIX man page. I agree that it might be worded better.
|
|
|
You might want to check your NetInfo database. I suspect that a partial user account with a home folder path of "99" still exists. Internally, QRecall uses the list of defined user accounts to generate a number of programmatically created filters. The "trash" and "cache" filters are two such filters, as there are trash and cache folders relative to every user's home folder. If a user account contains an invalid home path, the filter creation will fail, which is exactly what you're seeing in the log. Aside from the onslaught of log messages, it shouldn't affect the capture since QRecall simply failed to create an exclusion filter for a bunch of folders that don't exist.
|
|
|
I think a better solution is to simply have the scheduler immediately run all actions that have missed a scheduled run time while the system was shut down. This would make the behavior of actions during a shut down consistent with sleeping -- and consistency is a good thing.
|
|
|
Frederic Thomas wrote:I *don't* understand why something that is to run at an INTERVAL of ONE day does *not* given the chance one hour too late. Again, my only problem is that what QRecall does not correspond to what I understand in the term INTERVAL.
An Interval schedule simply means that the scheduled run times are determined by fixed time intervals (some number of hours/days/weeks). So if an action is scheduled to run at 12 hour intervals starting at 2:00AM, it would be scheduled to run Yesterday 2:00AM Yesterday 2:00PM Today 2:00AM Today 2:00PM Tomorrow 2:00AM Tomorrow 2:00PM and so on If the action ran yesterday at 2:00PM and the computer was shut down at 2:00AM today, that scheduled run time was missed. The next scheduled time will be at 2:00PM Today. Except for the way that the run times are calculated, an Interval schedule behaves exactly like a Daily schedule.
Note: There's an alarm clock for mac out there that makes the mac wake up from sleep at some time: integrating that in QRecall would be smart. You can even program power on I think...
I'm reluctant to have QRecall arbitrarily change system settings, but I have considered adding certain power management features to actions (i.e. sleep when finished).
|
|
|
Frederic Thomas wrote:Not sure why they did take that long to appear.
I have no idea. But I do know that JForum has a few idiosyncrasies.
|
|
|
Stephen Murphy wrote:1) If I read the Help file correctly, when I exclude something, and then restore a directory, anything excluded would be deleted. I would like to be able to exclude files or folders in a way that they are totally ignored - neither archived nor restored. An example here would be podcasts. They exist in my iTunes folder hierarchy, and at times they take up a lot of space, so I don't want to back them up - I can always re-download them if I need to. But if I excluded them, and then had to restore the containing iTunes folder, they would be deleted.
You read it correctly. This is an excellent suggestion. I'm working on some new logic to deal with deleted files. It might be possible to extend this to handle excluded items in a special way too.
2) Because of this, to "exclude" certain directories/files, the only way I can see at the moment is to explicitly include all files/folders other than those to be "ignored". So, in the iTunes case, I would have to include, say, every Artist folder at the same level of the hierarchy of the Podcasts folder - that's a lot of work, and it also means that every new folder that gets created would have to be explicitly added (and may not be done so in time for a critical backup). It would be better to have an overall include, excluding ("ignoring") some of the folders/files underneath a certain level.
Or, you can simply capture the entire iTunes folder (excluding Podcasts) and should you ever need to restore it, select all of the iTunes subfolders in the archive and choose Restore. Each individual subfolder will be restored. Since you didn't capture the Podcast folder it isn't in that list and would be ignored. Probably much less work than the other way.
3) My home directory is around 60GB, but I only really need to backup about 12GB of this. So, I'm forced to use the clumsy "include just these folders" approach I've suggested above. The final problem here is that I don't think I can inlcude hidden files/folders (say, a .svn directory in home) in the current system.
There are a number of ways of doing this. Since the .svn directory is a folder, you can use the Go To command in the open files dialog or the Finder (Command+Shift+G) to navigate into the hidden directory. If you can open the hidden item using the Finder or some other application (BBEdit, Hex Fiend, etc.) you can then drag the item's icon from its window bar title into the action. If you enable hidden files in the Finder, you can drag hidden items directly.
|
|
|
Now that the log files are up, I can answer the primary question.
Frederic Thomas wrote:So I have QRecall set to backup my home to a AFP server every day. It did not run last night, but there's nothing about it in the log? See attached screen shot: it ran the 27th and the next execution is 29th, nothing in log about 28th... (b)
QRecall wasn't running at 1:00 on the 28th. According to the log. The last log record on the 27th was 2007-07-27 19:58:04.202 +0200 #debug# received SIGTERM [3.732883.263.36] This indicates that something killed the scheduler, probably a shutdown. The next log record is 2007-07-28 02:15:18.717 +0200 #debug# discovered recent 'QRecall Archive.quanta', mod=2007-07-27 01:06:53 +0200, repository=/Volumes/Gandalf/QRecall Archive.quanta [4.732885.385.2] Which is one of the first things that will happen when you log in. Given that there are no log messages during the intervening period (the scheduler attempts to restart every half hour), my conclusion would be that your computer was off at 1:00 on the 28th. From the help file (Help > Automation > Scheduling):
Actions are not scheduled while the computer is off. When you restart, actions will be scheduled to run at their next calculated run time.
If you want a QRecall action to run consistently at 1:00 every morning, schedule your computer to start up at least 30 minutes before. If, however, you simply put your system to sleep, any pending actions will start immedately when the computer is awakened again. Again, from the help:
Actions do not run?nothing does?while the computer is sleeping. When the computer wakes up, any actions that would have started while asleep are started immediately.
|
|
|
Frederic Thomas wrote:So I have QRecall set to backup my home to a AFP server every day. It did not run last night, but there's nothing about it in the log? See attached screen shot: it ran the 27th and the next execution is 29th, nothing in log about 28th... (b)
There's no attached screen shot, so I can't comment. It would be better to attach (or send me privately) your actual log file as there is much more information there that might illuminate a problem.
In any case, the capture is set to INTERVAL every 1 day starting from xxx... so why is it not trying to backup ? It did backup on the 27th, more than one day ago... (a) [we're the 28th at noon as I write this]
Does your action have a condition that says "Ignore if no archive?" This will cause your action to be silently skipped if the archive isn't mounted at the time the action runs. If you want QRecall to scream and wail when the archive is missing, remove that condition. It's also remotely possible that the scheduler daemon wasn't running at the time the action was scheduled to run. Is there any chance you had just restarted your system?
And lastly, looking at the log, (c), there is no schedule using IncyBack.quanta so why is it looking for it? When is it going to delete alias of long gone archives in its Preferences? At the level just before max, messages about this fill the screen as if this was a terrible problem! (no screenshot of this).
A lot of the log messages in QRecall are there for the purposes of diagnosing the beta. Most of these will disappear in the final release.
- (a) INTERVAL does not seem to work as I would expect of interval
Can't really comment because I don't know what's going on (or didn't go on, as the case may be.)
- (b) If a scheduled backup is skipped, I think a log entry would be good. Again this is all about visibility on what the scheduler is/was/will be up to.
Everything gets logged. Just about the only reason an event like this wouldn't' be logged is if QRecall wasn't running.
- (c) alias removal in pref
The obsolete aliases are only producing annoying log messages. This will go away in the future.
|
|
|
It's a harmless error. I'm planning to remove these kinds of errors in a future version. These occurs when some process deletes or replaces a file between the time that QRecall reads a folder to determine which files need to be captured, and it actually captures the file. If the file has been removed or replaced in the mean time, the OS returns a "file not found" error, QRecall logs it, and moves on. For files that are contently being replaced (like the iCal preference file in your example), this is fairly typical occurrence. What QRecall needs to do is find out if the file has been replaced with something else and capture that instead, or record that the file has been permanently deleted. It has no impact on the integrity of the archive.
(any chance you could allow multiple selection and copying directly from the QRecall access version of the log?):
It's already on my to-do list.
|
|
|
|
|