#10 The program runs, but nothing is indexed into GDS

[Yan_sino]

This happened on the first field test of the standalone version. It ran as expected, it even seem to have downloaded data from svn server, but nothing is indexed. The entries never show up.
I suspect that the mixture of third party library is the cause. The executable requires even no dependency from RA library when using the Subversion libraries, which is ridiculous.
I got the compatibility test image to test this.

[Yan_sino]

Bug recreated using the full installer package, under the XP-IE6 comp test VPC image.
But the expectation seems to be wrong. The cause here is "Cannot find IFilter".
What's wrong with this installation?
I'll investigate this, also the verbose version will be taken to another test site to see if it is also impossible to get the IFilter there.

[Yan_sino]

Used WinDBG to step into LoadIFilter implemention. The findings are disturbing.

0x80004005 (E_FAIL), the general failure code, can be returned from LoadIFilter when there is an exception in the process of execution. Apparently the exception handler just returned 0x80004005. So it is only an indicator that something bad happened inside.

The Adobe PDF filter triggered an exception (but since it is already catched, I cannot see what it is.) and was left in a fragile state but got returned from LoadIFilter anyway, it then crushed the whole program upon its destruction, using an access violation.

What about Plain Text Filter? They also returns 0x8004005 on XP, but without crushing.

And the Office IFilter can take the situation, thus advancing to the "Access Denied" step, where it fails to CreateFile our temp file. That can somehow be cured by hooking APIs, but first this 0x80004005 thing must be fixed.

Wonder if the Plain Text Filter in WinXP follows the same pattern.

Getting debug symbols for WinXP, expecting more results.

[Yan_sino]

The definitive answer, from Process Monitor by Sysinternals:

22:28:41.1237533 idxTest.exe 4852 CreateFile E:\222\tmps99.txt SHARING VIOLATION Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Sequential Access, Attributes: N, ShareMode: Read, AllocationSize: n/a

This is the call that's generating FILTER_E_ACCESS error in Plain Text Filter.

The error is SHARING VIOLATION. According to a comment under the documentation of CreateFile (http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx), consequent calls of a file created using FILE_FLAG_DELETE_ON_CLOSE must specify SHARE_DELETE in sharing mode to succeed, or there will be a sharing violation. If the handle created with FILE_FLAG_DELETE_ON_CLOSE (including all its duplicates) is closed, the file will no longer be visible to future calls to CreateFile, but can still be accessed through other open handles of the same file.

Another thing that needs noticing is that the Plain Text Filter skipped CreateFile and directly called NtCreateFile. NtCreateFile is also internally called by CreateFileW, so hooking target should be aimed at NtCreateFile instead of CreateFileA/W.

Thanks to this precious piece of tool and the helpful community, I am able to continue now.

[Yan_sino]

Fixed.

After hooking 2 Native APIs (NtCreateFile and NtOpenFile) and practicing some other dirty tricks such as opening multiple handles to the same file, the first sign of a successful index showed on Windows XP. It is finally fixed.

The reason of this one is described in detail below, Finding the cause and pinning down problematic calls cost so much time, that I nearly not commited in a week.