On Tue, Nov 13, 2007 at 12:56:19PM -0800, Linus Torvalds wrote:
quoted text
> 
> Ok, I've made a bugzilla entry for this for the Fedora people, but I 
> thought I'd mention something I noticed yesterday but only tracked down 
> today: it seems like the beagle file indexing code is able to screw up git 
> in subtle ways.
> 
> I do not know exactly what happens, but the symptoms are random (and 
> quite hard-to-trigger) dirty index contents where git believes that some 
> set of files are not clean in the index.
> 
> I *suspect* that beagle is playing games with the file access times, 
> causing the ctime on disk to not match the ce_ctime in the index file. But 
> that's just a guess.
> 
> I'm posting here in case somebody on the list knows what beagle does, or 
> somebody has been bitten by strange behaviour and realizes that he has 
> beagle running and prefers to fix the problem by just disabling beagle 
> (which will also be a great boon for performance - beagle seems to be very 
> good at flushing your file caches, but I guess that's not a bug, but a 
> "feature").

Last I ran across this, I believe I found it was adding extended
attributes to the file.  I think it's something like

	getfattr -d

to show all the extended attributes set on the file.  Does that show
anything?

Yeah, I just turned off beagle.  It looked to me like it was doing
something wrongheaded.

--b.

quoted text
> 
> The easiest way I have found so far to trigger this is to run
> 
> 	while ./t7003-filter-branch.sh -i; do echo ok; done
> 
> in the git t/ directory, while at the same time telling beagle to index 
> just that git/t/ directory. That seems to trigger a failure on subtest 17 
> fairly reliably (not the first time through the loop, but *eventually* - 
> it takes a few minutes). I think it's because "git filter-branch" requires 
> the index to be clean.
> 
> (But I've also seen it fail on subtest 4).
> 
> I opened bugzilla
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=380791
> 
> for this, since I consider it a beagle bug (indexing shouldn't change 
> directory state, and if beagle wants to avoid changing access times, it 
> should use O_NOATIME). But I don't actually know exactly what it is that 
> causes problems, so if somebody is interested and tries to figure this 
> out, that would probably be good.
> 
> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html