Bruce Giles wrote:James, I just sent you a QRecall report a short while ago that you can probably now ignore. I have an action set to backup my VM folder after Fusion quits. The action was running, but not finding anything to archive. I suspect your tip will solve my problem. I just turned on the Deep Scan option for that action, but QRecall is in the middle of backing up my entire volume, so I can't test this right now. I'll give it a shot tomorrow and let you know if it worked.

I moved this to a new thread in the Beta forum: "Virtual Machines folder not captured". See that one for more information.

I've moved this to a new thread:

Bruce Giles wrote:

James Bucanek wrote:Tip: I'd also suggest setting the "Deep Scan" option for the VM folder capture action, as VM packages (particularly Parallels) are notorious for tricking the filesystem change history into not seeing all of the changes.

James, I just sent you a QRecall report a short while ago that you can probably now ignore. I have an action set to backup my VM folder after Fusion quits. The action was running, but not finding anything to archive. I suspect your tip will solve my problem. I just turned on the Deep Scan option for that action, but QRecall is in the middle of backing up my entire volume, so I can't test this right now. I'll give it a shot tomorrow and let you know if it worked.

It didn't help. In looking at it further, I think I know what's going on, but I'm not sure if I've found a bug, or I'm just not understanding how exclusion works in QRecall 2.0.

I have two separate archive files: one called "iMac 24.quanta" which is my main backup file. The second one, called "Virtual Machines.quanta" is used to backup my Virtual Machines folder. Usually, that's for VMware Fusion, but on occasion, I have VirtualBox files in there too. The settings for the "iMac 24" archive has all the checkboxes in the Exclude section checked, but nothing listed in the box where custom locations can be added. The settings for the "Virtual Machines" folder are exactly the same in that respect.

Now, the "Virtual Machines" folder on my hard drive has QRecall capture preferences -- the "Do not capture" button is the only one selected.

I have one action to capture my entire hard drive, and a separate action, on a different schedule, to capture my home folder. Both capture to the "iMac 24" archive. Neither of those actions captures my Virtual Machines folder, AS EXPECTED, since it has a "do not capture" preference. I have a third action, scheduled to run one minute after Fusion quits, for which the specified action is to capture the "Virtual Machines" folder to the "Virtual Machines" archive. That's the one that isn't capturing anything. In looking closely at the log, I see this:

Action 2015-11-06 09:27:01 Minutia Capture to Virtual Machines.quanta
Action 2015-11-06 09:27:01 archive: /Volumes/iMac 24 Backup/QRecall Backups/Virtual Machines.quanta
Action 2015-11-06 09:27:02 Capture Virtual Machines
Action 2015-11-06 09:27:02 Macintosh SSD:/Users/bgiles/Documents/Virtual Machines/
Action 2015-11-06 09:27:03 Excluded items
Action 2015-11-06 09:27:03 Folder Virtual Machines
Action 2015-11-06 09:27:03 Captured 0 items, Zero KB
Action 2015-11-06 09:27:03 captured: Zero KB (0 bytes)
Action 2015-11-06 09:27:03 written: Zero KB (0 bytes)
Action 2015-11-06 09:27:03 duplicate: Zero KB (0 bytes) 0.00%
Action 2015-11-06 09:27:03 rate: Zero KB/min
Action 2015-11-06 09:27:03 files: 0
Action 2015-11-06 09:27:03 folders: 0
Action 2015-11-06 09:27:03 icons: 0
Action 2015-11-06 09:27:03 Nothing Captured
Action 2015-11-06 09:27:03 There was nothing new to add to the archive.
Action 2015-11-06 09:27:03 ------- Capture finished (00:01)

It seems pretty clear from the log that it's not capturing the folder because it's excluded (by the capture preference). But I thought b20 (which is what I'm running) had a bug fix that was supposed to allow that when I was specifically trying to capture a folder that was ordinarily excluded. If so, that's not working. Or did I misunderstand?

I suspect the better solution, given my archive setup, is to delete the capture preference, and add an exclusion for the Virtual Machines folder to my "iMac 24" archive only. Then my regular backups should skip the folder, but my Virtual Machines capture action will get it, because it's capturing to a different archive which doesn't have an exclusion for the folder in the archive settings. Do you agree?

Also, as I was writing this message, I was opening and closing archive windows, as well as the Help window. When I closed one of the archive windows, QRecall quit on me. I submitted the bug report to Apple, and as soon as I post this message, I'll submit a report to you as well.

James Bucanek wrote:Tip: I'd also suggest setting the "Deep Scan" option for the VM folder capture action, as VM packages (particularly Parallels) are notorious for tricking the filesystem change history into not seeing all of the changes.

James, I just sent you a QRecall report a short while ago that you can probably now ignore. I have an action set to backup my VM folder after Fusion quits. The action was running, but not finding anything to archive. I suspect your tip will solve my problem. I just turned on the Deep Scan option for that action, but QRecall is in the middle of backing up my entire volume, so I can't test this right now. I'll give it a shot tomorrow and let you know if it worked.

Thanks, but even though that wouldn't be difficult to do, I could imagine myself managing to screw something up somehow. I think I'd be better off to just wait the 10 minutes. Now that I know what the issue is, I guess I can be a little more patient.

I do vaguely recall QRecall crashing once recently, but I have no memory of what I was doing at the time. The standard Apple crash reporter dialog came up and I submitted it. Does Apple share any of that info with developers, or do they just use it to fix problems in their own software? Anyway, I'm glad you figured it out.

I probably did immediately re-launch QRecall and re-open the archive. If something like this should happen again (and it hasn't, so far), is there anything I can do short of rebooting to force the archive closed?

James Bucanek wrote:Once in the dialog, you can reconfigure the options to whatever you want. Just be aware that the options are highly interdependent. The "Reindex only" option is incompatible with all of the other options, so as long as "Reindex only" is checked, all of the other options are disabled. Uncheck "Reindex only" and you'll have the opportunity to select a different set of options. The "Use auto-repair information" and "Copy recovered content to new archive" options are also mutually exclusive; selecting one disables the other. And once you've picked any other option, the "Reindex only" option will be disable, because, you know, mutually exclusive.

OK, now I understand, after I played with it a bit. My first impression was that this is a dialog that's crying out for radio buttons instead of checkboxes, but the "Recover lost files" and "Recover incomplete files" options don't fit that mold either. They can be a primary choice, if you don't pick any of the top three, or a secondary choice, if you pick either of the first two. So I have to say I don't really like the way those options are laid out, because it's not inherently clear what you can and can't do. You have to turn off the checked "Reindex only" option before it becomes clear that you can do something else. But honestly, I can't come up with a better way to do it.

OK, so if I want to get rid of those damaged ("Unknown Unknown Repaired") layers I need to keep merging them with subsequent layers until I eventually hit a layer that recaptures everything that was still missing, and at that point, the damaged layer disappears. I probably won't do that, as I'd rather the archive history, in case I need to recover something else from back then, but the temptation is strong. (Something in my nature just doesn't like to see error messages in the browse window, even when I understand what they mean and why they're there. You REALLY don't want to see what the System Log file in the Console app does to me. )

By the way, two more things. With regard to the verify errors discussed in this topic, when the Verify command reports an error and you choose to repair it, you get the option of verifying or repairing your volume first, which is good. But no matter whether you choose verify volume or repair volume, the top of the sheet says "Repairing volume". That confused me a little, when I was sure I had clicked the Verify button, not the Repair button.

Second, after I got past the volume verify/repair, when the Repair Archive sheet comes up, the only option not grayed-out was "Reindex only". I had already done enough of these that I was pretty confident that "Reindex only" wasn't going to work, but I had to go though that first, and wait for it to fail, before I could go on with the "Use auto-repair information" box checked, and that one actually did fix the archive. Is that the way it's supposed to work?

James Bucanek wrote:If you haven't done so, please send a diagnostic report. I'm still looking for combinations of actions the leave the .lock file locked.

Just now sent a report.

-- Bruce

Bruce Giles wrote:At the moment, I'm running another verify. When that completes, I'll try again to delete the layer and I'll report back here with the details.

The verify completed and reported no problems of any sort. Also, I was able to delete the last incomplete layer, and it deleted almost immediately. But now there's something odd going on with the Merge command. I have a number of incomplete layers going back several weeks. I attempted to merge them with a subsequent complete layer, but after doing so, I end up with a layer marked as "unknown".

For example, before the merge:

Layer 26: Monday, October 19, 2015 at 1:00 AM 34.4 MB 121 items
Layer 27: Monday, October 19, 2015 at 2:48 AM 36.9 GB Incomplete
Layer 28: Monday, October 19, 2015 at 7:00 AM 102.5 MB 144 items
Layer 29: Monday, October 19, 2015 at 1:00 PM 40.8 MB 138 items
Layer 30: Monday, October 19, 2015 at 7:02 PM 105.3 MB 132 items

Then I selected both Layer 27 and 28, and merged them. After the merge:

Layer 26: Monday, October 19, 2015 at 1:00 AM 34.4 MB 121 items
Layer 27: Unknown Unknown Repaired
Layer 28: Monday, October 19, 2015 at 1:00 PM 40.8 MB 138 items
Layer 29: Monday, October 19, 2015 at 7:02 PM 105.3 MB 132 items

So now I select the new Layer 27 (Unknown) and Layer 28 (1:00 PM) and try to merge these. After the merge:

Layer 26: Monday, October 19, 2015 at 1:00 AM 34.4 MB 121 items
Layer 27: Unknown Unknown Repaired
Layer 29: Monday, October 19, 2015 at 7:02 PM 105.3 MB 132 items

So, it seems that and Unknown layer can't be eliminated by merging, but if you try, it appears to "eat" the subsequent good layer. After trying this a few times, I closed and re-opened the archive, and did another Verify. The verify found no problems, and subsequent scheduled captures are proceeding without error.

I had the same problem with the Verify command. I updated to Beta 18, did a repair, and as far as I know, the problem is fixed. As mentioned in the release notes, I opened the archive, turned on the option to display invisible items, and noted that I had four "dev"s, a "home", and a "net". I command-clicked them to select them all, and attempted to delete them. For the next ten minutes or so, nothing happened, except that the window said something about waiting for permission to open the archive. I left the room for a while, and when I came back, it had finally deleted them. Here's what the log file says:

Action 2015-10-21 22:51:06 ------- Delete items in Macintosh HD.quanta
Action 2015-10-21 22:51:06 archive: /Volumes/Seagate 2GB Backup/QRecall Backups/Macintosh HD.quanta
Action 2015-10-21 22:51:06 Minutia Waiting for permission to open archive
Action 2015-10-21 23:00:06 Minutia Broke stale lock file
Action 2015-10-21 23:00:06 died: 2015-10-22 02:51:06 +0000
Action 2015-10-21 23:00:06 Minutia Acquired permission to open archive
Action 2015-10-21 23:00:08 Delete 6 items
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting home
Action 2015-10-21 23:00:08 Deleting net
Action 2015-10-21 23:00:10 ------- Delete finished (00:03)

This is actually at least the second time this has happened. Shortly before, I had attempted to delete an incomplete layer. When nothing happened after a few minutes, I got impatient, canceled the delete, and rebooted the computer. I haven't yet tried again to delete that incomplete layer.

At the moment, I'm running another verify. When that completes, I'll try again to delete the layer and I'll report back here with the details.

-- Bruce

Interesting, but I haven't relocated my home folder. It's always been on the startup volume.

I did the upgrade to El Capitan last night, and so far, there have been no problems either with the OS or with QRecall. I had put actions on hold for several hours while I did the upgrade. The hold period had expired, and as soon as I logged in and entered the password to decrypt my backup volume (which is encrypted by File Vault), QRecall started in with the next held action.

-- Bruce

Both of the following were (I think) also occurring in b14, but I've been really busy lately, and didn't have time to check.

1. After installing b15, and restarting QRecall, I couldn't run actions at first. I'd get a message (sorry, I didn't get the exact text) that said something about the scheduler not running, or maybe it couldn't be started, and I should restart QRecall. Restarting QRecall didn't help, but rebooting fixed it. I could see in the log that the new scheduler was installed.

2. Possibly related to (1), when I selected an action from the actions window and clicked the Run button (intending to run it immediately), nothing happened. Not even any indication in the log that I had done this. The activity monitor (which was not visible until I selected it from the Window menu) said the next action would be the action I had just tried to run manually, but it was scheduled for its usual time. Other actions that should have occurred earlier weren't mentioned. The fix was to click the Run At button, and schedule it to run in 1 minute. That caused a bunch of actions to be queued up in the Activity Monitor window (after the one minute delay). I had only tried to manually start one or two capture actions, but many of the actions now queued up are verify, compact, and merge actions. I'm headed off to work, so I'll just let them all run, and hopefully I'll have a good full backup by the time I get home, ready to install the OS X upgade.

3. At some point under b14, several weeks ago (yeah, I've been THAT busy), QRecall stopped running any actions, and I don't know why.

I just sent you a report, in case that helps track down the problem.

-- Bruce

James Bucanek wrote:

Bruce Giles wrote:I don't think Apple could have made it any more subtle. I much preferred the old barber-pole pattern, but I realize that QRecall is just using what Apple provides there.

In the next iteration of the UI I was contemplating using the even-smaller progress indicator. I might have to include a free pair of reading glasses with every copy of QRecall.

I'm already looking through a pair of the finest reading glasses that WalMart can supply (3 for $7.98!), and trust me, it doesn't help.

Seriously, see the attached file for what it looks like on my old non-retina iMac screen. Maybe it looks better on newer, higher resolution screens, but to me, there's just BARELY some indication that the blue color might be very slightly "faded" in the center of the bar. More importantly, however, is that the faded area (if that's what it is), doesn't move. There's no pulsing going on. The faded area doesn't move from left to right or anything like that. Given that, it may be better to use one of the "spinner" type indeterminate progress indicators. Or do I have some kind of weird problem going on?

By the way, this brings up another issue that's not specific to the beta, as I've seen it in Rev 1 of QRecall as well. Note that the attached screenshot shows it's capturing a file called "screenshot_0000.png". That QRecall capture has now been running for more than 24 minutes, and the activity window STILL shows it working on screenshot_0000.png. I've checked the actual size of that screenshot, and it's only 281K, which QRecall ought to be able to capture in a fraction of a second. So what is QRecall really doing? There's no indication in the log file of any problem. It just now finished, and the log file says:

Schedule 2015-09-11 18:11:35 Action 'Capture Virtual Machines to Virtual Machines.quanta' set to run at Today 6:11 PM
Action 2015-09-11 18:11:36 ------- Capture to Virtual Machines.quanta
Action 2015-09-11 18:11:36 archive: /Volumes/iMac 24 Backup/QRecall Backups/Virtual Machines.quanta
Action 2015-09-11 18:11:44 Capture Virtual Machines
Action 2015-09-11 18:11:44 Macintosh SSD:/Users/bgiles/Documents/Virtual Machines/
Action 2015-09-11 18:36:53 Captured 1706 items, 58.4 GB (58% duplicate)
Action 2015-09-11 18:36:53 captured: 58.4 GB (58,463,957,153 bytes)
Action 2015-09-11 18:36:53 written: 10.9 GB (10,910,757,248 bytes)
Action 2015-09-11 18:36:53 duplicate: 33.9 GB (33,918,316,347 bytes) 58.02%
Action 2015-09-11 18:36:53 rate: 2.32 GB/min
Action 2015-09-11 18:36:53 files: 1,738
Action 2015-09-11 18:36:53 folders: 133
Action 2015-09-11 18:36:53 icons: 18
Action 2015-09-11 18:36:57 ------- Capture finished (25:13)

If the activity window ever switched from an indetermine progress bar to one showing actual progress, it must have done so in the last few seconds, and I wasn't watching it at the time, so I can't say for sure if it did or not.

If QRecall spent all that time doing some kind of maintenance on the archive file, it seems like it ought to say so in the log and in the activity window.

-- Bruce

When I type "qrecall" at the command line and hit enter, the resulting usage summary for some commands appears to have the commands repeated. See the items marked in red below:

$ qrecall
* Missing <command> argument
Usage: qrecall <command> [ ... ]
       qrecall capture <archive> <path> [ <path> ... ]
       qrecall dump <archive> -options
       qrecall create <archive> [ --settings <values> ]
       qrecall compact <archive> [ --minfree <fraction> ]
       qrecall verify <archive>
       qrecall restore <archive> <item> [ <item> ... ]
       qrecall recall <archive> <directory> <item> [ <item> ... ]
       qrecall merge <archive> --layers <range>
       qrecall delete <archive> <item> [ <item> ... ]
       qrecall uncapture <archive> --layers <range>
       qrecall reindex <archive>
       qrecall repair <archive> [ --options <flags> ]
       qrecall info actions | <action>
       qrecall scheduler hold <until> | resume
       qrecall suspend suspend <actionID>
       qrecall unsuspend unsuspend <actionID>
       qrecall run run <actionID> [ -at <time> ]
       qrecall unrun unrun <actionID>
       qrecall captureprefs list|normal|exclude|ignore|scrape ...
       qrecall keys keys check
       qrecall version
$

James Bucanek wrote:That's not 100%, it's "indeterminate." OS X progress views have an "indeterminate" mode to indicate that the amount of progress is unknown or unknowable. When the look of OS X got "Yosemited." the familiar marching barber-pole pattern was replaced with an (very) subtle gradient that drifts slowly across the screen. On small controls, it's nearly indistinguishable from the progress view at 100%.

Well, raise my rent! I took another close look at it -- very close -- and sure enough, you're right. I don't think Apple could have made it any more subtle. I much preferred the old barber-pole pattern, but I realize that QRecall is just using what Apple provides there. OK, so we can ignore that one.

To state the obvious, that's a bug. I'm still not sure where the problem is, and I'm beginning to think there are several bugs. In some cases it appears that the icons for the volume and computer aren't being captured properly. In other cases, the static system icons for a volume and the computer that are supposed to display when a captured icon isn't available aren't loading for some reason. Its been difficult to resolve because neither of these problems occur on my system with any regularity. Regardless, it's on the short list of bugs to look into. The issue is entirely cosmetic, as the icons captured/displayed for items in the archive aren't used to recall them.

So, just out of curiosity, what icon was supposed to be there? I went back and looked at QRecall 1.2.3.8 which is still running on one of my other computers, to see what it did. In that case, the top level item is the name of the computer, as defined in the Sharing panel of System Preferences. It happens to be an old iMac, and the icon is an iMac icon, so that's appropriate. But in b13, the top level item isn't the computer's name, it's MY name. In fact, the computer name isn't even in the list. The next level below my name is the name of the hard drive. So what should the top level icon be -- a human silhouette, or something like that?

The assistant in 2.0.0b13 does add the new power state conditions to the actions it creates so that most will stop automatically if the power capacity of the battery drops below 20%. (On desktop computers, these conditions will never trip.)

But they will if the desktop computer is connected to a UPS (and monitoring the battery state via a USB cable), right? The release notes seem to indicate that.

I bow to your superior skills in proofreading, but I have to call you out on this one. It's "scraping" (one 'p'), the noun form of "scrape": "to push or pull a hard or sharp implement across a surface or object so as to remove dirt or other matter..."

I was going to argue back on this one. I was absolutely certain you had used the word "scrap" in several places, in which case, "scrapping" would be appropriate. I went back and looked again and couldn't find it. Then I read ahead and discovered that Ming-Li Wang noted it as well, and you've apparently fixed it. I have to say I prefer "scrap" and "scrapping" to "scrape" and "scraping". I think of "scrap" as a synonym for "destroy". For example, "The wrecked car was scrapped." I don't think of "scrape" that way. But it's really not a big deal either way. I can learn to live with it. If I really have to.

-- Bruce