See the Actions section in the 2.1(24) beta release notes.

The details about the action that will/did ran is provided as environment variables.

Post here if you have questions.

Ralph,

The Finder (and probably the Open/Save UI) all know about "ubiquitous" (iCloud) documents and present them as if they were in this special place called the iCloud Drive. The same is true of app-specific documents, like your Keynote documents. In reality, they all live in a special hierarchy inside the ~/Library/Mobile Documents folder, which we (being mere users) are not to concern ourselves with.

The rules for when and why a document is stored on your local system or only as placeholder is a complex mix of criteria. Obviously, if you open the document macOS will immediately download a copy. After that, it depend on how big the document is, how fast your network connection is, how often you access that document, how much free space is on your startup volume, and so on.

Bruce Giles wrote:Is there a way to tell QRecall to ignore actions while powered off, and just resume at the next scheduled interval after powerup?

Not yet, but this is still on the short-list for 2.1 (and that short list is getting pretty short).

Ralph,

Thank you for being so patient.

I had a chance to look into this today and I think I understand what's going on. Apple is playing some clever shell game in the Mobile Documents folder, just not the game I thought they were playing.

I have "successfully" backed several iCloud Drive folders and documents here. And by "successfully", I mean that QRecall faithfully captured the iCloud Drive files store on my local "Mobile Documents" folder.

However, this might not be what you expect. Documents in the iCloud Drive folder can be locally cached copy or merely placeholders for a document you have in the cloud. In the Finder, a placeholder appears with a little "cloud" icon next to it, which means it isn't physically stored on your hard drive at the moment.

On you local drive, these "cloud" documents are stored as tiny invisible .icloud documents containing bookmark information about the original.

And sure enough, QRecall captured all of those placeholder files. But, since the files are normally invisible, they do not appear in the QRecall browser unless you turn on "Show Invisible Items". (The Finder obviously knows about these special placeholder finds and displays them as regular files, even though they are invisible.)

If you capture the files, open the archive, and set "Show Invisible Items" you'll see all of the cloud documents that QRecall captured. But, obviously, these aren't the actual documents, just the placeholders, since QRecall doesn't download the shared document from the Internet.

For iCloud documents that are currently cached on your system?the ones that appear without the little "cloud" icon?those are just regular documents and get captured just fine.

Good new:

It turned out the menu bar icons for the activity monitor just needed a special "template image" flag set, and it wasn't set.

Bad news:

"Template" images are always monochrome, so the colored indicator to show that there's a warning or problem in the status window now draws just a grey dot, indistinguishable from the "busy" dot.

Update: I decided to add some code to detect the "dark mode" setting and draw a colored icon for regular menubar users and the monochrome version for dark mode users.

Let me know your opinion in the next beta release.

Charles Robinson wrote:I'm sure maintaining the app keeps you quite busy

...
That's an understatement.

I didn't have dark mode menubar on my to do list, but it shouldn't be very hard. Since 2.1 is all about the UI updates, I'll see if I can squeeze that into this release.

Alexandre,

That was indeed the problem. The latest report you sent shows the restore command couldn't get the info for the Boxcryptor volume.

Glad to hear the patch fixed it.

Alexandre,

Thank you for the diagnostic report.

Yes, it's a bug. QRecall is crashing when trying obtain the list of volumes on your system. For some unknown reason, one or more of the browsable volumes on your system returns an error when QRecall asks for the volume's specifics. And that's where it gets in trouble; it tries to log the volume details and crashes.

I've (hopefully) modified the code so it can log the failure without crashing. (I have no way of testing this since this situation has never arisen here and you're the first user to report it.) I'll email you link to a patched version of QRecall that you can try.

Please send a follow-up diagnostic report after you try this so I can see the success (or failure) of the new version.

Alexandre,

If you haven't already, please sent a diagnostic report (in the QRecall application go to Help > Send Report). If the process crashed, there should be a crash log that we can look at.

If the process didn't crash, and it simply lost its connection with the action, that should be in the log too.

Ralph,

Thanks for the update. I've got this on the "to be looked into" list, but haven't gotten to it yet.

And sorry about the thread: the beta announcement topic wasn't supposed to be open for comments, so I locked it after your post.

Bruce Giles wrote:I'm less sure I like that behavior with invisible folders. I may be misunderstanding your intent here, so let me ask a direct question. If I'm backing up my entire hard drive, then am I just going to see "Private Folder" for the entire time while it backs up /bin, /cores, /dev, /etc, /home, /mach, /net, /opt, /private, /sbin, /tmp, /usr, and /var? If that's correct, that would NOT match my expectations. If I saw "Private Folder" listed in the activity window while it did all that, I'd probably be wondering what was wrong.

Let me clarify. The "Private Folder" was just a hypothetical example; the status will display the actual name of whatever invisible or unreadable folder is being captured. When the capture encounters an invisible (/private) or unreadable (/Users/somebodynotyou/Desktop) directory, it will display that directory's name ("private" or "Desktop") until it's finished with that directory subtree.

Now (well, soon) the idea is that the items displayed in the capture progress are whatever you could normally encounter by browsing in the Finder (without using any hacks or special Finder commands like Option+Command+L or "Show Package Contents").

Examples would be a .git folder (all dot named directories are implicitly invisible) and ~/Library, because that folder is explicitly made invisible.

I like this because the default will be to honor the access restrictions for the regular user. So even though your QRecall account might, technically, have permission the access all of the documents for other users, it seems polite not to have those filename flashed on the screen.

Anyway, you're welcome to set QRMonitorInvisibleFolderProgress if you don't like it.

Bruce Giles wrote:At first I thought it might be because I'm backing up a folder that contains only a single enormous file -- the VMware virtual machine file. But that file is actually a package containing many files, only one of which is screenshot_0000.jpg.

Ah yes, packages.

This reminded me that I've had a bug report on the books for eons that the file progress doesn't update correctly inside of packages (and I suspect invisible folders).

I started looking into this, and it was like pulling a thread on a sweater; the more I pulled, the more the logic didn't make any sense.

So I rewrote it all today. Here's how it work (in the next beta). This is a little on the experimental side, so I'm looking for feedback.

QRecall no longer reports the progress of individual items inside a directory if that directory is either opaque (package, application, bundle, etc.) or if it is either invisible or inaccessible as a regular user. Instead, it will simply report that it is capturing "Private Folder" or "Adobe Photoshop.app".

Also—and this is the experimental part—it will no longer collect icon or localized display information about these files. The advantage is a (marginal) capture performance improvement. But it also means that if you enable the viewing of invisible items or packages in the archive browser, you won't see pretty icons or localized names for those items.

Finally, if you like this kind of detail there are two new advanced settings: QRMonitorOpaqueFolderProgress and QRMonitorInvisibleFolderProgress. Set them to true to enable the progress reporting of those items (although this doesn't change the display metadata collection).

Bruce Giles wrote:1) The indeterminate progress bar in the Activity window is still nearly impossible to tell from a 100% full progress bar. I realize that's an OS issue, not really a QRecall issue, but Apple has apparently decided this isn't enough of a problem for them to do anything about it.

While I can't do anything about Apple's control design, you'll notice that the collapsed version of action (click to toggle between the two) has a new-and-improved background progress indicator of my own design, which I hope clearly distinguishes between these two states.

2) I'm doing a new backup, to a new archive, of my VMWare Fusion virtual machine file. It's been running for about 42 minutes so far, and backed up about 130 GB, and for the entire time (except for perhaps the first few seconds), the Activity window says "Capturing screenshot_0000.png", which is only a 1.9 MB file. I'm sure it's backed up way more than that, but it just seems a little odd. Is there anything you can do in the new version of QRecall to help with that?

I've looked that this code a lot and don't see why it should be doing that. Having said that, I've recently made performance improvements in the code that updates the activity monitor with the status of the running action; one side effect is, I hope, more timely updating of the actual status. See if the next (post 2.1.0b32) version improves anything.

Ming-Li Wang wrote:Very happy to see v2.1 in beta. I'm you'll beta 31 on macos 10.13.4.

Welcome aboard!

First bug to report: QRecall sometimes has troubles deleting items from an archive, taking a long time waiting for the archive to close. (screenshot 1)

Actually, it's waiting to open the archive. QRecall thinks that some other process might be using the archive and is waiting for it to stop. Sometimes, particularly if a process is on another computer, it can be hard to tell and QRecall will cautiously wait about 10 minutes before proceeding. If everything is working perfectly, this shouldn't happen as the last process should mark the archive as "not busy." Hopefully the report will have some clues.

The dialog would say "complete" if I wait long enough, but it won't go away, and the "Stop" button would be grayed out and unclickable. (screenshot 2)

This is a known bug that I'm still investigating. Basically, the QRecall application loses its connection with the command process at the last moment and gets stuck in a dialog because (a) it can't tell the command to stop and (b) it hasn't gotten a message from the command that says it's finished. Again, your report (and reports from others) should help figure this out.

I've run into the problem numerous times with two different archives, so it doesn't seem to be archive-specific. I've deleted items from both archives successfully as well, so it seems random to me so far.

You are correct, it is not archive specific, or even command specific; this can happen with any command.

A report has been sent.

Thanks.

Ralph,

I'll have to spend some time researching this.

I suspect the iCloud folder is actually a mountpoint, or a collection of mountpoints, for a virtual filesystem who's content resides on different logical device, but it will take a bit of investigation to confirm this.