Message |
|
Jan Sass wrote:btw: where are the actions aliases stored? i have a 'cant resolve alias ...' in logs
That's nothing to worry about. The aliases in question are stored in ~/Library/Preferences/QRecall/Recent Captures/. They are used by the Desktop Capture/Recall commands to locate the 10 most recently captured archives. Since you've been deleting archives, you have aliases here to archives that no longer exist. If the messages are bothering you, you can trash the aliases that refer to deleted archives.
|
|
|
Interim release 1.0.0b45 corrects this problem. Download and install the update by choosing QRecall > Check for updates....
|
|
|
Interim release 1.0.0b45 corrects this problem. Download and install the update by choosing QRecall > Check for updates....
|
|
|
Jan Sass wrote:You can have all of my logs, if only i knew where to find them (i can view them, but where can i save them?).. Pls advise, and i'll PM them.
Your log files are stored at (your home folder)/Library/Logs/QRecall. You might want to compress them into a ZIP archive before sending them.
So, new backup worked like a charme - thank you. BUT i would like to see the O&V Window removed or at least have an option: always show all drives. This is because i need to back up multiple drives and don't want to to switch between the "master-layers" in O&V-window. is this possible in a future release?
That would be a very difficult and there are some technical problems in doing so. But I'll add your suggestions to the wish list.
|
|
|
Jan Sass wrote:Did so, opened my archive, got th4e message: Open failed, you should reindex or repair.
I'd be very interested in your log files around the time when you unsuccessfully opened, reindexed, and repaired this archive. In my testing, this bug caused only cosmetic problems. If it is corrupting archives, I want to know how.
|
|
|
This turns out to be a bug (apparently introduced by the compiler). As far as I can tell this only affects Intel Macs. Download this inter-release version QRecall 1.0.0b44a and see if it fixes the problem. - Drag your existing QRecall application from the Applications folder to the trash. - Drag this application into your Applications folder. - Launch the new version. The bug affected the composite list of volumes for each layer, making it appear that there was only one volume in the layer. This is why you couldn't select the second volume and when you recaptured your files the capture didn't see the old files and captured everything again.
|
|
|
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.
|
|
|