Message |
|
James, Let me clarify a few points... First, the scheduled Action that is active when the "Lost Connection with Helper" occurs does indeed complete succesfully. However, the Actions window continues to show it as "Running"...and subsequent scheduled Actions that use the same archive just say "Waiting" in the Monitor window...and they never run.... My fix is to reboot the mac. I do believe that I tried to just kill the Scheduler process once...and it did seem to change the Actions window from the "Running" status...but I was not sure if that would cause other issues...so...I am simply rebooting. One other odd symptom is that you only see the "Lost Connection" verbiage in the log..whereas normally, I would see it in the Monitor window. I'm not sure if that helps you or not. I will run the sample.sh script the next time this occurs...and send a diagnostic report. In fact I will send a report now...since it happened this morning. Thanks.. GKG
|
|
|
James, I continue to see the "Lost Connection with Helper" on my mac mini running 10.6.8. I know that you are aware of this long standing issue...is there any fix in the works for this? The real problem here is that when this connection to the helper is lost...the scheduled Action that was executing remains in "Running" status in the Action window...and therefore, subsequent scheduled Actions never run because they are "waiting" for the archive. Thus, the machine has to be manually checked every day to see if the condition has occurred and further actions are waiting. Thanks, GKG
|
|
|
I am getting this same error on each recapture attempt. The volume being captured in this case is an SMB share on a Windows server machine. As such, I cannot verify it with Disk Utility from the mac. I did run a CHKDSK on the Windows Server and the volume/folder in question here does seem to be OK. I have sent another report. Thanks, GKG
|
|
|
James, The 70 beta release has corrected the issues concerning the extended logging and the erroneous recaptures. I did see one error message that I have never seen before: Action 2012-05-11 18:18:11 Caution Unable to read extended attribute data Action 2012-05-11 18:18:11 path: /Volumes/Backup Tree/Eone Share/TurboTax/Tax 2011/Personal/TurboTax 2011 Action 2012-05-11 18:18:11 xattr: com.apple.FinderInfo Action 2012-05-11 18:18:11 errno: 93 It would appear that the extended attributes of this 1 file are missing or corrupt? It is only a "Caution" so I would imagine it could be ignored? Thanks, GKG
|
|
|
Ok...thanks for the update...
|
|
|
James, This seems to be related to beta 69...I rolled-back my entire image to OSX 10.7.4 with QRecall beta 68 and it works fine...
|
|
|
James, I recently re-installed the current QRecall beta to a fresh copy of OSX 10.7.4. I then activated your extended logging by turning on QRLogCaptureDecisions and QRLogFSEvents. I am now seeing this in the log for every file in a recapture. Action 2012-05-11 05:47:10 Minutia Capture Decision; capture file LM Icon 1.jpg because unknown Action 2012-05-11 05:47:10 Minutia Capture Decision; capture file LM Icon 2.jpg because unknown Action 2012-05-11 05:47:10 Minutia Capture Decision; capture file LM Icon 3.jpg because unknown Action 2012-05-11 05:47:10 Minutia Capture Decision; capture file LM Icon 4.jpg because unknown Normally, after the "because" verbiage, a reason is given, like file size changed or date changed etc. Also, the re-Capture action nows appears to be recapturing every file every time it is run. I have not seen this before. I have also sent a report. Any ideas? Thanks, GKG
|
|
|
Thanks for the update...a CLI would be just as useful for my needs
|
|
|
Greetings James, I know I asked about this before...but I just wanted to follow-up. Is there anything in the works that would allow me to run a QRecall action from an Automator or Apple script? This functionality would be very powerful in capturing a recoverable image of a running virtual machine. A script can already be used to create a virtual machine snapshot...thus quiescing the state of the virtual disk...then QRecall could capture the virtual machine package...and finally, after the capture completes, the script would remove the VM snapshot created in the first step. This process works great...when down manually...it would just be great to be able to perform this in an automated fashion. Thanks, as always.
|
|
|
James, I just sent another report of this same problem. I installed the latest update to 10.8 that was released yesterday. (12A193i). Same issue...QRecall cannot open an Archive for a Capture action. Thanks, GKG
|
|
|
|
|
|
Greetings James, I have installed OSX 10.8 Preview version 3. I also installed QRecall on the new OSX beta image. I am having issues with the newest QRecalll beta version on this latest 10.8 release. Are you interested in receiving bug reports, etc. for 10.8 at this point...or is it too early in the cycle? Thanks, GKG
|
|
|
James, Yesterday, after sending the report on this issue...I decided to try an experiment. I simply unchecked the "Start and Run Actions while logged out"...and this issue has, at least so far, completely disappeared. I have restarted my mac several times and have not seen the issue since. I'm not sure if this helps...but I thought I would share this... One other question...does deleting the QRecall log from the mac's Console application...then restarting the system and emptying the trash have any deleterious effect on QRecall from that point forward? Sometimes, I like to clean out all the log entries and start fresh. Thanks, GKG
|
|
|
Report sent... If there is anything that I can do to assist in recreating this issue, logs, etc., please let me know... Thanks, GKG
|
|
|
James, Is there any update on this issue? I would say that 50% of the time...after I boot my mac...then launch QRecall...open the Action window...and manually kick-off a task... 1) The Action Window does not show the task's status...normally it would say "Running", "waiting", etc. 2) There is no Activity Monitor window opened as expected...(restarting the Activity Monitor window via the menu bar does not restore it either). Thus, the only way to know if the action that you just kicked-off is running is to open the log window. I also noticed that when Qrecall is in this state...if I open an archive with Finder...and then click Verify...it does not open the Activity Monitor window...it performs the verify with the progress bar within the archive window...normally, when I do this...I can close the archive window and the verify continues as seen through the activity monitor. I am running 10.7.3 with the latest beta. Thanks, GKG
|
|
|