Update July 23, 2018: The QRecall 2.1 beta is closed. If you are running the beta, use QRecall > Check for Update… to upgrade to the release version. Everyone else can download QRecall 2.1 on the Download page.

*** Thanks to everyone who participated ***

Dawn to Dusk Software is pleased to announce the beginning of the QRecall 2.1 beta test program.

To get started, go to the QRecall Download page.

If you already have a permanent or trial identity key, you can continue to use that. If don't have a permanent key, or your trial key has expired, click the button on the download page to obtain a free Beta Identity Key that will be valid for the entire beta test period.

The theme of QRecall 2.1 is "new technology." The user interface has been redesigned with a modern look, feel, and features (like sidebars, Quick Look, and full-screen mode). Underneath the hood, a massive rewrite of the code adopts modern technologies like automatic memory management, XPC interprocess communications, modern compilers, and much more.

As always, feedback is welcome and encouraged.

David Ramsey wrote:Deleting the files has cured the "runs multiple times per day at odd times" problem.

However, I think I am now noticing another problem.

Now, it seems that every backup takes a LONG time. For example, today's backup has been running for 39 minutes as I type this and has copied a mere 1.28GB of data (didn't do much today).

Performance problems.

During a QRecall capture there are about a thousand different things going on, which means there's a million ways it could be getting slowed down.

While the performance of the source volume could be issue, it's the least likely. One issue could be that QRecall can't use the volume change history for some reason, which will force it to perform an exhaustive scan of the directory structure. But for the most part it just reads directories and files, and unless there's something wrong with the volume (and it doesn't sound like it), this shouldn't be an issue.

It's much more likely that the size of the archive or the performance of the volume it is on will have more of an impact. Due to the nature of QRecall's data de-duplication logic, the amount of work required to add new data to an archive increases exponentially as the size of the archive grows. So if it takes 1 second to add X amount of data to a 100GB archive, it might take 8 seconds to insert that same amount of data into a 400GB archive.

Other factors include the archive volume's speed, bus latency, how full the volume is, and how fragmented the volume has become.

Now, that's not to say nothing is wrong, but it's really hard to tell from this distance given the number of things that could be affecting performance. If you like, send a series of diagnostic reports while one of these long-running captures are executing. The Send Report command samples all running QRecall processes and include that in the uploaded report. That could provide some clues as to what's eating up its time.

David Ramsey wrote:Can I delete these?

Yes. There's ever only one active lock file. The rest are orphans.

David,

Well this is mighty peculiar. You're running a regular scheduler, so when you log out and back in again, the schedule gets shut down and restarted.

When it starts up again it thinks the previous actions didn't run on time and starts them again, even though the log clearly shows that the scheduler started the action and saw that it finished.

It's possible the scheduler is having problems remembering what has run and what hasn't, so let's try this: in your ~/Library/Preferences folder, locate the com.qrecall.scheduler.plist file and trash it (along with any semaphore files that start with com.qrecall.scheduler.plist.). Restart your system and see what happens.

Curious indeed!

I could ask you a million questions, but I think it would be simpler if you would send a diagnostic report (Help > Send Report) from that computer. That will allow me to investigate/eliminate a whole bunch of possibilities.

Steven J Gold wrote:Curious minds want to know...

This is why I love my customers.

I have a 5 GB disk image file I'm backing up.
Actually, it's a "Sparse Disk Image Bundle" consisting of 560+ "bands" each of which is an 8.4 MB file.

I notice when I write to/modify the mounted disk image, the Date Modified for some -- but not all -- of the individual band files change.

Correct. A disk image is a file that pretends the be the blocks of a volume. If the package is broken up into individual files, only the files that correspond to blocks you changed on the "volume" get modified.

When backing up, does QRecall treat each of the bands as individual files even though at the higher level the OS (like Finder) treats the conglomeration as a single file?

Technically, it depends on how you backup up the disk image. If you capture the disk image file/package then QRecall sees them as regular files. If you capture the volume of the mounted disk image, QRecall capture those individual files as it would the files on any volume.

But it doesn't matter (at least to the size of the archive).

QRecall performs block-level de-duplication of the data, so it actually doesn't matter if the disk image is a single massive file, a collection of "bands," or the individual files stored on that disk image. Every file will be broken down into its individual data blocks and analyzed one at a time.

If I write to the mounted disk image resulting in say 100 out of 560 of the band files being changed, will QRecall only recapture the changed band files as opposed to the entire bundle?

Also correct. The advantage of using a disk image with individual bands is that QRecall can skip the analysis of the bands it knows have not changed. But in the end, it doesn't matter how many "bands" you have or which ones were modified, only the modified data blocks get captured.

You/I/we probably don't need that log file, as you seem to have a handle on the issue.

Feel free to toss your QRecall.log file(s) and restart; a new will be automatically created.

Ralph Strauch wrote:Lastly, as I'm writing this, the MBP just popped up another "Drive not Ejected Properly" message, while the drive is still sitting there, connected but not being accessed afaik.

I suspect this is happening more that you realize. The pattern I typically see is an intermittent hardware problem (external bus, cabling, power supply, drive controller, and sometime software) that causes a drive to spontaneously disconnect. It will then, almost immediately, reconnect so by the time you turn around it's already reappeared on the desktop.

This can occur repeatedly, without notice or harm. But when it occurs during a long-running process (like a QRecall capture or repair), then it can cause problems.

I looked at your logs. The QRecallScheduler process monitor and logs mount events. So I can tell that on your iMac, for example, your external volume BUD3 has unmounted and then immediately remounted itself over 60 times in the past month. Here are some recent examples:

2017-12-30 13:32:20.434 -0800 unmounted volume /Volumes/BUD3
2017-12-30 13:32:50.260 -0800 mounted volume /Volumes/BUD3

2017-12-30 13:32:50.983 -0800 unmounted volume /Volumes/BUD3
2017-12-30 13:32:54.054 -0800 mounted volume /Volumes/BUD3

2017-12-30 21:13:12.937 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:13:42.762 -0800 mounted volume /Volumes/BUD3
2017-12-30 21:13:43.982 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:13:47.059 -0800 mounted volume /Volumes/BUD3

2017-12-30 21:15:31.133 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:16:00.896 -0800 mounted volume /Volumes/BUD3
2017-12-30 21:16:02.297 -0800 unmounted volume /Volumes/BUD3
2017-12-30 21:16:05.435 -0800 mounted volume /Volumes/BUD3

2018-01-02 15:25:25.290 -0800 unmounted volume /Volumes/BUD3
2018-01-02 15:25:54.687 -0800 mounted volume /Volumes/BUD3
2018-01-02 15:25:55.759 -0800 unmounted volume /Volumes/BUD3
2018-01-02 15:25:58.805 -0800 mounted volume /Volumes/BUD3

2018-01-06 08:49:29.136 -0800 unmounted volume /Volumes/BUD3
2018-01-06 08:49:58.800 -0800 mounted volume /Volumes/BUD3
2018-01-06 08:50:00.213 -0800 unmounted volume /Volumes/BUD3
2018-01-06 08:50:03.285 -0800 mounted volume /Volumes/BUD3

2018-01-06 12:23:50.293 -0800 unmounted volume /Volumes/BUD3
2018-01-06 12:24:19.997 -0800 mounted volume /Volumes/BUD3
2018-01-06 12:24:21.318 -0800 unmounted volume /Volumes/BUD3
2018-01-06 12:24:24.404 -0800 mounted volume /Volumes/BUD3

As you can see, the volume occasionally unmounts, and then a few seconds later is mounted again. In most cases it does this again within a few seconds.

Honestly, the cause of this kind of thing can be difficult to track down, but swapping out components (try a different cable, swap power supplies, switch from eSATA to USB or vice versa) might narrow it down.

Ralph,

Here's what I found going through your logs.

First, I apologize for the "lost communications" errors you're getting. These are random interprocess communications failures caused by the legacy Mach Ports service. The only way to fix this is to completely rewrite QRecall to use the modern XPC communications. This work has already been done, but won't appear in QRecall until the next major version.

QRecall seems to be working as expected, although I can see why you might think there are problems.

The first set of actions are exactly as you described. You created a new archive (7th bu), started a capture, stopped it, started it again and let it finish.

Except for two issues, this all ran flawlessly. The first issue is that at some point (probably when uninstalling and reinstalling) QRecall is no longer pre-authorized. All of the capture actions are running with user-only privileges. This resulted in vast swaths of system files not being captured and reporting "Could not capture file/Insufficient privileges to read file/Permission denied" errors. It also explains the "Capture encountered problems" warning you see at the end.

The second issue is, of course, the lost communications link between the helper process performing the capture the the monitor app displaying its progress. My suggestion, for QRecall 2.0 and any macOS after 10.10, is to take any loss of communications error with some healthy skepticism. Instead of assuming the process has crashed (the original intent of that error), check Activity Monitor and see if the QRecallHelper process is still running. If it is, ignore the error and check back later to see what the log says. If the process completed successfully, it will log some king of completion message (hopefully "Capture finished"). That's the definitive answer to whether the action was a success or a failure.

2018-01-01 12:18:24.558 -0800 Capture finished (14:19:55)

You then restarted your computer and repaired the archive. Because there was nothing wrong with the archive, the repair completed successfully and reported no issues:

2018-01-02 14:43:12.323 -0800 Repair finished (2:31:33)

You then ran another capture followed by another verify:

2018-01-02 16:37:01.695 -0800 Capture finished (38:32)

2018-01-03 10:17:55.594 -0800 Verify finished (2:33:33)

Again, except for not having permissions to capture any system files and some communication failures, both actions ran successfully and to completion.

At this point I would suggest you re-pre-authorize QRecall to use administrative privileges. Go to QRecall > Preferences&hellips; > Authorization and turn on "Capture and recall items using administrative privileges". Then recapture your hard drive (this will take a bit since there is now a whole bunch of new stuff to capture).

Finally, I don't know what's causing the QRecall app to freeze on you. I don't see any '.hang' reports auto-collected by the system. If it happens again, launch Activity Monitor, select the QRecall app (which should say "not responding"), choose View > Sample Process (Option+Command+S), and send me the resulting report.

David Ramsey wrote:The proximate problem appears to be that the "iconservicesagent" process is hogging a tremendous amount of CPU time, up past 100%.

This is the culprit. Apple seems to have consolidated icon lookup/management/generation into this new background service. The bad news is that this service is really, really, slow—at least at the onset.

I don't know if it's the 10.13 upgrade, the APFS conversion, or some combination of both, but after installing High Sierra this process was driving me nuts. QRecall captures were glacially slow, with iconservicesagent maxed at 100% CPU while everything else crawled along. I have a folder of about 1,200 Photoshop files, and it was excruciating to open. In icon view, I'd scroll a page and the Finder would freeze for 30 seconds, scroll down a little more, and another 30 second freeze, and so on.

I suspect that the icon information gets cached somewhere, because over time things have improved dramatically. Or possibly some of the performance problems have been addressed in 10.13.1 and 10.13.2. Anyway, about a month ago I stopped noticing iconservicesagent being a problem. I can still catch it on the top list, but it's now unusual, rather than the norm. My 1,200 Photoshop files scroll about as fast I can page down and captures are back to their regular speed.

So with any luck, this might eventually take care of itself. Remember that all captures are incremental. Just let the capture run, maybe overnight, and stop if it hasn't finished. It will pick up again where it left off when you start it again. Once you're caught up, merge the incomplete layers with the final one.

Hello Matthias,

This could be any number of problems. Often it's just an installation issue.

First, you might simply try reinstalling QRecall. Open the QRecall application. While holding down the Option and Shift key, choose QRecall > Quit and Uninstall. Restart your system, launch QRecall again, and re-authorize it.

Whether this fixes the problem or not, please send a diagnostic report, so that we can look at the details. Open QRecall and choose Help > Send Report…. That will upload the details of what is, or was, going wrong.

Ralph Strauch wrote:Once Qrecall opens an archive, the only way to unmount that drive (without just pulling the plug) is to shut down the computer. Eject won't work, it just produces a notice that something else is using the file. This persists even when Qrecall and all other running apps have been quit, and even when I've logged out of my account and try to eject the drive from a different account. The only way to disconnect the drive seems to be Shutdown. The problem does not occur with files opened by other apps.

If you believe the problem preventing your volume from unmounting is an open file or files, there's an obscure command line tool that might help track the culprit.

The lsof (list open files) tool will list all of then open file descriptors in your system. Use the +D option to filter the list to only those items contained within a specific directory/volume, like this:

sudo lsof +D /Volumes/Stuck

will list the files/directories that are open on the volume Stuck. More importantly, the list includes the name of the process that opened the file and the user account it's running under.

To answer your question, QRecall can be uninstalled casually by holding down the Option and Shift keys and choosing QRecall > Quit and Uninstall command. For a thorough uninstall, see Help > QRecall Help > Guide > Advanced > Uninstall > Uninstall (the hard way).

However, I don't think uninstalling QRecall is going to fix anything.

Looking at the diagnostic report you sent, the QRecall app is hanging when it tries to open the archive file(s). Specifically, the call to open the file hangs deep in the filesystem. You can see this in the .hang file where QRecall calls open(), which eventually get stuck in check_file_access() > lck_mtx_sleep_deadline() > thread_block_reason().

Also, several actions are getting stuck obtaining write access to the archive files. Finally, one action crashed trying to close a mapped file in the archive.

All of these symptoms point to a problem with the drive or server that contains the archive. If it's a server or NAS, I'd first suggest restarting it; the server might have stale file semaphores that are causing problems. It might be connectivity problem. It also might indicate hard drive issues. It's hard to tease out a culprit from the logs, but that's the direction I'd look in.

Sorry about that. QRecall is (currently) a bit literal about UIDs and GIDs.

(An earlier version used to capture and lookup the UIDs based on the current account info, but there were other problems with that. I'll make a note to try and resurrect that option in a future version.)

The workaround is to just recall all of the files belonging to sjg (which will belong to 503), then simply change the ownership of all of your files back to 501 (the new and improved sjg). Here's how:

I would first create an second admin account for this. It will be *much* easier to do if you're not logged in as sjg at the same time. Log out of sjg and log into the new admin account. (I keep an admin account named "Maintenance" around just for silliness like this.)

Alternative: If you've already recalled these file and have them sitting somewhere, skip the new account setup and jump to the terminal stuff.

Use QRecall to restore your sjg home folder. This will overwrite your new sjg home folder with the captured version. At this point sjg is useless as all of the files belong to 503 and sjg is 501, so you can't even log it at this point.

Open a Terminal window and issue this command:

sudo -s

The terminal will prompt you for the admin account's password. After sudo -s returns, you'll be running a shell with root privileges. Now run these commands:

find -x /Users/sjg -user 503 -print0 | xargs -0 chown 501

find -x /Users/sjg -group 503 -print0 | xargs -0 chown :501

These command will find every file and directory in /Users/sjg and pass it to the chown command, which will change the ownership of the file/dir to 501. The second command does the same with the group ownership. These may take awhile to run, depending on how many files you have.

When these commands finish, everything owned by 503 in /Users/sjg will now be owned by 501. Issue the exit command in the terminal, log out, and back into your home account.

Note: you might have other files, outside of your home folder, that still belong to 503. You'll just have to deal with those on an ad hoc basis, but these commands can be reused with any directory, just change the path of the find command to whatever directory you want to fix.

Boy, I can't slip anything past you guys.

Yes, as mentioned in the release notes for 2.0.9, the certificate used to digitally sign the application and distribution disk image file have changed and are now correct. The previous version of QRecall was accidentally signed with my Mac Developer signature?a signature used to sign apps distributed via the App Store?instead of my Developer ID.