Current user of version 2.2.12. I've cloned a copy of my current backup archive and downloaded the beta 3 dmg, but have some questions I'd like answered before proceeding as it appears the beta will replace my current version of the app and its subsystems since the names are the same...

In no particular order:

1. Any plans to allow iCloud to be an stack destination? i.e., create an stack container on iCloud Drive ?

2. Does the beta respect file attributes set on an individual file/folder from version 2 via the Services menu?

3. Can the Beta run along with version 2, or does version 2 need to be removed in order to test the beta? (I notice many of the component names are the same).

4. Can the archive destination be either HFS or APFS? Any advantage using one over the other?

Steven J wrote:1. Any plans to allow iCloud to be an stack destination? i.e., create an stack container on iCloud Drive ?

That should be possible within the next couple of weeks.

2. Does the beta respect file attributes set on an individual file/folder from version 2 via the Services menu?

Capture preferences have not changed, and both versions 2 and 3 support the same set of options.

3. Can the Beta run along with version 2, or does version 2 need to be removed in order to test the beta? (I notice many of the component names are the same).

Sadly, no. Two versions of QRecall cannot coexist. An archive you use with version 3 will be upgraded and will not be backwards compatible with version 2. If you save the original archive, you reserve the option of uninstalling version 3 and reinstalling version 2.

4. Can the archive destination be either HFS or APFS? Any advantage using one over the other?

There are some advantages to using APFS volumes for your archive. QRecall now takes advantage of file cloning, so actions like capture start and finish faster, and there's less chance the archive can get left in a state that requires it to be repaired. The disadvantage is that APFS volumes tend to get more fragmented (hurting performance), which is something we're working to address.

James Bucanek wrote:

Steven J wrote:1. Any plans to allow iCloud to be an stack destination? i.e., create an stack container on iCloud Drive ?

That should be possible within the next couple of weeks.

Reading this gives me hope that maybe Google Drive or OneDrive will be supported someday? For students and people working in an educational institute, the price of Google Drive or OneDrive can't be beat--they are free, with ample space. I have terabytes backed up on Google Drive, and will never switch to iCloud or S3 for that purpose.

I have been running v3 betas on my system for a few months without issues, but have yet to try the "stacks" feature, mainly because it seems to be something useful only for backing up to the cloud. Am I right? Or is it something worth doing even when backing up locally?

Thanks!

M Wang wrote:Reading this gives me hope that maybe Google Drive or OneDrive will be supported someday?

QRecall stacks might be compatible with Google Drive or OneDrive already, I just haven't tested those yet.

Basically, QRecall stacks should work on any cloud drive service that (1) automatically uploads items stored on the local "drive" to the cloud, (2) replaces the local copy with a placeholder, and (3) transparently downloads the original item again whenever that file is accessed.

Most cloud drives work this way.

The problem with iCloud (which may, or may not, be an issue with Google or OneDrive?again, haven't tested them yet) is that iCloud treats the entire stack container as a single document. So simply trying to check the status of the stack container document ends up re-downloading all of its individual parts, which completely defeats the purpose of using a cloud document.

The next update to QRecall 3 will address this.

I have been running v3 betas on my system for a few months without issues, but have yet to try the "stacks" feature, mainly because it seems to be something useful only for backing up to the cloud. Am I right? Or is it something worth doing even when backing up locally?

Stack document can also be used for local redundancy. Specifically, a lot of users capture their documents to an archive. They then either sync or copy that archive to a second drive which is taken off-site, or they rotate between a set of archives (at least one of which is always off-site).

Stacks can simplify this off-site drive rotation, and is much more efficient at doing so.

Thanks for the detailed explanation. I don't have Google Drive "installed" on my system, as I use it only for backup purpose. Those cloud storage drivers are notoriously review hungry and tend to make the system less stable, and I've tried to stay away.

My current cloud backup solution is Arq, which manage cloud connections by itself, and I hope someday QRecall can do the same.

Take your time, though. No rush.

Thanks for the excellent software, as always.

Promises of an iCloud Drive compatible stack container were premature.

Over the past few weeks, we've encountered some technical difficulties in reliably using iCloud Drive as a stack container. We are committed to getting this to work, but it will take some more time.

We've tested the existing Document stack in Dropbox and Google Drive and it appears to be working just fine.

For Dropbox:

Install the Dropbox extension.

In Dropbox ? Preferences ? Sync, turn on Smart Sync (Save hard drive space automatically).

Create a Document stack container and store it anywhere in the Dropbox location.

For Google Drive:

Install the Google Drive extension.

In Google Drive ? Preferences ? Google Drive, turn on Stream Files.

Create a Document stack container and store it anywhere on the Google Drive volume.

These are not ideal solutions, but they work. We will probably develop Dropbox and Google Drive specific containers, but that's further down the to-do list.