QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Extended Logging No Longer Working...  XML
Forum Index » Beta Version
Author Message
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

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

Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

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 Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

Gary K. Griffey wrote:This seems to be related to beta 69

It is.

It's a side effect of the change to how finder metadata is captured. The change results in all items that have finder metadata stored in a com.apple.FinderInfo extended attribute to get recaptured in 1.2.0b69.

But this change broke the capture logging. The code that makes the capture decision and the code that tries to figure out what changed and log it are different blocks of code. The finder metadata change in b69 causes the files to be recaptured, but then the code that logs the difference can't find any difference (because, logically, there isn't any). So it logs "unknown".

Straightening this all out has revealed a far more subtle bug that would cause some items to be unnecessary recaptured. I'm testing the bug fixes now and a new version should be out in a few hours.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

Ok...thanks for the update...

James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

QRecall 1.2.0b70 is ready. Upgrade and see if these problems are resolved.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

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
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

Gary K. Griffey wrote:errno: 93

Error 93 is ENOATTR (Attribute not found). It means that QRecall got a list of all of the extended attributes for the file, but when it went to read them one of them wasn't there.

This is either a transient problem, which won't repeat and can be ignored, or something else is odd with the volume structure. See if it happens again. If it does, try repairing the volume and capture again. If that doesn't resolve it, send a diagnostic report.

It is only a "Caution" so I would imagine it could be ignored?

In general, failing to capture extended attributes isn't a serious problem because they typically don't contain information critical to the use of the file.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

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 Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

Gary K. Griffey wrote:The volume being captured in this case is an SMB share on a Windows server machine

Try copying the file to a local Mac volume, delete the file on the server, and then copy it back.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

James,

I copied the folder from the share to my desktop....deleted the folder from the share...then copied it back to the share...

I then ran a Capture...It is still giving me the error...but this time for a specific DMG file within that same folder...

Very odd...
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

Odd indeed.

Try this: Open a terminal window and use the ls -lA@ command to list the items in that directory and their extended attributes.


If the .dmg file lists a com.apple.FinderInfo attribute, try to delete it:



Now try the capture again and see what happens.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

James,

Ok...removing the extended attributes worked. No more issues during recapture.

Thanks,

GKG
 
Forum Index » Beta Version
Go to:   
Powered by JForum 2.1.8 © JForum Team