Message |
|
I misunderstood your original post. You captured four items: A volume (Mac Clients) and three folders (Office 2004, Library, Preferences) on another volume. Open the Owners and Volumes drawer: View > Show Owners & Volumes (Command+Option+V). Select the other volume in the drawer. This drawer should open automatically the first time you capture multiple volumes. If it didn't, let me know.
|
 |
|
Is Preferences inside Library? That is, did you try to capture ~/Library and ~/Library/Preferences? Capturing a folder implies capturing all of the items (file and folders) that it encompasses. QRecall ignores all capture items that are contained inside another capture item. If they weren't nested, I'd be very interested in getting a copy of your log files.
|
 |
|
Bruce Giles wrote:Either I'm misunderstanding the purpose of the "Ignore if no archive" condition, or else it's broken.
It's broken. It probably broke on the previous release, which involved significant changes to the scheduler. It will be fixed on the next release.
|
 |
|
Bruce Giles wrote:I was playng around a little with the Capture Assistant today. In the time limit section, I selected "Keep 90 days". I notice the dialog has a footnote, with an asterisk, but I don't see where the matching asterisk in the main text is. Anyway, that's a trivial point.
The asterisks in the button titles were lost. I just fixed that.
I'm not sure what the footnote is trying to say. The first sentence sounds as though the "Keep 90 days" and "Keep 30 days, then less frequently for two years" options might change to other options, depending on what I'm trying to capture, but if that's the case, I haven't seen it happen yet.
That's exactly what it's saying. The suggested schedule changes based on a guesstimate of how much data the archive can capture. The assistant calculates a ratio of the free space on the archive volume (after a hypothetical first capture) to the total size of the items you selected to capture. If the estimated free space on the archive volume is more than 150% the size of the items to capture, it suggests the 90 days and 30 day+3 years schedules. This is based on the assumption that approximately 4% of files will change each day and approximately 40% of the data in those files does not actually change. If the ratio is smaller, the assistant will suggest 60, 30, or 14 day schedules instead. Of course, these are just estimates and your actual data use can make them wildly inaccurate ? thus, the disclaimer. If you just use your computer for checking e-mail, you could probably keep 10 years of daily changes. If you're editing fresh video footage each day, your archive might overflow in a week.
When the assistant finished, I looked at the results. The rolling merge says: Keep most recent 3 days Followed by 57 day layers I'm pretty sure that's 60 days, not 90.
You're absolutely correct.  Looking at the schedule tables, the 90 day schedule was wrong. I just changed it to Keep 7 days followed by 83 day layers.
Also, in this particular case, since the capture is done daily, could the same result be achieved by either: Keep most recent 90 days or Keep most recent 1 days Followed by 89 day layers?
Yes, if you make exactly one capture a day there's no difference.
(I realize they're not the same if you change the capture frequency.)
Which is exactly why the schedules are a little non-intuative. If you add additional actions to, say, capture your Documents folder every hour or use the Desktop Capture command to take a snapshot of a project folder, the archive will have many intermediate layers during the day. Keeping 3 (or 7) days keeps all of those "micro-backups" for a few days, allowing you to recover the project as it was at 9AM the day before yesterday. After a few days have elapsed, these micro-backups will be merged so that only the last daily version of each file is retained.
|
 |
|
Pierre von Kaenel wrote:Why don't I mount volumes manually? This is a laptop and it moves from home to office and back each day. I have remote volumes at both locations and don't want to have to mount/unmount/mount/unmount etc. Plus I have multiple remote volumes at each location used for different purposes and types of backup. (I'm very meticulous when it comes to backups.)
I agree completely. I have a laptop and an iMac in a similar situation. This is on my to-do list. There are just some technical problems to work out.
|
 |
|
Currently, the volume containing the archive must be mounted before the action is run. In fact, if you told QRecall that your archive was on a removable or network volume, the assistant will add a condition to the action to skip it if the volume isn't connected when the action runs. I'm looking into auto-mounting the archive volume when an action runs, possibly making it a an option in the action.
|
 |
|
This is (mostly) normal. There's a bug in the current version of the log viewer that displays some internal/low-level log messages. The extraneous log messages you are seeing are about low-level communications passed between processes. The next version of QRecall will correct this display problem. You should only see the high-level "Compact Stopped by user" message(s).
|
 |
|
Tell me about the error, or (better) send me your log file.
|
 |
|
QRecall is very conservative in the criteria is uses to determine when a file or directory might have changed and needs to be recaptured. In this case, all of the files on the volume are new (since they were all rewritten when you restored the volume). It's only logical that QRecall would see them as new files and capture them again. Since all of the files contained the same data as the previously captured items, no new data was added to the archive ? thus, the 99% duplicate message. As for the exact mechanics involved, the likely suspect is the attributeModDate property of each file. This property is changed whenever any file metadata is set or changed. Recalling a file sets the metadata of that file to its recalled state, which subsequently changes its attributeModDate. The next time the file is captured, the file's new attributeModDate doesn't match the attributeModDate of the previously captured item, so QRecall recaptures it.
|
 |
|
Great minds must think alike. I was contemplating this very feature yesterday (probably for the same reason). As for an interface, I was thinking of adding an editable "notes" field to the info drawer, akin to the notes of an iCal event.
|
 |
|
If I had to guess, I'd say that some of your folder names begin with <space> and others begin with Option+<space> (non-breaking space). QRecall uses a Unicode comparision function supplied by Mac OS X that's supposed to sort exactly the same way the Finder does. Clearly some investigation is in order. Which is actually good timing, as I'm in the process of reengineering the way that strings are managed internally.
|
 |
|
Bruce Giles wrote:Actually, the title of the page is "Recall Items", not "Restore Items". And that was part of my problem. I knew the command I wanted was "Restore To", so when I saw this page, the title caused me to think it was about the Recall command only, and I therefore didn't really look at it.
That's a good point. I might break out the Restore command and give it its own page.
|
 |
|
Bruce Giles wrote:Is the "Restore To" command documented in the help? I couldn't find it, but, but maybe I wasn't searching the right way.
QRecall Help > Capture Basics > Restore Items. After the basic restore instructions, there a note on how to restore a volume. How were you searching? If I search the help for "restore volume" or "recall volume" the Recall Items page is the first hit.
I finally noticed the "Show Owners & Volumes" command in the View menu.
Oh, that's embarrassing. The help really should mention that you must open the owners & volumes drawer in order to select an entire volume. 
|
 |
|
The latest release resolves this problem.
|
 |
|
I purposefully disabled resursive expansion (holding down the Option key while clicking an enclosure triangle) in the browser. The problem is that a single folder could potentially expand to thousands, or even hunderds of thousands, of items. QRecall *might* eventually come back after 10 minutes, if it doesn't simply blow up the operating system's outline framework (which is not designed to display that many items at once). However, I'll look into revisiting this. I might limit the expansion to two or three levels, or maybe stop expanding subfolders once two or three hundred items are revealed. This might make you repeat the process to display everything, but it would certainly be less work than it is now.
|
 |
|