Sorry to hear your trial key isn't working.

It's likely due a quirk (bug) in OS X. Starting around OS X 10.9, access to preference files are coordinated by a background process named cfprefsd. This is actually a good thing, and solves a lot of issues with multiple processes stomping on each other's preference values.

Unfortunately, it also introduced a bug where one process can't see the changes made by another process for long periods of time, sometimes indefinitely. When you entered the trial key it was stored in your QRecall application preferences, but the helper process (the one that actually performs a capture) can't see it.

Usually a restart of your system is all that's needed to clear the log jam. Try that and see if the trial key starts working. (Killing the cfprefsd might work too, but I've had reports that sometimes that isn't enough.)

If that doesn't work for some reason, send a diagnostic report: in the QRecall application choose Help > Send Report… and we'll look further into it.

If your snapshot files (which tend to be large) are slowing things down a lot, you might want to check your shifted-quanta capture setting (Archive > Settings...). Shifted-quanta detection will not be beneficial for either disk image or memory images files. So for VMWare, it should be set to its lowest setting or just turned off.

If that doesn't help, there are additional things to try.

It's also unlikely that QRecall is spending a lot if time capturing .lck files. These tend to be very small semaphore files. It's more likely that a .lck file was just the last thing it captured while looking for the next thing to capture.

It was just coincidence then. The timing (action started running at 10:03:37 and the volume mounted at 10:03:40) made it look like the volume had been automatically mounted by QRecall.

The errors you're getting when the volume is mounted using AFP are strange indeed. I'm not entirely sure what to make of them.

A prime example is the capture that failed today. The archive couldn't be opened because the length of the negative hash map file was reported to be -4 by the operating system. I don't think I've ever seen a negative file length.

I will also note that the volume containing the archive was not mounted when the action started, so QRecall mounted the network volume automatically. (This also appears to have caused two other volumes to mount at the same time.) All three volumes were mounted using AFP.

Because of this, I might offer the possibility that when OS X mounts the volumes they get mounted using AFP, but when your utility mounts the volume they get mounted using SMB.

I can't offer any advice as to why your NAS suddenly decides to mount your volumes using AFP, but the vendor might.

I would be interested in investigating why your archive is getting corrupted and needs repair. If you can, please send a diagnostic report from the computer that is mounting the volume using AFP and trashing the archive.

Apple File Protocol (AFP) has a few known bugs, and older versions have a bunch of bugs. So it might depend on what version of AFP your NAS is running.

If you're still running QRecall 1.2, there are some advanced setting designed specifically to work around some of these bugs. QRecall 2.0 uses a different filesystem API that was supposed to put this kind of incompatibility behind us, but depending on the version of AFP there still might be issues.

The two biggest stumbling blocks in APF are a pre-allocation bug that ends up filling the volume and a file-size limitation. The pre-allocation bug can be worked around. But if it's a very old version of AFP that can't write really large files, there's nothing QRecall can do about that.

Ralph,

Yikes, that's a lot of errors.

Most of the errors do appear to be related to network communications. Most of the captures/verifies/repairs that fail predomenatnly report POSIX error 60 or 6.

Error 60 is an "operation timed out" error, usually associated with a network communications socket or device channel. Error 6 is a "no such device" error; in this context it usually means the volume/drive being addressed is no longer connected.

A lot of your failures follow the pattern of getting "timed out" errors, later followed by "no such device" errors. I suspect you're having network communications or remote storage device problems that initial stop responding to requests, and later appear to go off line. You can see this in events such like that starting on May-12 where the first capture starts but dies with an error 60. Subsequent actions then fail because they can't access any archive files (error 6).

I also see that your archive's volume tends to get mounted and unmounted a lot. At first I thought this might be an indication of a problem, but the timing wasn't quite right. Instead, it seems to be by design; you apparently mount the volume and then manually start a capture action. (Just FYI: if the volume can be automatically mounted, QRecall will mount, and unmount, the volume for you.)

I did find one really suspicious sequence of events that I think lead to all of the problems on May-9. The volume was mounted at 12:23 and the capture action was manually run a few seconds later. The capture action ran until 13:17, at which time it encounted network timeout errors (60) that prevented it from finishing. But before that, it appears that the system was put to sleep:

2016-05-09 13:16:30.695 -0700 Power Management will go to sleep

2016-05-09 13:23:29.285 -0700 Power Management did power on

(Please note that there's another possible problem here. Starting somewhere around OS X 10.10, the kernel is letting background processes run in the so-called "power nap" mode, where the system is mostly asleep but some background processes are still running. Unfortunately, QRecall seems to be one of the processes that it's allowing to run, but not enough of the rest of the system is awake to function correctly and errors ensue.)

It's been my experience that network sockets don't like to be put to sleep, and can take quite awhile to recover when the system wakes up again, which is probably the source of that particular failure.

Without anything definitive to go on, I'd recommend trying to isolate the pieces one at a time and see if you can find some improvement.

First, is it possible to eliminate the network and server for a trial and connect the archive drive directly to the system, just to make sure it's not the drive or something else?

Then try to replace pieces one at a time to see if that makes any difference. Try a different network connection. If you're using WiFi, try to hook up a hard-wired ethernet cable. If you're using ethernet, see if you can use IP-over-Firewire or something. Can you move the archive drive to a different server?

I know I'm not being terrible helpful, but I hope it gives you some ideas to try.

Steven,

Unless you reformat your boot volume, or transfer your boot drive to a new drive, it won't make any difference at all. QRecall primarily identifies volume by their UUID, and unless you migrate to a new partition/drive, your UUID won't change and your volume's name is largely immaterial.

If, in the future, you do reformat or migrate your boot volume so it has a different UUID, QRecall will then try to match the volume in the archive with your boot volume using a combination of the volume's name, the date it was formatted, and its size. So if you replace your startup drive (now named El Capitan), and later want to dig back into your archive (when it was still named Yosemite) and try to restore an item, QRecall might not be sure where to restore it to. In this case, you'll have to recall the item and manually locate the original item to replace.

That's the worst case scenario.

Marc Bizer wrote:Are you familiar with the backup utility Arq? It doesn't do data deduplication, but I'm pretty sure that it just keeps an archive of files on Google Drive, Amazon S3, etc. with some sort of index on one's local hard drive. I don't know whether it's possible to send just quanta via these cloud APIs -- have you checked Google's for example?

We continue to explore these technologies. The problem is they either fall largely into one of two kinds of solutions: file storage or databases. The file storage solutions don't scale well, and the database solutions suffer from unacceptable latency or huge index key sets. But we continue to look at them...

Another question: if I stored the QRecall archive on an NAS or Time Capsule, would QR automatically mount and unmount the storage volume?

Yes. If the archive for a scheduled action is not mounted, the scheduler will attempt to mount it before running the action (and will attempt to unmount it again when the action finishes).

I see QR as a great replacement for Time Machine -- except that you can't use it to restore an entire hard disk, right?

Absolutely, you can. See the help section QRecall Help > Guide > The Basics > Restore Items and Restoring a Volume to a Different Volume. For more sophisticated restore solutions, see QRecall Help > Guide > Troubleshooting > Restoring OS X.

Marc Bizer wrote:Sorry to persist, but if the user isn't supposed to know what is underneath, why have the UI rely on a terminology that is keyed to what is happening underneath rather than to what the user is experiencing?

So you don't mis-apply preconceived notions about what's happening.

Besides, the UI doesn't hide what's happening. If you use the upper and lower shades to isolate a single layer, you don't see a "snapshot" of your files that day. You see a positive delta of what changed, which is the essence of layers.

Marc Bizer wrote:What about macupdate.com? They still list version 1.2.3 as the most current.

That's odd, because until recently MacUpdate.com was subscribed to our version RSS feed. They'd often have our latest version and release notes within minutes.

I'll make a note to update their listing. Thanks for the heads-up.

Marc Bizer wrote:I appreciate your precision, but in terms of interacting with the software (UX), does it really matter what is happening underneath?

We certainly like to think so!

Marc Bizer wrote:So what about plans to allow backup to online servers, such as Google Drive, Box, and Amazon S3?

Investigation is ongoing, but we don't have a solution yet.

The problem with most of these networked file synchronization solutions is that they are file oriented. In other words, you make a change to a local file and that file will be uploaded?in its entirety?to the server. Later, it will be downloaded?in its entirety?back to your other devices.

The bulk of a QRecall archive is a single database file that contains all of your captured data. So if you added a 150K image file to a 100GB archive, a file synchronization service would dutifully re-upload your entire 100GB archive file. This is not only horrifically inefficient, but ludicrously wasteful, and you still need enough local disk space to keep the copy of the on-line archive.

We are actively exploring three different solutions. The first is a simple "cascade" feature what will allow you to incrementally synchronize an off-site archive with a local one. Another is a client/server version of QRecall allowing you to efficiently capture to a QRecall service over the network. And finally, we're exploring leveraging massive database services like Amazon DynamoDB and Redshift, but we've yet to prototype a workable system so we don't know what the performance is yet.

Marc Bizer wrote:I'm curious as to why the developer has adopted these terms. The standard equivalent for "layer" and "capture" is "snapshot," for example. If one wishes to use "capture" as a verb, then why not just use "backup"?

Excellent question!

It was a conscious decision to use different terms because, in the very early stages of development, it became clear that the standard terms ("backup," "copy," "clone," "snapshot," and so on) were inaccurate and carried too many preconceived notions.

We never use the term "copy" because QRecall does not copy files. We don't use the term "snapshot" because QRecall never makes a snapshot of your existing files.

QRecall maintains a database of discrete, individual, unique, blocks of data we refer to as "quanta". A file is a collection of quanta. When you capture a file, it's disassembled into its quanta and added to the database in a manor that never stores the same quanta more than once.

During the capture, a layer is created. A layer is not a "snapshot," it a set of positive deltas that describe what has changed. In other words, QRecall never stores any information about what is, but only what's changed.

I like to think that QRecall is to backups what holography is to photography.

QRecall works more like a modern version control system. And you notice that git never talks about "copying files" or "taking snapshots." git commits new nodes to a repository. The nodes represent deltas, and a repository is a network of nodes that can be used to reconstruct a set of files at a given point in time.

Now we don't object to the idea of "making backups" or talking about "snapshots" of your files, because at the end of the day QRecall is essentially copying files. And all of those positive deltas can be combined to calculate a "snapshot" of your files at a point in time (which is exactly what is happening when you see the "compositing" message in the QRecall item browser).

So if you want, feel free to think of QRecall as copying files, making backups, and taking snapshots. Just remember that that is not what is happening under the hood.

Bruce,

Excellent suggestion. I'll make sure they get a copy of the press release tomorrow.

The future feature I'm thinking of is the ability to execute a script, either before or after, an action runs. The script that runs before will have the ability to cancel the action.

It would then be possible to write a script that determines if the the database daemon is running and cancel the capture. You would then create a capture action for each MS Office application, and the script would prevent all but the last application to quit from running the action.

You could almost do that now with schedule conditions, but currently you can only attach one "ignore if application X is running" condition. I'd like to expand that too, so you can attach multiple application conditions. Using that technique, you could create an action the captures when you quit Word, but then ignore the action if any of the other MS Office apps were running. Again, the idea to let only the last application that quits trigger the capture.