During my testing (b19) I noticed a bunch of hundred items that were captured again and again with each run. These items are mainly folders (most of them empty in the layer) and a few pdf files. I have not touched them or altered them (or their content) between the runs (I have not touched some of them for years).

Thanks to QRecalls space saving algorithms they only add up to a few KB run. But they waste resources, make seraching the browser confusing and I wonder: what could be the reason for this behaviour?

Johannes

Johannes wrote:I wonder: what could be the reason for this behaviour?

There's a setting just for this.

In the Advanced QRecall Settings post, you'll find the QRLogCaptureDecisions settings. Set it to true before your next capture and QRecall will log the reason (well, at least the first reason) it decided to capture each item. Do remember to turn it off once you've conducted your investigation.

Nice feature - but not crashing the QRecallBundledHelper

When I enable it the capture-action will not complete.
The Log says (after producing the first decision output)
Lost connection with command
connection with command closed
Unable to connect with helper
cannot establish a connection with helper
Port: QRecallHelper.1b71efb

Further investigation brought up a crash log for QRecallBundledHelper.

The next run of the action will do some auto-repair (Undid incomplete changes made by previous action).

This is reproducible a result of switching the QRLogCaptureDecisions Setting. If I set it to false everything runs fine again.

So we have to fix this first, before i can go on with investigating.

Johannes

Johannes wrote:Nice feature - but not crashing the QRecallBundledHelper

Ouch, definitely not.

Thanks for the crash report. I'm testing a fix for this now. I'll post a link to download an alpha release later today.

QRecall 1.2.0(24) alpha is available to download, for anyone who wants to give it a spin.

This version addresses

Correct classification of Growl notifications

A crash when using the QRLogCaptureDecisions advanced setting

Memory efficiency while reading the names index.

A rare situation where the checksum of a new record was incorrectly calculated

Thanks for the update and the great support!

Crash is fixed, so we can proceed to the mysterious recapturing of unchanged items.

1) The pdf files
The log lists a reason for the pdf files: finderInfo different.
I checked the xattr (hope that is the right track) of one of those files.

The Original file reads:
com.apple.FinderInfo:
00000000 50 44 46 20 70 72 76 77 00 10 3C 50 63 6E 74 6C |PDF prvw..<Pcntl|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020

The recalled tmp file from the last backup run reads:
com.apple.FinderInfo:
00000000 50 44 46 20 70 72 76 77 00 00 3C 50 00 00 00 00 |PDF prvw..<P....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020

So there is a difference (bold face). But I did not do anything to the file. Could it be that QRecall ignores some of the bytes/attributes?

2) The folders
Apart from the pdf files (and their parent folders) there is a bunch of about hundred folders that are recaptured every time. I get no reason for capturing those in the log. I have only one clue what those folders might have in common: All of them were created long ago (eventually in OS 9 ages). Of course they got transferred several times to new Volumes and machines.

Does that make any sense?

Johannes

Johannes,

This might be garbage metadata from OS 9 that OS X isn't handling. One key difference in the "before and after" shot is the 00 10 vs 00 00. These 16 bits contain the Finder flags, and the difference is that the first one has the kNameLocked attribute set.

This is a deprecated file attribute that I don't think is even supported anymore. It might be that OS X is inconsistently reporting the status of this field, so QRecall thinks it keeps changing. QRecall doesn't interpret any of the legacy FileInfo or FolderInfo structures; it simply compares them byte-for-byte and recaptures the item's metadata by making an exact copy.

This issue has come up with other metadata. The so-called "extended" finder information is now so full of deprecated/unsupported fields that QRecall now captures and compares only the two remaining supported values (extended finder flags and the put-away folder ID) from that structure.

You might try this as an experiment. Pick one of these files and restore it using QRecall. Capture the enclosing folder, and then capture it again. If QRecall doesn't capture it the second time, then I think this might solve the problem. If it works, it's because QRecall would recreate a copy of the file through the OS X file API. If there are any deprecated file attributes that OS X is now ignoring, it would discard them when creating the new file and should return 00's when asked for them back.

As for the other folders, it could be a similar issue if these are really old (OS 9 era) folders. Folders don't have much useful information in their finder info structures, so discarding it isn't a big loss. Just create a new folder, move the the contents of the old folder into the new one, and trash the old folder.

It seems that a deep scan cleared 70% of the affected files/folders: they are no longer recaptured.

The remaining pdf files could be redeemed by restoring them (as suggested by you)

For the remaining folder I followed your advice too (create it new and move the files over): no more recapture

Now I have only two reluctant folders left. Unfortunately the System will not allow me to fiddle with them as they are "important for the System": Sites and Music. Is there a terminal command to clear their extended finder info?

Johannes

Johannes wrote:Is there a terminal command to clear their extended finder info?

I though there was, but I can't find one. I know you can delete ACL with chmod, but I don't know of a utility that will let you arbitrarily delete extended attributes. I guess that's why I probably end up writing a program to do it.