QRecall Community Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 

some unchanged items appear in each layer again and again RSS feed
Forum Index » Beta Version
Author Message
Johannes


Joined: Dec 10, 2010
Messages: 68
Offline
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
James Bucanek


Joined: Feb 14, 2007
Messages: 1567
Offline
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.

- QRecall Development -
[Email]
Johannes


Joined: Dec 10, 2010
Messages: 68
Offline
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
 Filename QRecallBundledHelper_2010-12-11-180019_MacBook-Pro.crash [Disk] Download
 Description Crash.log
 Filesize 28 Kbytes
 Downloaded:  580 time(s)

James Bucanek


Joined: Feb 14, 2007
Messages: 1567
Offline
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 Development -
[Email]
James Bucanek


Joined: Feb 14, 2007
Messages: 1567
Offline
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

  • - QRecall Development -
    [Email]
    Johannes


    Joined: Dec 10, 2010
    Messages: 68
    Offline
    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
    James Bucanek


    Joined: Feb 14, 2007
    Messages: 1567
    Offline
    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.

    - QRecall Development -
    [Email]
    Johannes


    Joined: Dec 10, 2010
    Messages: 68
    Offline
    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
    James Bucanek


    Joined: Feb 14, 2007
    Messages: 1567
    Offline
    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.

    - QRecall Development -
    [Email]
     
    Forum Index » Beta Version
    Go to:   
    Mobile view
    Powered by JForum 2.8.2 © 2022 JForum Team • Maintained by Andowson Chang and Ulf Dittmer