Bug 100879 - Indexing for Windows Search not working on Win10 x64 with LibreOffice x64
Summary: Indexing for Windows Search not working on Win10 x64 with LibreOffice x64
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.1.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-12 17:22 UTC by John
Modified: 2020-01-31 14:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple test file (4.15 KB, application/vnd.oasis.opendocument.text)
2016-07-12 17:22 UTC, John
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2016-07-12 17:22:43 UTC
Created attachment 126184 [details]
Simple test file

Win10 x64 with LibreOffice x64 5.1.3.2

I have just noticed that there is no indexing in Win10 for the text content of .odt files, this being the case on of similar all three similarly configured PCs that I use. I am not entirely sure when this first arose.

The location of the files in question is definitely indexed and the control panel >  indexing options> advanced options> file types lists odt files, these to be indexed both their properties and file contents.

To confirm the side created a simple .odt file which just contained the words  Rhubarb and particles. A search from this from the top of the directory in which the file is located failed to find it. I then exported the file to a .pdf file and this was indexed for the text content immediately.

On a clean Win10 x64 virtual machine on which LibreOffice has never been installed, I note that the name of the indexing filter is slightly different, this being "opendocument format filter" whereas on the machine with LibreOffice installed, the filter is "open document format ODT filter". Putting the same file which was not successfully indexed on my main production machine onto this virtual machine allowed it to be indexed correctly by the virtual machine pretty much immediately suggesting to me that the problem is with the indexing filter.

I note the discussion in bug 56035 although this is now rather old and I wonder if this might be a regression.
Comment 1 V Stuart Foote 2016-07-12 21:49:14 UTC
Can not confirm.

On windows 8.1 Ent 64-bit en-US with
Version: 5.1.4.2 (x64)
Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a
CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; 
Locale: en-US (en_US)
and MS Office 2013 installed.

On Windows 10 Enterprise 64-bit en-US with
Version: 5.2.0.2 (x64)
Build ID: a7567a46e5d2953c320b13eb88a3981c4f9bd1e0
CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; 
Locale: en-US (en_US)

Following custom installation of LibreOffice on Windows 10, with Windows Explorer Extension verified active... Control Panel -> Indexing Options -> Advanced -> File Types -- the "OpenDocument Format Filter" (GUID {7BC0E710-5703-45BE-A29D-5D46D8B39262}) shows registered as filter description and in the Windows Registry. And for the ODF formats, shows as expected with "Index Properties and File Contents".

After installation of LibreOffice 5.2, it was necessary to rebuild index (Control Panel -> Indexing Options -> Advanced -> Index Settings:  "Rebuild").  But I do not consider this a bug.

Once indexes are rebuilt the Search on Windows 10 (and Windows 8.1) worked as expected locating strings from file contents.

This all works correctly.
Comment 2 V Stuart Foote 2016-07-12 22:04:50 UTC
And, the sample document when added to an indexed location (%USERPROFILE%\Documents) is picked up and indexed... either Rhubarb and particles return the document on search.

=-ref-=

http://opengrok.libreoffice.org/xref/core/scp2/source/winexplorerext/registryitem_winexplorerext.scp#236
Comment 3 V Stuart Foote 2016-07-13 12:56:56 UTC
On a second Windows 10 Pro 64-bit en-US system with install of
Version: 5.2.0.1 (x64)
Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

The index filter listed for ODF (Control Panel -> Indexing Options -> Advanced -> File Types) is "OpenDocument Format Filter" with "Index properties and contents" set, as defined in source (code pointer comment 2)

On save to Desktop (i.e. to an indexed location) the test document is immediately indexed, and a search for Rhubarb picks it up.

Works as intended.  Please check you Windows registry and your installation, and verify your indexing options. Reported filter of "Open document format ODT filter" is *NOT* from the LibreOffice installation.
Comment 4 John 2016-07-13 16:47:43 UTC
Thank you for that; most helpful. I was able to confirm that the registry entry for {7BC0E710-5703-45BE-A29D-5D46D8B39262} existed and appeared valid but tracing the indexing entry of "Open document format ODT filter" with a text search of the registry led to an alternative that appeared invalid - the entry contained very little other than its name.

Consequently I uninstalled LibreOffice completely and did a text search on the registry for LibreOffice and deleted everything found. Some of the entries found referred to previous x86 installations.

I then installed 5.2.0.2 x64.

The indexing option file type entry then became "OpenDocument Format Filter" and indexing worked immediately; there was no need to have it rebuilt.

The origin of the "Open document format ODT filter" entry is not clear to me. This is a relatively new build machine with a clean install of Win10, Office 2010 x64 and LibreOffice 5.x, originally x86 and then x64 although the move from x86 to x64 was done as an upgrade, not with complete removal of the x86 installation which clearly was not removed entirely with residual registry entries. Could the "Open document format ODT filter" have come from the prior x86 installations?
Comment 5 V Stuart Foote 2016-07-13 18:29:46 UTC
(In reply to John from comment #4)

> The origin of the "Open document format ODT filter" entry is not clear to
> me. This is a relatively new build machine with a clean install of Win10,
> Office 2010 x64 and LibreOffice 5.x, originally x86 and then x64 although
> the move from x86 to x64 was done as an upgrade, not with complete removal
> of the x86 installation which clearly was not removed entirely with residual
> registry entries. Could the "Open document format ODT filter" have come from
> the prior x86 installations?

Do not believe so. I believe that string is associated with MS Office 2010 and its odffilt.dll, providing search indexing of a few ODF document formats--here ODT. But also ODS and ODP.

LibreOffice and OpenOffice before use ooofilt.dll or, for running on 64-bit Windows, OOo implemented ooofilt_x64.dll

And Andras had reworked that part of the Windows builds for better behavior on 64-bit Windows for the LibreOffice 3.5.5/3.6.0 release (see bug 47805)--point is that string has never come from a LibreOffice install.

=-ref-=
https://bz.apache.org/ooo/show_bug.cgi?id=105892
Comment 6 V Stuart Foote 2016-07-13 18:59:19 UTC
(In reply to V Stuart Foote from comment #5)
> 
> Do not believe so. I believe that string is associated with MS Office 2010
> and its odffilt.dll, providing search indexing of a few ODF document
> formats--here ODT. But also ODS and ODP.
> 

And poking around, the stand-alone MS FilterPack could be the source of the indexing filter, and Registry strings, for anyone who didn't have an instance of MS Office installed.

=-ref-=
http://www.microsoft.com/en-US/download/details.aspx?id=17062
Comment 7 John 2016-07-13 19:10:05 UTC
Hmmm - must have come from Office but curious that it did not work and appeared corrupt and also odd that sequential installs of revisions of LibreOffice did not overwrite it until I completely removed and reinstalled LO as described.

At least is is now documented; if it happens to someone else, the solution is there, even if the cause is not clear.