Got another "lost connection with process" while trying to repair an archive that says it needed repair. Report sent. Note this is 3rd "lost connection with process" I've gotten recently. I follow your instructions after each incident and things went well for a time.

Wait.... sorry I got this wrong, it wasn't during a repair, it was during a verify. Also this may have been related to the possibility that the capture items were not available at the time... they were on an external drive. Obviously QRecall should probably not lose the connection to the process, it should just hold on the verify or report the specific situation (i.e. "capture items not present"). So I'll go ahead and report it.... butg I'm not going to worry about it too much, as I think all of my archives currently do not need repair, and I'm going to try to rerun the verify.

Mike

Mike,

Thanks for the diagnostic report.

It's a bug.

The action terminated with an uncaught exception when trying to obtain exclusive access to the archive.

It's a random thing, unlikely to happen again, and doesn't involve any data loss. The code has been fixed and should appear in the next release.

Dont't know if it is relevant to this specific thread but I have a very similar issue with a RESTORE operation which systematically fails



I managed to recover the file from a secondary (cloud) backup but this is obviously not good.

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.

Just happened again and sent report referencing this thread

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.

Thanks - got your new build and it seems to work (at least did not crash outright).

FWIW I often have a VeraCrypt fully encrypted disk attached to my machine that obviously does not have any OS readable volume - it might be the one that is upsetting your code.

In any case will send another diagnostic when the restore finishes - hopefully without further issues.

UPDATE: The restore completed successfully - sent a new report.

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.

One of my backup volumes has been randomly disconnecting during a backup and again during attempts to repair it. The drive is three and a half years old and may have just reached the end of it's life, but I'm sending a report in case you can glean anything from it.

ralph

Problem seem to be back - tried a restore - failed.

Diagnostic sent.

Alexandre Takacs wrote:Problem seem to be back - tried a restore - failed.

Thanks for sending a diagnostic report.

The restore command is crashing inside the code that tries to match the volume identity of the captured items with the volumes you have on-line. There appears to be an empty/null/whatever volume name or something that's causing the crash.

I'm digging into it now, but in the mean time try to perform a recall instead of a restore (a recall doesn't need to find the original location of the captured item).