As I mentioned earlier, only the archive in charge of backing up my system partition would fail to verify, and it is so even after I started over with a brand new archive.

After some digging just now I found my user profile folder was the culprit. Now, remember I said I had a dedicated partition for my documents which is mounted at boot at ~/Documents? I unmounted the partition and tried again and sure enough the test archive verified without error.

Note that I've been using the same arrangement for a long time and neither QRecall v1.2.x nor early v2 betas had any trouble with it. They only started since beta 16, or 15 at the earliest.

A diag report has been filed.

Strange! I sealed the old sys.quanta and created a new one, which had its first capture last night (at 3am this morning), and then immediately failed the verification less than 2 hours later. It's repairing; a diag report will be sent when done.

edit: the repair job checked the partition hosting the archive: no problem. I also verified my system partition with Disk Utility: no problem either.

The verification failed again today with "layer catalog tree" error as you mentioned. It's fine now after reindexing with the newest layer (created last night) intact. I'm going to seal the archive and start a new one for the time being. The old archive would be kept for a while so it would be available for testing if you find a solution.

I keep old system archives to satisfy my occasional curiosity when I want to see how something was done/set back then, and for the rare cases where I want to check an old plist or the like when investigating an issue. Nothing critical. To resuscitate the system, a recent archive suffices.

What worries me are my other archives, which hold my actual "data" and were all created by QR v.1.2.x. Weekly verifications have all checked out just fine so far, but do you advise starting anew with those as well?

Something just came to mind, though I don't know if it bears any significance to the issue.

I have a SSD partition dedicated for my documents, which is mounted at boot as the "Documents" folder under my user profile. As a result, while sys.quanta (the archive at issue) is set up to capture only the system (root) partition, it doesn't backup the contents of the ~/Documents folder, which is backed up separately.

Sys.quanta, however, does show two "volumes" when opened in QRecall: "carlosys" (the name of my system partition) and "Documents", as shown in the attached screenshot below. Note that the size for the "Documents" volume is zero. It really is an empty volume.

James Bucanek wrote:Important question: Is this an archive created with the 2.0 beta, or is this a 1.2.x archive that you started using with 2.0?

The latter. The date stamp for layer 0 is 2015-01-31, so definitely 1.2.x.

Did a manual capture just now, followed by verification, and sure enough, the verification failed again for the same reason. It's repairing. I'll send another diag. report when it's done.

For two straight weeks my system partition archive needed repair when verified. In both times disk verification showed no error and the repair was successful, but 6 out of the last 7 daily layers are now "incomplete", while 4 from the previous week were incomplete. (Note that I removed those incomplete layers and compacted the archive after the first repair.)

As can be seen from the screenshot below, the repair log indicates there are 4 "unreachable" folders under my system partition "carlosys", including one under my user profile directory tree. The 4 folder serial numbers are the same for each day. Unfortunately I can't tell which folders they are referring to so I can't investigate further.

I'm still on Yosemite (10.10.5), if that matters.

edit: forgot to say, a diag report was sent.

Yeah, I saw it in the release notes. Thank you!

It seems v2 is almost ready. I have had no bug to report for weeks.

It's another Sunday and I'm happy to report that the issue has indeed been fixed in b14. All merge and verification jobs reserved for Sat. and Sun. morning have finished successfully, and b14 has been running perfectly well here. Thank you.

Johannes wrote:A solution for both issues would be simple filters on file/folder names (exclude/include *.dtBase2, peaks/*, analysis/* export/* ect).

Your wish is mine, too, as I made a similar request just a few days ago.

Any other suggestions?

Before that happens, QR2's command line tool "qrecall" might provide a workaround. The following line should work to exclude all "peaks/*" under the /project_folder tree from QR2 backup:

find /project_folder -type d -name "peaks" -print0 | xargs -0 qrecall captureprefs exclude

Similarly, the following line should get "*.dtBase2" excluded:

find /project_folder -type f -name "*.dtBase2" -print0 | xargs -0 qrecall captureprefs exclude

Put them in a bash script and run them as often as necessary. You can use Hazel, Keyboard Maestro or the like to automate the task. Even the good old crontab can do the job.

Having seen no error/warning messages in the log window, I'd been very happy with b13 until I noticed several yellow status icons in the status window. Several archives have not been verified for almost two weeks. That should not be possible since all my archives are scheduled to be verified at least once a week.

As there's still no warnings or errors in the log window, I dialed the detail level to the max and saw numerous question marks associated with a "Problem communicating with helper, retrying" message. Given your detailed explanation earlier these don't concern me.

After digging into the various records associated with those verification actions scheduled for early Sat. and Sun. morning, however, I found several of them--the last one on Sat. morning, at around 4:40am, and all 3 this morning--did not have a "Verify finished" line. And sure enough, those are exactly the 4 archives listed as "Verified 13 days ago" in the status window.

Note that all weekend verification jobs are preceded by a merge action. They all finished without issue according to the log. Manual verifications on all 4 finished successfully as well.

One side issue: my investigation was prompted by the "red" dot inside QR's menubar icon. As it turned out, the non-verification status for those 4 archives merely earned them a "yellow" dot. The lone "red" dot in the status window is for my music archive that has not been captured for 11 days. It's nevertheless a non-issue as I haven't got the time to rip my CDs for quite a while. (The capture done 11 days ago was for meaningless changes in .DS_Store files.)

Now, I don't want to disable status warnings in the menubar icon; nor do I want to "forget" the archive, but the red dot bugs me, and might numb me someday. So please consider allowing some customization there in the future. Thanks!

James Bucanek wrote:

Bruce Giles wrote:

Feature request: Two-column sorts of the Actions window. I'd really like to see actions sorted first by the Archive column, and then by either the Next or the Schedule column.

I'll add that to the list. Most of the UI enhancements are being addressed in version 2.1, so I'll probably get to it then.

I thought one could get the same result by simply clicking on the Next or Schedule column first before clicking on the Archive column. No? Not that I'm against you doing anything about it. Just saying perhaps Bruce could achieve (most of) what he desires already before v.2.1 arrives.

In the release notes, "scraping" should be spelled as "scrapping", with two "p"s. Mentioned so you can get it right in the help files.

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 thought as much, but didn't speak because English is not my first language.

The cause for confusion probably lies in the beta release notes, however. In the section titled "Excluding, Ignoring, and Scraping Items", "scrap"--not "scrape"--is used numerous times as a verb.

b13 has been working for 24 hours and there's not a single error message or warning in the log. Lucky 13 indeed. Well done. Thank you!

I've made substantial rearrangement to my action schedule, with all except the ever-changing system folders on file change event-based schedules. It's a great feature for v2. Thank you very much. Two small issues arise out of this change, however.

1. Those event-driven actions take place more often than I expected due to meaningless (non)change to .DS_Store files. There are now numerous layers in those archives that contains nothing but one or two .DS_Store files. I know they take up very little space in the archives, and the layers will evently merge with those with substantive changes. And yet I still hope I can exclude all the .DS_Store files from most archives.

Currently there's no way to specify a .DS_Store file in archive settings UI because you can't select a hidden file. (The trick of using SHFT_CMD_G to go into hidden folders don't work here.) The "qrecall captureprefs" command works, but I wonder if the extended attribute QR uses would stick when OS X makes changes to .DS_Store files (I guess it depends on whether the system writes changes directly into existing files or creates a new one and then removes the old one).

More importantly, new .DS_Store are created all the time, and it's not practical to exclude them one by one. Hence my request: could you please allow more flexibility in this area? I would like to exclude, e.g., all .DS_Store files, all *.bak files, all *.*-journal files, and all "minidump" folders, just to name a few.

2. The current explanation for the option "Ignore new events for ___ (min./hours/days/weeks)" reads:

Ignore New Events

The ignore option will ignore new events that occur after the event that ran the action. To prevent new events from running the action again too quickly, choose the Ignore new events option and set a time period. The next event that occurs after the ignore period will run the action again.

I had taken it to mean--until I experimented with the option--file changes taking place in the "timeout" period would be backed up only when a new file change event after the timeout triggered the capture action. Should no new changes be made to the watched folders for a long time after the timeout, as a result, changes during the timeout would be without a backup for a long time.

In fact, QR behaves as I expect/want it to behave: all changes taking place during the timeout period are backed up as soon as the timeout period expires.

If my understanding is correct, I would suggest changing the option to something like "minimum time between actions" or "minimum time before the next action".

Thanks for listening.

Thanks! Can't wait to test the lucky 13.