I just did a recall of an external drive that I had accidentally wiped. The final notification was something like "recall incomplete."

While the recall was in progress, there was a log entry. It showed one file that was unable to be restored, but it was trivial, like a spotlight file or some other hidden file.

But now that the recall is done, I wanted to check the log again and there's no log entry! My goal is to find out what files were not successfully recalled and just make sure there were no significant issues.

Mike,

I assume you were restoring your entire startup volume.

The bad news is that your startup volume includes your log files. So the restore replaced your working log files (the ones being written during the recall) with your captured log files. (Note that it also restored your QRecall preferences and other ephemeral settings.)

This conundrum has been partially addressed in QRecall 3.0, but not entirely.

Actually I was recalling an external drive that has no programs on it and is not the boot drive, just data.

Strangely there was a log entry while the recall was running, but it disappeared. I thought about doing a verify before QRecall captured the external drive again, but it already did capture it again and might think the missing files are not there on purpose. Can you throw away a layer in the archive, then do a verify? Does verify tell you what files are missing/corrupted or does it just fail?

Mike

Then that's very odd. Then the message is probably in there somewhere. You might increase the detail level of the log window. Or you can just search the log files manually (they're just plain text files). less and grep are your friends.

The recall issue you saw was most likely something to do with the recall process itself; a permission error, or out of disk space, or something like that. A data corruption in the archive (which is what a verify would reveal), would have stopped and immediately terminated the recall command with a fatal error.

I found the section of the log at the point the restored finished. Maybe you can explain this.

2021-09-27 05:31:19.551 -0700         Restored 128027 items, 1.14 TB (1,143,542,559,569 bytes) [2.73806095.2067.11]

2021-09-27 05:31:19.551 -0700 Details files: 175,402 [2.73806095.2067.11.1]

2021-09-27 05:31:19.551 -0700 Details folders: 9,179 [2.73806095.2067.11.2]

2021-09-27 05:31:19.552 -0700 Details rate: 2.9 GB/min [2.73806095.2067.11.3]

2021-09-27 05:31:33.085 -0700 #debug# caught exception [2.73806095.2067.12]

2021-09-27 05:31:33.085 -0700 Details problems encountered [2.73806095.2067.12.1]

2021-09-27 05:31:33.085 -0700 Subrosa .Exception: Info [2.73806095.2067.12.1.1]

2021-09-27 05:31:33.085 -0700 Subrosa .Complete: 1 [2.73806095.2067.12.1.2]

2021-09-27 05:31:33.085 -0700 Subrosa .Explain: iffyrecall [2.73806095.2067.12.1.3]

2021-09-27 05:31:33.085 -0700 Subrosa .LogClass: 3 [2.73806095.2067.12.1.4]

2021-09-27 05:31:33.085 -0700 Subrosa .Command: restore [2.73806095.2067.12.1.5]

2021-09-27 05:31:33.085 -0700 #debug# backtrace 380001e95f493 [2.73806095.2067.12.1.6]

2021-09-27 05:31:33.085 -0700 #debug#     0x7fff5215701d:     0x7fff52156f35 __exceptionPreprocess (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation@    0x7fff52065000) [2.73806095.2067.12.1.6.1]

2021-09-27 05:31:33.086 -0700 #debug#     0x7fff7c8cfa17:     0x7fff7c8cf9e7 objc_exception_throw (/usr/lib/libobjc.A.dylib@    0x7fff7c8bb000) [2.73806095.2067.12.1.6.2]

2021-09-27 05:31:33.086 -0700 #debug#     0x7fff52170b95:     0x7fff52170b8c -[NSException raise] (/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation@    0x7fff52065000) [2.73806095.2067.12.1.6.3]

2021-09-27 05:31:33.086 -0700 #debug#        0x10bd1557d:                0x0 unknown (/Users/Mike/Library/Application Support/QRecall/QRecallHelper.app/Contents/MacOS/QRecallHelper@       0x10bc98000) [2.73806095.2067.12.1.6.4]

2021-09-27 05:31:33.086 -0700 #debug#        0x10bcaa338:                0x0 unknown (/Users/Mike/Library/Application Support/QRecall/QRecallHelper.app/Contents/MacOS/QRecallHelper@       0x10bc98000) [2.73806095.2067.12.1.6.5]

2021-09-27 05:31:33.086 -0700 #debug#        0x10bca37da:                0x0 unknown (/Users/Mike/Library/Application Support/QRecall/QRecallHelper.app/Contents/MacOS/QRecallHelper@       0x10bc98000) [2.73806095.2067.12.1.6.6]

2021-09-27 05:31:33.086 -0700 #debug#        0x10bca9b58:                0x0 unknown (/Users/Mike/Library/Application Support/QRecall/QRecallHelper.app/Contents/MacOS/QRecallHelper@       0x10bc98000) [2.73806095.2067.12.1.6.7]

2021-09-27 05:31:33.088 -0700 #debug#     0x7fff542ff9a2:     0x7fff542ff4f8 __NSThread__start__ (/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation@    0x7fff542ed000) [2.73806095.2067.12.1.6.8]

2021-09-27 05:31:33.088 -0700 #debug#     0x7fff7e2932eb:     0x7fff7e29326d _pthread_body (/usr/lib/system/libsystem_pthread.dylib@    0x7fff7e290000) [2.73806095.2067.12.1.6.9]

2021-09-27 05:31:33.088 -0700 #debug#     0x7fff7e296249:     0x7fff7e296207 _pthread_start (/usr/lib/system/libsystem_pthread.dylib@    0x7fff7e290000) [2.73806095.2067.12.1.6.10]

2021-09-27 05:31:33.088 -0700 #debug#     0x7fff7e29240d:     0x7fff7e292400 thread_start (/usr/lib/system/libsystem_pthread.dylib@    0x7fff7e290000) [2.73806095.2067.12.1.6.11]

2021-09-27 05:31:33.089 -0700 Warning Restore encountered problems [2.73806095.2067.13]

2021-09-27 05:31:33.089 -0700         One or more problems were encountered while recalling the items. [2.73806095.2067.13.1]

But I'm thinking that if the recall was incomplete, then I'm missing data, and the next time QRecall captures that disk it will mark those files as deleted. In fact it already did do a capture of that disk. If I do a verify now, of course it will succeed. What I'd really like to do is verify it against the archive at the time of recall.

Mike

Mike M wrote:But I'm thinking that if the recall was incomplete, then I'm missing data

That is entirely possible.

Mike M wrote:What I'd really like to do is verify it against the archive at the time of recall.

A verify action only validates the internal consistency of the archive. It doesn't compare what's in the archive to what's on disk. There's currently no function that will tell you the difference between what's on a volume and what's in the archive, although that is a requested feature and is still on the wish list.

(Well, that's not exactly true; in the archive browser you can choose Edit > Select Existing Items, which will effectively compare the files in a browser view against what's on the volume, but it only works for the currently displayed folder.)

Mike M wrote:I found the section of the log at the point the restored finished. Maybe you can explain this.

That's simply the summary message that one or more issues were encountered. You'd have to search back through the log to find the specifics of the/each issue.

If you like, compress your log file(s), email them to support@qrecall.com, and we'll take a look at them for you. (We have a number of automated tools for combing through log files looking for problems.)

I followed your earlier advice and increased the detail level of the log. The log entry about the recall problem came back and it was about an inability to create a file and a directory. Both of them had "spotlight" in the name so I'm going to assume they were not important data. I've resolved this to my satisfaction.

I didn't know before that you can increase log detail. That's really good to know.

In the past, it was possible (although not recommended) to capture and restore your Spotlight database.

The latest versions of macOS, however, makes a lot of the spotlight data inaccessible, even to processes running as root. So if you did capture those files in the past, I'm not at all surprised you can't restore them now.