It seems I am still having problems. The archive that I have used over the last months cannot be written to any longer. It is not a simple permission issue (the archive resides on a USB drive), because a test archive could be used on the same drive with no problems.
The error message says:
Cannot convert FSRev to Path
And consequently:
A network or disk error was encountered

I cannot verify the archive, either, because:
cannot open a negative hash map.

There may be a simple thing causing all this but I am at a loss.

Prion

Prion wrote:There may be a simple thing causing all this but I am at a loss.

I wouldn't bet on "simple."

There are a bewildering number of issues that can cause an archive to become unusable. The most common is a corrupted volume structure. This can cause the operating system to report I/O errors, mysterious "Cannot convert FSRef to Path", data validation errors, and items to disappear in the Finder—I'm not sure if this is what you meant when you wrote "Archive disappeared."

Once QRecall detects any inconsistency in an archive it will refuse to use it until it can be repaired. So the general formula to dealing with these kinds of problems is:

(1) Repair the volume that contains the QRecall archive using Disk Utility.
(2) Repair the QRecall archive using the File > Repair... command.

The original/root cause of the problem can probably be found in the QRecall log. It will most likely be the first error or warning that immediately precedes the spat of problems you're having now. If you get stuck trying to figure it out, send a diagnostic report (Help > Send Report).

James
there are several incomplete layers of capture after a certain date. I was racking my brain what may have changed and I think I know now. At that day I re-enabled TimeMachine attached to which the USB drive with QRecall's archive is running.

Repairing the QRecall volume revealed a minor header problem which was corrected (according to Disk util).

What shall I do with the incomplete layers? Delete them? Assuming for now that the TimeMachine backup will contain all the changes since then I think I could live without them. Apparently it was not such a good idea to have TM and QRecall as a dual backup solution, at least not in this configuration.

1) Any ideas what may have caused the problem technically and how to avoid this in the future?
2) QRecall can backup over WiFi, can it not?
3) Delete the incomplete layers? Or do they still contain valuable information?

Thanks
Prion

Prion wrote:there are several incomplete layers of capture after a certain date.

An incomplete layer is just that: QRecall stopped capturing to the archive before it was finished. It just means that one or more items modified before the date of the layer were not captured. The missing items will be captured by the next (complete) capture.

1) Any ideas what may have caused the problem technically and how to avoid this in the future?

An incomplete layer is created when the QRecall capture is stopped before it can finish. There are a variety of events that can cause this to happen:
o You stopped the capture action directly (clicking on the stop button or sending the process a TERM signal) or indirectly (log out, shutdown, restart).
o The capture ran into a problem that prevented it from finishing, like running out of disk space.
o The capture's action has a condition that automatically stops the action at some time.

If this started to occur after you enabled Time Machine backups to the same device, you might have run out of disk space. This will prevent both QRecall and Time Machine from completing their backups. Of course, QRecall tells you about this, while Time Machine just deletes data or stops.

2) QRecall can backup over WiFi, can it not?

Yes.

3) Delete the incomplete layers? Or do they still contain valuable information?

The layers contain the items that QRecall could capture before it was stopped. Whether that's "valuable" is entirely up to you. The only danger of incomplete layers is when recalling; if you recall an incomplete layer you may be missing items that were modified before that layer date, but were not captured.

If incomplete layers bother you, simply merge the incomplete layers with the next complete layer in the archive. You'll discard any intermediate versions of items that were captured in those incomplete layers, but at least you won't have any incomplete layers in the archive.

Hi James,

I did not make myself clear then, what I meant was why enabling TimeMachine may have conflicted with QRecall, possibly the fact that both running simultaneously and/or that the USB drive is connected to the TimeCapsule may play a role here though I have not idea *how* exactly this may have been a problem. I did not mean to ask about incomplete layers, sorry about the confusion.
I definitely did not run out of space, on both hard drives there is more than 200 GB of free space available.

The problems started exactly the day I re-enabled TimeMachine, I checked the TimeMAchine sparsebundle.

Good point about merging the incomplete layers with the next complete one, this will make the archive look a bit more tidy, I do not think there are valuable intermediates that need to be preserved. Out of curiosity, if QRecall gets interrupted in the midst of dealing with one particular file it will resume its activity by starting over again at this particular file, right? It will not somehow miss the bits it has started to do but forgotten because it was interrupted?


Some things have changed now.

The header problems for the QR volume on the USB drive could be solved
The QR Archive on the USB drive could be repaired using the auto-repair data associated with it (Don't you just *love* it when a problem arises, and only after you had that brief moment of realization that you'd be lost had you been left to your own devices you are introduced to that magical fall-back position and it all resolves into sweet nothingness)
There was an unused mountpoint in the volume folder which was a beast to get rid of. I suspect that it was ultimately the reason that QRecall could not access its archive because the drive now had a trailing "1" after its name. "Drive in use" error message all over the place. History anyway.

Whatever detail it was, everything is working again now. For now, the USB drive is connected to the MBP directly and TimeMachine is disabled. I'll await your comments on how to proceed regarding
1) coexistence of TimeMachine and QRecall
2) connecting the USB drive to the TimeCapsule.

Thanks for your support! The longer I work with QRecall the more I realize just how much consideration and attention to detail went into its creation. I am trying to avoid this situation but if I'd be forced to make a choice between TimeMachine and QRecall, I'd ditch the former. Still trying to avoid this situation though but that's how good I think QR is.

Prion

Prion wrote:what I meant was why enabling TimeMachine may have conflicted with QRecall, possibly the fact that both running simultaneously and/or that the USB drive is connected to the TimeCapsule may play a role here though I have not idea *how* exactly this may have been a problem.

To the best of my knowledge, Time Machine and QRecall should coexist peacefully, with some minor caveats. I have a number of customers who run both QRecall and Time Machine and haven't reported problems.

Having QRecall and Time Machine both backing up to the same drive simultaneously can result in poor performance—for both. QRecall and Time Machine both use a fair amount of memory and are very I/O intensive. The result is more competition than cooperation, resulting in wasted effort and poor performance.

A small number of customers have reported that having multiple processes hammering on the same USB drive can sometime "overwhelm" the drive or the USB interface, resulting in I/O errors. These seem to be transient, but that would definitely cause QRecall to halt in its tracks.

My suggestion is to make a note of when Time Machine normally does its thing and schedule QRecall to do its heavy lifting (like daily capture and merge actions) at some other time. You might want to suspend QRecall's scheduled actions until Time Machine is finished with its initial backup.

I definitely did not run out of space, on both hard drives there is more than 200 GB of free space available.

Then it sounds like an I/O or some other event caused QRecall to stop. The log should say. If you send a diagnostic report (Help > Send Report), I'll take a look at it.

The QR Archive on the USB drive could be repaired using the auto-repair

Auto-repair occurs when something disastrous happens (crash, I/O error) to the capture process. If the archive was auto-repaired, then I suspect an I/O error.

Whatever detail it was, everything is working again now. For now, the USB drive is connected to the MBP directly and TimeMachine is disabled. I'll await your comments on how to proceed regarding
1) coexistence of TimeMachine and QRecall

Should be OK. It might be too much for your USB drive, but it shouldn't be. Also, that could change if you move the drive to your Time Capsule.

2) connecting the USB drive to the TimeCapsule.

Should also be fine. After you move your drive to the Time Capsule, you'll need to open all of your QRecall actions and change the archive in each to refer to the new archive, which will now appear on a networked volume. You will also need to be logged in for your QRecall actions to run. Mac OS X requires an account and password to mount a networked volume, and that requires you to be logged in.

Thanks for your support! The longer I work with QRecall the more I realize just how much consideration and attention to detail went into its creation.

Prion wrote:Out of curiosity, if QRecall gets interrupted in the midst of dealing with one particular file it will resume its activity by starting over again at this particular file, right? It will not somehow miss the bits it has started to do but forgotten because it was interrupted?

Oops, almost forgot to answer that bit.

Every time QRecall begins a capture, it simply compares what's on the drive to what's in the archive. If it has completely captured an item and that item hasn't changed, then it skips it and moves on. Otherwise, it captures the item again.

It's simplistic logic, but it makes it almost impossible to "fool" QRecall into overlooking an item.