Extended Logging No Longer Working...

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

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...

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.

Ok...thanks for the update...

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

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

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.

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

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.

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...

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.

ls -la@ <path to folder>

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

xattr -d com.apple.FinderInfo <path to file>

Now try the capture again and see what happens.