My scheduled backup this morning of my iMac showed a capture problem with a TechTool Pro backup file in Library/Applications Support. When I tried to open the archive to see if a good layer had been written the archive window flashed briefly and then qrecall crashed. Repeated tries to open the file produced the same result. I then ejected the backup drive from iMac and mounted it on my MBP to see what would happen there, and got the same result. The archive window flashes briefly then qrecall quits, so the problem is apparently within the archive.

Both computers had just been upgraded to qrecall 2.0.0(37). This was the first backup run on the iMac after the upgrade. On the MBP, the first backup after the update ran into a lot of problems "communicating with helper" but a subsequent backup immediately following appeared to run successfully.

I've sent reports from both machines. The qrecall crashes when I try to open the archive produced large Apple Crash Reports, which I can also forward to you if that would be helpful. I've started a repair on the archive and it appears to be running normally.

Backing up my MBP over wifi to a drive mounted on my iMac failed this morning, with a "Invalid parameter not satisfying: path!=nil" message. I ran it again, and the second time it failed with "cannot open negative hash map."

Some background that may or may nto be relevant. My log shows a "Problem encountered while closing archive" at 1am on Sunday, that must have resulted when the iMac ran a scheduled backup because I had left the archive open on the MBP. That may be irrelevant, though, because both the iMac backup and a subsequent MBP backup later on Sunday both ran successfully.

I had a backup issue tonight and and when I looked at the log I found that the files it had failed on were associated with Zoolz, a Cloud backup service I recently signed up for that was running at the time. In spite of the problems with those files, the backup produced a good backup layer that just didn't contain those files. I then turned off Zoolz and reran the backup, and it ran fine.

There's probably a way of excluding invisible directories and eliminating the problem, and even if not, it wouldn't be terrible not to be able to run Zoolz and Qrecall at the same time. I thought you'd like to know about this issue, though, as something that might come up in other situations when Qrecall is running at the same time as other data-intensive activities. The 2016-03-16 19:41:47 Capture to 2nd backup.quanta in the Report I've submitted is the one that displays the problem.

It looks just like the previous version. I'm really feeling stupid today. :^(

Thanks for straightening me out.

I miss being able to select and run an action from the same window. Not a big deal, but just a minor annoyance.

You should be able to do that now. Could you be more specific about what part of the interface you're using, what you're trying to do, and/or what's not working?

I'm talking about running actions from the Action window. In Qrecall 1.2 the Action window included a toolbar containing a RUN button. in Qrecall 2 that toolbar is absent, so it's necessary to move the cursor from the Action window up to the Action menu at the top of the screen to initiate the action.

James,

Thank you!!! I had jumped to the conclusion that the archive was unrepairable after several attempts at repairing it each left it still in need of repair,. After removing the repository companion files, though, the repair was successful, leaving me with a final damaged layer at the end. I deleted that layer and reran the backup, and I'm back in business.

A couple of other things:

Is it possible to exclude files within a package, and is it possible to exclude files by name regardless of where they occur? I'm thinking particularly about Render Files in Final Cut Pro Libraries, which can take up a lot of space and are easily replaceable so don't need to be backed up. I've sent a report covering all of that.

I miss being able to select and run an action from the same window. Not a big deal, but just a minor annoyance.

And thanks again for Qrecall and for the support you provide.

James,

I destroyed my archive the other day with a stupid error. I was backing up my MacBook Pro over wifi to a backup drive mounted on my iMac, and working on the iMac. Forgetting that the backup was running, I shut down and restarted the iMac, interrupting the ongoing backup. The archive now appears to be unrepairable, so I guess I'll have to start over and lose my historical archive. I'm sending reports from both computers, in case they are of any functional use for you.

Before this, the problems I was having earlier with the archive failing to close after a backup seem to have worked themselves out. The problem did seem to be related to the network connection with one particular drive, as it only occurred during backups over the network. But it also seemed like Qrecall was playing a role. In three particular cases, for example, on jan 14, 15, and 16 in the MBP log, the problem was in closing fill.scribble.index and Qrecall actually wrote the completed archive.

Right now I have no specific problem, just passing this info along FYI.

Yep, that did it. Thanks.

This isn't a problem with the app but with the website. I've been logged in for a while and can't seem to log out. When I click the "log out" button on the upper right I get taken to <https://secure.qrecall.com/login.jsp> where I get a blank page that says

"Not Found
The requested URL /login.jsp was not found on this server.
Apache Server at secure.qrecall.com Port 80"

When I try to log directly into <https://secure.qrecall.com> I get a "Welcome to OSX Server" page that offers me several options, none of which work.

This is using Safari 9.0.3. When I shift to Firefox and try to log in from there, I get a page that says

"Your connection is not secure
The owner of secure.qrecall.com has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website."

Ah, thanks! I didn't look closely enough to notice that the late December dates were 2016. Thanks for pointing that out.

The logs on both my MBP and iMac are putting all my 2016 log entries in between 12/26/15 and 12/27/16, as shown below. This log is from the MBP and I'm also sending a report from the iMac, in case that provides additional information.

Schedule	2015-12-26 15:17:29	       	Action 'Capture MBP-HD to 3rd backup.quanta' set to run at Today 3:17 PM 

Action	2015-12-26 15:17:30	-------	Capture to 3rd backup.quanta 

Action	2015-12-26 17:00:47	-------	Verify 3rd backup.quanta 

QRecall	2016-01-01 14:33:59	Minutia	Cannot connect to scheduler 

QRecall	2016-01-01 14:34:01	       	Installing system components 

Schedule	2016-01-01 21:58:03	       	Action 'Capture MBP-HD to 3rd backup.quanta' set to run at Today 9:58 PM 

Action	2016-01-01 21:58:04	-------	Capture to 3rd backup.quanta 

Schedule	2016-01-02 11:49:55	       	Action 'Merge Layers in 2nd backup.quanta' set to run at Today 11:49 AM 

Action	2016-01-02 11:49:56	-------	Merge layers in 2nd backup.quanta 

QRecall	2016-01-02 12:16:03	Warning	Unable to open document 2nd backup.quanta 

QRecall	2016-01-02 12:16:18	Warning	Unable to open document 2nd backup.quanta 

Action	2016-01-02 12:19:27	-------	Verify 2nd backup.quanta 

Schedule	2016-01-02 12:24:27	       	Action 'Merge Layers in 2nd backup.quanta' set to run at Today 12:24 PM 

Action	2016-01-02 12:24:28	Minutia	Merge layers in 2nd backup.quanta 

Action	2016-01-02 12:25:12	Minutia	Install 

Action	2016-01-02 12:25:20	Minutia	Install 

QRecall	2016-01-02 12:25:23	Minutia	Removed resource link QRecallScheduler 

QRecall	2016-01-02 12:25:23	       	Updating system components 

Monitor	2016-01-02 12:25:24	Minutia	Cannot connect to scheduler 

Schedule	2016-01-02 12:28:53	       	Action 'Verify 2nd backup.quanta' set to run at Today 12:28 PM 

Action	2016-01-02 12:28:54	-------	Verify 2nd backup.quanta 

Schedule	2016-01-02 21:38:12	       	Action 'Capture MBP-HD to 2nd backup.quanta' set to run at Today 9:38 PM 

Action	2016-01-02 21:38:13	-------	Capture to 2nd backup.quanta 

Schedule	2016-12-28 08:56:27	       	Action 'Capture MBP-HD to 3rd backup.quanta' set to run at Today 8:56 AM 

Action	2016-12-28 08:56:28	-------	Capture to 3rd backup.quanta 

Schedule	2016-12-30 14:59:46	       	Action 'Capture MBP-HD to 3rd backup.quanta' set to run at Today 2:59 PM 

Action	2016-12-30 14:59:47	-------	Capture to 3rd backup.quanta 

Action	2016-12-31 17:41:16	-------	Recall from 3rd backup.quanta 

Action	2016-12-31 17:43:02	-------	Recall from 3rd backup.quanta 

Schedule	2016-12-31 17:54:46	       	Action 'Capture MBP-HD to 3rd backup.quanta' set to run at Today 5:54 PM 

Action	2016-12-31 17:54:48	-------	Capture to 3rd backup.quanta 

Schedule	2016-12-31 19:07:52	       	Action 'Capture MBP-HD to 3rd backup.quanta' set to run at Today 7:07 PM 

Action	2016-12-31 19:07:53	-------	Capture to 3rd backup.quanta

James,

I've trashed the archive that wouldn't repair, replaced it with a new archive, and backed up both computers successfully and uneventfully. I've now swapped that drive out and brought my other offsite drive back in, and backups are running fine on it as well, so hopefully I'm back in business.

I don't think the problem was a bad drive, since it seemed to affect both drives equally during the period it was happening. I did seem to be having network problems, which definitely contributed.Some of those involved scheduled backups run automatically at night when both machines were otherwise asleep so I'll just skip that for a while and backup the MBP manually during the day, at least until I accumulate a history of stability with v2.0.

I am still concerned about the seven failures cited above, which all appear to occur as the archive attempted to close immediately after writing the backup to the archive and the backup statistics to the log,. The timing of these failures, occurring at a specific well-defined point in a long ongoing process, makes it hard to attribute them to a source external to that process, like a mechanical or network failure.

I'm curious -- what app are you pasting the log entries from, to get that formatting and the line numbers?

I tried a couple of more times to repair my archive and both attempts failed, so I guess this archive is toast. I?m not convinced, though, that the problem is with the drive. In the two months I have been using Qrecall v2.0 beta, this particular problem -- where a backup that appears to be successfully completed and written to the archive experiences a fatal error as the archive is being closed -- has occurred 7 times, involving two different archives and backup drives, run both over the network and directly mounted to the computer.

Both drives have been given a clean bill of health by Disk Utility, Tech Tool Pro, and Diskwarrior. The failure always seems to occur at the same point in the backup being performed ?- after Qrecall has recorded all the statistics for the backup and is closing the file, so it seems unlikely that it could be due to a mechanical or network problem unrelated to the backup task.

Here?s a list of the backups that have experienced this problem.

Action 2015-11-08 11:12:38 ------- Capture to 3rd backup.quanta
2015-11-08 11:32:24 Captured 4207 items, 1.07 GB (50% duplicate)
2015-11-08 11:38:12 Failure Problem closing archive

Action 2015-11-11 06:24:16 ------- Capture to 3rd backup.quanta
2015-11-11 07:26:51 Captured 787 items, 447.8 MB (83% duplicate)
2015-11-11 07:39:03 Failure Problem closing archive

Action 2015-11-16 03:04:33 ------- Capture to 2nd backup.quanta
2015-11-16 07:31:53 Captured 750 items, 440.8 MB (56% duplicate)
2015-11-16 07:42:48 Failure Problem closing archive

Action 2015-11-19 03:37:19 ------- Capture to 2nd backup.quanta
2015-11-19 07:53:57 Captured 1785 items, 610.6 MB (61% duplicate)
2015-11-19 08:47:46 Failure Problem closing archive

Action 2015-11-30 08:56:33 ------- Capture to 2nd backup.quanta
2015-11-30 09:08:35 Captured 1732 items, 417 MB (52% duplicate)
2015-11-30 09:11:35 Failure Failed

Action 2015-12-06 03:00:01 ------- Capture to 3rd backup.quanta
2015-12-06 03:17:56 Captured 1077 items, 838.9 MB (59% duplicate)
2015-12-06 03:27:38 Failure Failed

Action 2015-12-10 10:35:35 ------- Capture to 3rd backup.quanta
2015-12-10 10:55:26 Captured 1643 items, 922.4 MB (58% duplicate)
2015-12-10 11:07:33 Failure Problem closing archive

I've had another "problem closing archive" failure, where it looks from the log like the entire backup was written to the archive before the failure occurred. I tried to repair the archive and that failed as well, leaving me with long lists of invalid data and error corrections.

This was a backup of my MBP run over the network with the archive drive mounted on my iMac. I moved the disk to the MBP for the repair, to take advantage of USB3 speeds. I was running b25. This is a different backup drive from the one that exhibited this problem in November.

As soon as I send the report I'll update to b26 and run another repair.

I?ve now repaired my archive and run a manual backup of my MBP and everything seems fine. The repair log shows a long string of chunks of invalid data throughout the archive, along with one instance of ?Communication problems with command listener on port QRecallApplication? and three of ?Distributed objects message send timed out? at the end of the log. I?ll send a Report.

You?ve said elsewhere that the invalid data will be discarded and that the archive will contain only valid files, and I?m a bit confused about the result of that process. Will I lose files which were found to contain invalid data, or only the versions of those files which contained the invalid data?

This problem has occurred only with scheduled overnight MBP backups, so I?ll move the drive back to the iMac and let the iMac scheduled overnight backups run, but just run MBP backups manually during the day for a while.

As I said in the thread on Encryption, <http://forums.qrecall.com/posts/list/567.page>, I?ve been mounting my backup drives on the MBP because my Airport Extreme can?t read a FileVault encrypted drive. But if this problem is caused by backing up one computer to a drive mounted on another perhaps shifting from FileVault to Qrecall encryption and going back to mounting the drive on the AE would be a solution. What do you think?