Re: stuck in file crawl task loop

[Joe Shaw <joeshaw novell com>]

Hi,

On Tue, 2007-01-23 at 12:30 -0500, Brian J. Murrell wrote:
> Ok.  I chowned the file to me and then touched it and just like magic:
> 
> brian pc:~$ attr -l /home/brian/sieve.script 
> Attribute "Beagle.Uid" has a 22 byte value for /home/brian/sieve.script
> Attribute "Beagle.MTime" has a 14 byte value for /home/brian/sieve.script
> Attribute "Beagle.AttrTime" has a 14 byte value for /home/brian/sieve.script
> Attribute "Beagle.Fingerprint" has a 25 byte value for /home/brian/sieve.script
> 
> But still:
> 
> $ echo 'select * from file_attributes where filename = "sieve.script";' | sqlite3 ~/.beagle/Indexes/FileSystemIndex/FileAttributesStore.db
> bo7X958nykipdPCXJdiA+w|/home/brian|sieve.script|20041206030115|20070116172617|Beagle.Filters.FilterText|0
> 
> So it seems like it did half of the job.  :-)

Hmm, this might be the cause of the loop.  The code always checks the
sqlite database first because it has to[1], which means that if the old
ones aren't being dropped from the DB we could be pulling old
information.

I will look into it.

[1] Imagine this scenario: a file is 0644 and is indexed; Beagle
attributes are written to xattrs; the file is chowned to a different
user and touched; Beagle reindexes the file, but cannot write updated
attributes to, or drop outdated attributes from, the xattr because it
doesn't have write permission; it writes instead to the DB.  The next
time Beagle goes to retrieve the attributes for the file, it has two
potential sources: DB and xattr, and one of them is outdated.  Therefore
we have to assume that the DB is always more up-to-date (because we can
always write to it) than xattrs.

Joe