Good to know, and thanks for the follow up.

James,

The same odd behavior occurred again this morning. This time, I performed a video screen capture to illustrate what is happening.

As you can see from the video...a verify action is manually launched from the Actions window...the Action window does not change at all...however, you can also see from the log window that the verify is indeed kicked-off. The monitor window never opens either, at it should.

I can continue to launch other actions from the action window with the same effect...they execute...but no Action window status and no monitor window. Also, scheduled event triggers to not work when this occurs ether...actions must be kicked-off manually.

Now, if I reboot...it may work normally or it may exhibit these same symptoms. I have noticed that...if I wait maybe 30 minutes before launching QRecall...the symptom occurs with less frequency. Could this possibly be some type of race condition...where certain QRecall processes are getting started out of order?

Very odd...but I thought I would send the video so you don't think I am hallucinating.

Thanks,

GKG

I love my beta testers. I get the best bug reports, ever.

First, please send a diagnostic report. This will tell me a lot more about which processes were running and what action notifications were sent, what settings you're using, and so on.

Report sent...

Gary,

I've spent some time investigating, and I have yet to reproduce the problem here.

From your log files, it looks like your activity monitor process gets launched when you log it (which it should), but for some unexplainable reason none of the other processes can communicate with it. So when you start actions, they don't appear in the activity monitor window.

In the example you posted, you later launched the QRecall application. One of the first things the application does is try to establish a connection with the activity monitor process. When that failed, it restarted and reinstalled the monitor (on the assumption that it wasn't properly installed), at which point the monitor process started to receive notifications and generally behaved itself.

Let's try uninstalling and reinstalling QRecall to see if that makes any difference. Launch QRecall. Holding down the Option+Shift keys, choose the QRecall > Quit and Uninstall command. Wait a few seconds and launch QRecall again. After re-authorizing it, see if the problem comes back.

Ok...I will give it a try...

Thanks

Just an update...

I performed the Quit and Uninstall and then launched the application again, authenticated, etc.

So far...no issues...

I will keep testing and let you know if I see issues...

Thanks again...

GKG

James,

Just an update to close the original issue in this thread. To quickly restate the issue...while QRecall was writing to an archive located on an SMB share...the archive became corrupted and could not be repaired.

After performing many additional tests trying to recreate this...I have finally discovered that this is not a QRecall issue at all.

While QRecall was performing a Compact operation to this archive...I just happened to launch VMware Fusion and a Windows virtual machine that just happens to map a network drive to the same Windows server...not the same share..but the same physical server. This was causing the SMB share on the mac to spontaneously dismount Obviously, QRecall literally had the "rug ripped out from under it"...and the archive became corrupted.

I have opened a trouble ticket with VMware on this issue. I just thought other QRecall / Fusion users should be aware of this situation...sorry for the confusion...I just never made the association until yesterday..and now I can recreate it easiliy.

GKG

Gary,

Thanks so much for the thorough follow up.

I can confirm that the one thing QRecall really does not appreciate is having the volume that it's writing to spontaneously dismounted. Typically, this results in a "volume unmount" event being recorded in the log, which I can point to say "ah ha!" But I have to admit, having the mountpoint spontaneously replaced with a different volume is a new one on me.

I'm glad you found the root of the problem.

FYI...

Just one last note on this for any QRecall / Fusion users...to prevent this spontaneous SMB disconnect...simply change you VM's network adapter from "NAT" to "Bridged" mode...

This will prevent the mac's SMB share from being forcefully terminated. Again...this is a VMware Fusion issue...and has nothing to do with QRecall.

Thanks,

GKG

James,

This issue has started-up once again.

I copied an existing QRecall archive to an SMB share. I can Verify it just fine...but all Capture actions fail....and the Archive must be repaired. In this case...VMWare Fusion was not running and had not been run since the system was restarted.

My belief, when we discussed this issue last December, was that it was being cause by Fusion...but I don't see how that could be the issue now.

A report was sent.

Thanks,

GKG

Gary,

I reviewed the diagnostic report, and it's the same symptom as before. When QRecall is ready to close the archive at the end of the capture, it makes a copy of a small index file and opens the copy; except, the copy can't be found or isn't there (the error -43 you see in the log).

This could be an incompatibility with a rarely used file-duplication function which has caused QRecall to run into problems with other networked file system (including Apple's own AFS).

You could try deleting all of the .index files in the archive's package and then reindexing it. If the problem doesn't go away on its own—like it did last time—I'll take another look at a temporary solution.

I think this problem will go away once QRecall has finished transitioning away from the now-depreciated filesystem APIs in OS X, a task that's planned to be completed before the release of Mountain Lion.

James,

I tried removing all the .index files in the archive package and then re-indexing...but the re-index action fails also.

I guess I will just have to stick to storing archives on local drives until the API changes that you detailed are in place.

Thanks,

GKG

Gary K. Griffey wrote:but the re-index action fails also.

That's even more bizarre. I probably don't have a solution, but I'd still like a diagnostic report that includes the failed reindex.

Report Sent...