https://forums.qrecall.com/posts/list/3.page JForum - http://www.jforum.net

I ran into an issue this morning performing a capture to a network share. The capture bombs right at the end...with a "Cannot convert FSRef to path" error.

I I repair the archive...and move it to a local SATA drive...the same capture works fine...it just fails when the archive is located on the SMB share. I have sent a report...

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/361/1639.page https://forums.qrecall.com/posts/preList/361/1639.page GMT
Thanks for the feedback and the diagnostic report. From the log you uploaded, I can sort of tell what happened, but I can't tell you what went wrong.

When the archive was closing, QRecall wanted to write a new file to the package. Attempting to create and open this file failed. I don't know exactly how it failed, because the next thing that happened is QRecall tried to log the error and path to the file that couldn't be created, but that failed because archive package folder suddenly couldn't be found ... which is ridiculous, since you were just capturing to it. Anyway, this second failure threw another error, which is what eventually got logged.

So, I can't offer a good reason why QRecall was unable to create that file, and without the exact error code it's just guesswork. If I had to guess, I'd say the volume was completely full (unlikely) or something random happened with communications that caused the volume to be temporarily unavailable (more likely).

What I did do was modify the logging code so if something like this happens in the future, the code that logs what went wrong won't, itself, become the source of the problem.]]> https://forums.qrecall.com/posts/preList/361/1640.page https://forums.qrecall.com/posts/preList/361/1640.page GMT

Thanks for the update. I attempted the same capture again today...and this time it worked....very odd.

The volume does have plenty of space available...so...I think your "more likely" scenario is probably correct.

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/361/1641.page https://forums.qrecall.com/posts/preList/361/1641.page GMT https://forums.qrecall.com/posts/preList/361/1642.page https://forums.qrecall.com/posts/preList/361/1642.page GMT
I should have another beta ready soon, and it would include the fix I just mentioned which would correctly log the root cause of the problem. That would be much more informative.]]> https://forums.qrecall.com/posts/preList/361/1643.page https://forums.qrecall.com/posts/preList/361/1643.page GMT
I will move the repaired archive back to a local drive for now...

As after the new beta arrives...I will move it back and try it again with the new enhanced logging...

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/361/1644.page https://forums.qrecall.com/posts/preList/361/1644.page GMT
Any timeframe on the new beta release that you mentioned in this thread?

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/361/1648.page https://forums.qrecall.com/posts/preList/361/1648.page GMT Ah, the plans of mice and men.

I originally planned to have the next beta release out over a week ago, but I ran into complications reworking a critical section of the code that captures a file's metadata, that I would [i]really[/i] like to release. To slow things down even more, I was attending Audodesk University this week and just today got back to development.

So to answer your question: This weekend, I swear!]]> https://forums.qrecall.com/posts/preList/361/1650.page https://forums.qrecall.com/posts/preList/361/1650.page GMT
GKG]]> https://forums.qrecall.com/posts/preList/361/1652.page https://forums.qrecall.com/posts/preList/361/1652.page GMT Several, but most have been dealt with.

QRecall 1.2.0(54) beta is now available.

[quote=James Bucanek]This weekend, I swear![/quote]
I'm sure it's still the weekend ... somewhere. ;)]]> https://forums.qrecall.com/posts/preList/361/1653.page https://forums.qrecall.com/posts/preList/361/1653.page GMT https://forums.qrecall.com/posts/preList/361/1654.page https://forums.qrecall.com/posts/preList/361/1654.page GMT Installed new beta...rebooted system...launched QRecall....opened Action Window...launched a task...Action Window does not change to "Running"...Status monitor shows nothing...but a check of the QRecall log shows the task was submitted...repeated this 3 more times. Kick off a task...the Action window shows nothing is happening...the status monitor also shows nothing....but task is actually submitted.

Report sent...

GKG]]> https://forums.qrecall.com/posts/preList/361/1655.page https://forums.qrecall.com/posts/preList/361/1655.page GMT
I can see that it's not working, but I can't see why. (I'm not seeing the problem here, and my system is configured the same as yours.)

There's obviously something a little strange going on. During the QRecall upgrade, both the scheduler and monitor processes were replaced. But for some reason, the monitor stopped and didn't restart again until later. When it did finally start, the notifications it's supposed to receive when an action starts are never delivered.

Try restarting your entire system again (don't just log out and back in) and see if that makes any difference. Also look in the Console application and see if there are any messages from, or about, QRecall logged around 10:07.]]> https://forums.qrecall.com/posts/preList/361/1656.page https://forums.qrecall.com/posts/preList/361/1656.page GMT

I looked around a bit...and discovered that in the QRecall preferences...the Monitor tab's checkboxes had all been reset to "not" selected. I selected the ones I normally use...rebooted....and now QRecall seems to be working as expected.

Let me see if I can recreate the error.]]> https://forums.qrecall.com/posts/preList/361/1657.page https://forums.qrecall.com/posts/preList/361/1657.page GMT
Ok...I have rebooted my systems several times...and then launched QRecall...

The preferences are now Ok...i.e., they remain as they were set before...and I cannot recreate the oddity from earlier...it seems to be working fine now. Possibly, some issue during the installation of the new beta...I do not know..

If I see any other issues...I will let you know...

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/361/1658.page https://forums.qrecall.com/posts/preList/361/1658.page GMT https://forums.qrecall.com/posts/preList/361/1659.page https://forums.qrecall.com/posts/preList/361/1659.page GMT
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. :lol:

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/361/1660.page https://forums.qrecall.com/posts/preList/361/1660.page GMT
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.
]]> https://forums.qrecall.com/posts/preList/361/1661.page https://forums.qrecall.com/posts/preList/361/1661.page GMT https://forums.qrecall.com/posts/preList/361/1662.page https://forums.qrecall.com/posts/preList/361/1662.page GMT
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 [b]QRecall > Quit and Uninstall[/b] command. Wait a few seconds and launch QRecall again. After re-authorizing it, see if the problem comes back.]]> https://forums.qrecall.com/posts/preList/361/1663.page https://forums.qrecall.com/posts/preList/361/1663.page GMT
Thanks]]> https://forums.qrecall.com/posts/preList/361/1664.page https://forums.qrecall.com/posts/preList/361/1664.page GMT
I performed the Quit and Uninstall and then launched the application again, authenticated, etc.

So far...no issues... :-o

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

Thanks again...

GKG]]> https://forums.qrecall.com/posts/preList/361/1665.page https://forums.qrecall.com/posts/preList/361/1665.page GMT
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. :lol:

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 :evil: 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]]> https://forums.qrecall.com/posts/preList/361/1680.page https://forums.qrecall.com/posts/preList/361/1680.page GMT
Thanks so much for the thorough follow up.

I can confirm that the one thing QRecall really does [i]not[/i] 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. :-o

I'm glad you found the root of the problem.]]> https://forums.qrecall.com/posts/preList/361/1681.page https://forums.qrecall.com/posts/preList/361/1681.page GMT
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]]> https://forums.qrecall.com/posts/preList/361/1682.page https://forums.qrecall.com/posts/preList/361/1682.page GMT
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]]> https://forums.qrecall.com/posts/preList/361/1885.page https://forums.qrecall.com/posts/preList/361/1885.page GMT
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.]]> https://forums.qrecall.com/posts/preList/361/1886.page https://forums.qrecall.com/posts/preList/361/1886.page GMT
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]]> https://forums.qrecall.com/posts/preList/361/1887.page https://forums.qrecall.com/posts/preList/361/1887.page GMT 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.]]> https://forums.qrecall.com/posts/preList/361/1888.page https://forums.qrecall.com/posts/preList/361/1888.page GMT https://forums.qrecall.com/posts/preList/361/1889.page https://forums.qrecall.com/posts/preList/361/1889.page GMT
Thanks for the report. The reindex failed for a completely mundane reason: the archive data is damaged.

So the good news is that it didn't fail because of any weird "no such file" error. :wink:

The reindex detected an invalid record during its examination of the primary data file. Since this is on a networked volume, it's not unlikely that this was a transient data error. The simple test is to reindex again and see if the error occurs at the same position in the file.

It could also mean that something has overwritten or corrupted that archive data, in which case a repair is the only way to work around it.]]> https://forums.qrecall.com/posts/preList/361/1890.page https://forums.qrecall.com/posts/preList/361/1890.page GMT
You are correct...no surprise. :-o

When the Capture action to the archive stored on the SMB mount point fails, the archive is left damaged...and must be repaired first. This was automatically happening before...since I always ran a Verify action after the Capture failed...and the Verify fixed the archive's data component.

My error, in this case, was attempting to reindex of the archive before manually repairing it...(or running a Verify)...and it, therefore, failed, as you stated because the data was damaged by the Capture.

I repeated my steps...after first copying a clean archive to the SMB share...

1) Running a Capture...which failed.
2) Repairing the now damaged archive on the SMB share
3) Deleting all the .index files in the package
4) Reindexing the archive...which did work fine.
5) Trying another Capture...which failed.


So...at this point, I believe it is still only the Capture that has the issue to the SMB share.]]> https://forums.qrecall.com/posts/preList/361/1891.page https://forums.qrecall.com/posts/preList/361/1891.page GMT