Can not confirm. On Windows 10 1903 with 64-bit LibreOffice 6.4.0.3 installed.

In the Windows shell, document thumbnails are being extracted and built (so show in the Windows explorer view for Icons & Tiles) while the Search bar returns items to the Start Menu or populates the 'See more results'

A review of the system 'Indexing Options' dialog (now via the Action Center -> Search -> Searching Winodws -> 'Advanced Search Indexer Settings') 'Advanced Options' -> 'File Types' tab, shows the ODF formats are assigned the filter "OpenDocument Format Filter" and radio buttons are all set to "index properties and file contents"

Need info to check what filter is being assigned, if not the LibreOffice provided "OpenDocument Format Filter" look to the Windows registry for the string that shows.

I think this is a duplicate of bug 100879, some of the GUID and sources noted there.

@Mike, Andras -- could MS packaging custom action be provided to assure the correct filter gets assigned (update or clean install)?

I also can't confirm (testing with 6.4.0.3 on Win10 right now, searching term "lorem" typing in Start menu, and getting ODT documents in my Documents directory among results). However, please open a document you expect to be found using some search term; and check if it's written using the same language (and so its language isn't changing in the middle of the word). Windows indexer expects that parts of documents written in different languages be split to separate chunks; so a search term that is part-English part-German in the document will not be found.

(In reply to V Stuart Foote from comment #1)
> In the Windows shell, document thumbnails are being extracted and built (so
> show in the Windows explorer view for Icons & Tiles) while the Search bar
> returns items to the Start Menu or populates the 'See more results'

At work, on the systems where my LibO version is installed, windows explorer shows thumbnails but content is not indexed for searching


> A review of the system 'Indexing Options' dialog (now via the Action Center
> -> Search -> Searching Winodws -> 'Advanced Search Indexer Settings')
> 'Advanced Options' -> 'File Types' tab, shows the ODF formats are assigned
> the filter "OpenDocument Format Filter" and radio buttons are all set to
> "index properties and file contents"

Same settings.

> Need info to check what filter is being assigned, if not the LibreOffice
> provided "OpenDocument Format Filter" look to the Windows registry for the
> string that shows.

(In reply to Mike Kaganski from comment #2)
> I also can't confirm (testing with 6.4.0.3 on Win10 right now, searching
> term "lorem" typing in Start menu, and getting ODT documents in my Documents
> directory among results). However, please open a document you expect to be
> found using some search term; and check if it's written using the same
> language (and so its language isn't changing in the middle of the word).
> Windows indexer expects that parts of documents written in different
> languages be split to separate chunks; so a search term that is part-English
> part-German in the document will not be found.

Here's the strange thing. I tried to reproduce the issue at home, on my own Windows 10 system (x64, build 1909). The issue does *not* appear. Indexing happens instantly. Additionally, the filter name is the same, "OpenDocument Format Filter", however a newer LibO is installed at home, 6.2.7.1 (also x64).

I'm not sure of how one finds the GUID of the filter. Perhaps it's 7BC0E710-5703-45BE-A29D-5D46D8B39262 ?

I'll be back to work on Monday, at that time I'll report back on the filter GUID used on the problematic office installation.

With any luck, a newer LibO version will solve this problem for my users.

(In reply to Michail Pappas from comment #3)
 
> I'm not sure of how one finds the GUID of the filter. Perhaps it's
> 7BC0E710-5703-45BE-A29D-5D46D8B39262 ?
> 

Yes that GUID is the correct CLSID, inherited by the LibreOffice source from OOo (circa 2004), HKCR\CLSID\{7BC0E710-5703-45BE-A29D-5D46D8B39262} [1]. With a persistent handler of HKCR\CLSID\{7BC0E713-5703-45BE-A29D-5D46D8B39262}

In a typical install placed at: C:\Program Files\LibreOffice\program\shlxthdl\ooofilt.dll, though refactored a little since for WIN32_LEAN_AND_MEAN 32bit/64bit building.

On the other hand, believe the MS Office 2010 filter pack provided filter looks to be labeled "Open Document Format [ODT|ODS|ODP] Filter" provided by odffilt.dll installed on this path:
C:\Program Files\Common Files\Microsoft Shared\Filters\odffilt.dll

ODT assigned {9FBC2D8F-6F52-4CFA-A86F-096F3E9EB4B2}
with a Persistent Handler {34CEAC8D-CBC0-4f77-B7B1-8A60CB6DA0F7}

ODS assigned {E2F5480E-ED5A-4DDE-B8A8-F9F297479F62}
with a Persistent Handler {3DDEB7A4-8ABF-4D82-B9EE-E1F4552E95BE}

ODP assigned {4693FF15-B962-420A-9E5D-176F7D4B8321}
with a Persistent Handler {E2F83EED-62DE-4A9F-9CD0-A1D40DCD13B6}


So, should note that the "Windows Explorer Extension" is an optional component of a LibreOffice installation for Windows builds, and is enabled by default for interactive install. But possible a scripted or GPO deployment might have it disabled. And the MS Office filters might get activated.  

So, check the "work" computer(s).

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/ooofilt/ooofilt.cxx?r=3fbfb21e#1139

The filter retains the same GUID/CLSID but were originally named "OpenOffice.org Filter" and "OpenOffice.org Persistent Handler"

> (In reply to Michail Pappas from comment #3)
>  
> > I'm not sure of how one finds the GUID of the filter. 

Sorry, should have included that from a 'regedit' session, do <F3> search against either the Filter's string value (as found from the Advanced Search -> File Types dialog)  or against a referenced GUID/CLSID.  

Follow the linked names or GUIDs within the registry, to end up with path of the associated executable or library being called. Then check it for validity.

Incomplete removals on deinstallation, or while upgrading, can leave bogus paths behind in the Windows registry.

Checked with:

a) Notebook with ms office 2016 installed:

Search uses: "[x]odt Open Document Format ODT Filter"
C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\Filters\ODFFILT.DLL

-> Indexing does not work 

b) Notebook without ms office

Search uses: "[x]odt OpenDocument Format Filter"
C:\Program Files\LibreOffice\program\shlxthdl\ooofilt.dll

-> but did not work either

Created attachment 157580 [details]
windows search result

Attached picture shows the result:

Content indexing with Windows Search works for me with:
*.pdf,  (created from LO export)
*.docx, (created with Office 2016)
*.sxw   (created with AOO 4.16) 

files, but not with:
*.odt files

But it works, after renaming the *.odt file wrongly with *.sxw file extension.

Created attachment 157581 [details]
test blindtext files

(In reply to V Stuart Foote from comment #4)

> Yes that GUID is the correct CLSID, inherited by the LibreOffice source from
> OOo (circa 2004), HKCR\CLSID\{7BC0E710-5703-45BE-A29D-5D46D8B39262} [1].
> With a persistent handler of
> HKCR\CLSID\{7BC0E713-5703-45BE-A29D-5D46D8B39262}

Ok, that's the one!

> On the other hand, believe the MS Office 2010 filter pack provided filter
> looks to be labeled "Open Document Format [ODT|ODS|ODP] Filter" provided by
> odffilt.dll installed on this path:
> C:\Program Files\Common Files\Microsoft Shared\Filters\odffilt.dll

The files referenced by HKCR\CLSID\{7BC0E713-5703-45BE-A29D-5D46D8B39262} refer to C:\Program Files\LibreOffice\program\shlxthdl\ooofilt.dll on my home installation.


> So, should note that the "Windows Explorer Extension" is an optional
> component of a LibreOffice installation for Windows builds, and is enabled
> by default for interactive install. But possible a scripted or GPO
> deployment might have it disabled. And the MS Office filters might get
> activated.  

Hmmm, if that was the case (read: a gpo installation did not enable opendocument indexing by default) then I'd expect that in Windows search settings, odt files would not be associated with od? files. On my problematic setup they are though. I don't know if there is something else that should be enabled on a GPO-install as well.


> So, check the "work" computer(s).

Thanks, will do that first thing on Monday!

(In reply to Oliver Brinzing from comment #6)
> Checked with:
> 
> a) Notebook with ms office 2016 installed:
> 
> Search uses: "[x]odt Open Document Format ODT Filter"
> C:\Program Files (x86)\Microsoft
> Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\Filters\ODFFILT.DLL
> 
> -> Indexing does not work 
> 
> b) Notebook without ms office
> 
> Search uses: "[x]odt OpenDocument Format Filter"
> C:\Program Files\LibreOffice\program\shlxthdl\ooofilt.dll
> 
> -> but did not work either

Oliver, what's your exact Windows configuration (7/8/10 32-64bit and build number) and your LibO version (version plus whether it's 32/64bit)?

(In reply to Michail Pappas from comment #9)
> 
> The files referenced by HKCR\CLSID\{7BC0E713-5703-45BE-A29D-5D46D8B39262}
> refer to C:\Program Files\LibreOffice\program\shlxthdl\ooofilt.dll on my
> home installation.
> 

The IFilter interface [1], we do the legacy thing and link a persistent handler with the app module, while for newer implementations IIUC they merge. So, having the ooofilt.dll associated with the persistant handler looks correct.

You'd need to look for the MS Office filter GUID pairs, the CLSID for the odffilter.dll and the GUID for the file type (MS Office defines at least the three in comment 4).

What is also confusing is how to force a change in the filter module that the Windows shell uses for search, and more importantly how to 'repair' the LibreOffice filters when for some reason the index does not build with them.

=-ref-=
[1] https://docs.microsoft.com/en-us/windows/win32/search/-search-ifilter-registering-filters

(In reply to V Stuart Foote from comment #10)

> You'd need to look for the MS Office filter GUID pairs, the CLSID for the
> odffilter.dll and the GUID for the file type (MS Office defines at least the
> three in comment 4).
> 

I've read the comment and the reference, but not being a coder does not help. Best thing I could do is run any reg query commands given to me :)

BTW, I don't have office installed at either work or home.

(In reply to Michail Pappas from comment #11)
> BTW, I don't have office installed at either work or home.

Maybe. But if the still needed F3 search turns up the odffilter.dll string, or the GUIDs listed in Comment 4 show up registered, some application (other than a full MS Office install) laid them down. 

Rather than MS Office components, better to think of these as IFilter add-ons to the Windows shell to expose file metadata & properties, search indexing, and file thumbnails for use in the Windows explorer GUI, and supporting indexed search.

Have an issue should the MS provided odffilter IFilter interfere with our LibreOffice provided ooofilter IFilter module.

(In reply to Michail Pappas from comment #9)
> (In reply to V Stuart Foote from comment #4)

> Oliver, what's your exact Windows configuration (7/8/10 32-64bit and build
> number) and your LibO version (version plus whether it's 32/64bit)?

Win 10 x64 1909 [Version 10.0.18363.628] is installed on both notebooks
and have LO 6.1.7.8 (LTS):

Version: 6.1.7.8 (x64)
Build-ID: 46
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: 

But as mentioned above:
It does not work with ms office filter for *.ods files too, while renamed *.odt files are indexed in both cases...

I'm back at the problematic system. As I've already described, in the indexing settings (Action Center -> Search -> Searching Winodws -> 'Advanced Search Indexer Settings') 'Advanced Options' -> 'File Types' tab, shows the ODF formats are assigned the filter "OpenDocument Format Filter" and radio buttons are all set to "index properties and file contents".

c:\>reg query HKCR\CLSID\{7BC0E710-5703-45be-A29D-5D46D8B39262} /s

HKEY_CLASSES_ROOT\CLSID\{7BC0E710-5703-45be-A29D-5D46D8B39262}
    (Default)    REG_SZ    OpenDocument Format Filter

HKEY_CLASSES_ROOT\CLSID\{7BC0E710-5703-45be-A29D-5D46D8B39262}\InprocServer32
    (Default)    REG_SZ    C:\Program Files\LibreOffice\program\shlxthdl\ooofilt.dll
    ThreadingModel    REG_SZ    Apartment

C:>reg query HKLM\SOFTWARE\Classes\.odt\PersistentHandler /s

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.odt\PersistentHandler
    (Default)    REG_SZ    {7BC0E713-5703-45BE-A29D-5D46D8B39262}
	
(In reply to V Stuart Foote from comment #4)
> (...)
> On the other hand, believe the MS Office 2010 filter pack provided filter
> looks to be labeled "Open Document Format [ODT|ODS|ODP] Filter" provided by
> odffilt.dll installed on this path:
> C:\Program Files\Common Files\Microsoft Shared\Filters\odffilt.dll

Directory C:\Program Files\Common Files\Microsoft Shared\Filters does not exist on this system. C:\Program Files\Common Files\Microsoft Shared\ does exist.

> ODT assigned {9FBC2D8F-6F52-4CFA-A86F-096F3E9EB4B2}

Τhis string was not found in the registry. 

Some further test results and information:

* I repaired the existing (gpo-derived) LibO installation and rebooted. The issue persists.

* I used another fresh system, which was just joined to the domain. Made a fresh install using GPO again. Issue persisted. Uninstalled and installed LibO 6.3.4 x64 using the interactive installer, accepting the setup defaults. Again the issue persisted!!! 

At this point I can only think that something goes wrong in this setup: AD network (still using Windows Server 2003) / Windows 10 64bit clients / Libreoffice 64bit installation (regardless if it is gpo-guided or interactive).

Being clueless on how to proceed from here, I should first ask on how should I handle the bug at hand: that is, should I close this one and file a new bug (ie "No indexing on active directory Windows 10 64bit clients"), or can the title be changed to reflect the new issue context (whatever that might be)?

Created attachment 157614 [details]
Windows indexing properties

Not sure if this is related, but the indexing options show a GUID (probably of the user).

I've attached an image depicting this. The active directory domain user is named "m......." (see the bottom of the screenshot, the entire user folder is included).

On top of the picture there is a GUID. I suppose this is the GUID of the same user (not an expert). Should the GUID be depicted like that?

FYI, I'm *not* using roaming profiles.

With
a) Win10x64 LO 6.1x64 Notebook with ms office 2016 installed
b) Win10x64 LO 6.1x64 Notebook no ms office installed

i did some test using "ifilttst.exe" from:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/indexsrv/ifilttst

e.g.:
ifilttst /i C:\Users\me\Documents\blindtext.odt /l /d /v 3
ifilttst /i C:\Users\me\Documents\blindtext.sxw /l /d /v 3

but cannot find any errors - ifilttst.exe indexed *.sxw and *.odt files in both cases a) and b) the same way.

But with Windows Search only *.sxw files get indexed, not *.odt.

Now i exported reg key ".odt" from HKCR and renamed all "odt" occurences to "aaa". After import the new reg key all LO *.odt files (renamed to *.aaa) get indexed.

-> It seems, something blocks files with *.odt file extension.

Btw: I checked two other computers:
- Win7x64  Pro  LO 6.1   MS Office 2010
- Win10x64 Home LO 6.3.4 MS Office 2010

Both using "odffilt.dll" installed on this path:
C:\Program Files\Common Files\Microsoft Shared\Filters

and odt files get indexed in both cases...

(In reply to Michail Pappas from comment #14)
> Being clueless on how to proceed from here, I should first ask on how should
> I handle the bug at hand: that is, should I close this one and file a new
> bug (ie "No indexing on active directory Windows 10 64bit clients"), or can
> the title be changed to reflect the new issue context (whatever that might
> be)?

Can you please try, if it works for *.odt files renamed to *.sxw ?

Could there be difference in filter registration between 32- and 64-bit registry?

(In reply to Oliver Brinzing from comment #17)
> (In reply to Michail Pappas from comment #14)
> > Being clueless on how to proceed from here, I should first ask on how should
> > I handle the bug at hand: that is, should I close this one and file a new
> > bug (ie "No indexing on active directory Windows 10 64bit clients"), or can
> > the title be changed to reflect the new issue context (whatever that might
> > be)?
> 
> Can you please try, if it works for *.odt files renamed to *.sxw ?

I did try, but it still does not index content.

(In reply to Mike Kaganski from comment #18)
> Could there be difference in filter registration between 32- and 64-bit
> registry?

Just a "plain" user here. What makes the difference in my case is not the number of bits but whether we are the system is joined to an AD or not.

The thing is: if renaming an ODT to SXW makes the file to be indexed, that means that LibreOffice code works OK: no other filter (except OOo/AOO, which are hopefully outside of the scope here, to simplify things) will ever try to look inside that file type, and so LibreOffice shell extension will necessarily handle it.

Then, if at the same time, ODTs fail to be indexed, that means that those files *don't* reach LibreOffice code (which would otherwise handle them fine). And so it's the question of why. If the registration for the two file types looks identical, then ... ?

My idea (about differences between 64/32 registry) should be irrelevant here. The indexing should be not dual: one system service should handle all files on system, and that service should presumably use the system's architecture. Of course, when showing the search results, the displaying modules would be different for 64- and 32-bit applications, but that shouldn't matter, since both would look into the same already-gathered index DB.

I suppose that the only possible way is to compare everything regarding the two extensions - ODT and SXW. And that could also not help, if e.g. MS decided to handle ODT (an ISO format) specifically...

FYI: The notebooks that I used for the test are not in a domain.
After making changes to the registry/renaming file extensions, I always had the index recreated.

Created attachment 157740 [details]
Win10x64_with_LO61_and_MS_Office_2016_odt_ok.reg

I was able to make it work for my notbook Win10x64 with LO 6.1 and MS Office 2016 installed using attached *.reg file.

It did not work with MS Filter:

[HKEY_CLASSES_ROOT\.odt\PersistentHandler]
@="{34CEAC8D-CBC0-4f77-B7B1-8A60CB6DA0F7}"

but worked after changing GUID to "OpenDocument Format Filter":

[HKEY_CLASSES_ROOT\.odt\PersistentHandler]
@="{7BC0E713-5703-45BE-A29D-5D46D8B39262}"

(In reply to Michail Pappas from comment #19)
> (In reply to Oliver Brinzing from comment #17)
> > (In reply to Michail Pappas from comment #14)
> > > Being clueless on how to proceed from here, I should first ask on how should
> > > I handle the bug at hand: that is, should I close this one and file a new
> > > bug (ie "No indexing on active directory Windows 10 64bit clients"), or can
> > > the title be changed to reflect the new issue context (whatever that might
> > > be)?
> > 
> > Can you please try, if it works for *.odt files renamed to *.sxw ?
> 
> I did try, but it still does not index content.

Oliver's issue is different from the OP: the OP describes a case whereas indexing does not work, even if the file is renamed to SXW (SXx in general).

Furthermore:

(In reply to Oliver Brinzing from comment #22)
> Created attachment 157740 [details]
> Win10x64_with_LO61_and_MS_Office_2016_odt_ok.reg
> 
> I was able to make it work for my notbook Win10x64 with LO 6.1 and MS Office
> 2016 installed using attached *.reg file.
> 
> It did not work with MS Filter:
> 
> [HKEY_CLASSES_ROOT\.odt\PersistentHandler]
> @="{34CEAC8D-CBC0-4f77-B7B1-8A60CB6DA0F7}"
> 
> but worked after changing GUID to "OpenDocument Format Filter":
> 
> [HKEY_CLASSES_ROOT\.odt\PersistentHandler]
> @="{7BC0E713-5703-45BE-A29D-5D46D8B39262}"

^^^ this is not the case with the OP whereas the persistent handlers for ODT files are correct from the start.

Summarizing, I believe that it we are talking different issues, that require a different testing approach and solution. As such, perhaps it would be better for Oliver to file a different issue?

(In reply to Michail Pappas from comment #23)

@Michall, rather seems they are intertwined. NEEDINFO to you to at your 'work' systems, open a regedit session and check the recorded persistent handler,if any, for the HKCR\.odp, HKCR\.ods, HKCR\.odt stanzas.

That set of extensions, matches what the MS Office Filter pack would lay down. Oliver's tweaking the .odt to use the LibreOffice persistent handler CLSID thereby restoring indexing suggests an adjustment/addition is needed to the LibreOffice installer actions.

(In reply to V Stuart Foote from comment #24)
> (In reply to Michail Pappas from comment #23)
> 
> @Michall, rather seems they are intertwined. NEEDINFO to you to at your
> 'work' systems, open a regedit session and check the recorded persistent
> handler,if any, for the HKCR\.odp, HKCR\.ods, HKCR\.odt stanzas.

Will gladly do on Monday.

> That set of extensions, matches what the MS Office Filter pack would lay
> down. Oliver's tweaking the .odt to use the LibreOffice persistent handler
> CLSID thereby restoring indexing suggests an adjustment/addition is needed
> to the LibreOffice installer actions.

My apologies, thanks for correcting me.

I forgot to mention: Windows Search writes a log file:

%ProgramData%\Microsoft\Search\Data\Applications\Windows\GatherLogs\SystemIndex
SystemIndex.1.gthr

My log file contained an entry for every *.odt file skipped during index process:

87f36909	1d5de88	file:C:/Users/me/Documents/blindtext.odt	8000000c	0	80070057		1	2	228
88028b62	1d5de88	file:C:/Users/me/Documents/blindtext - Kopie.odt	8000000c	0	80070057		1	2	225
88028b62	1d5de88	file:C:/Users/me/Documents/blindtext - Kopie (2).odt	8000000c	0	80070057		1	2	224
[...]

8000000c and 80070057 look like error codes, but i don't know the meaning.

(In reply to V Stuart Foote from comment #24)
> (In reply to Michail Pappas from comment #23)
> 
> @Michall, rather seems they are intertwined. NEEDINFO to you to at your
> 'work' systems, open a regedit session and check the recorded persistent
> handler,if any, for the HKCR\.odp, HKCR\.ods, HKCR\.odt stanzas.

C:\>reg query HKCR\.odt /s

HKEY_CLASSES_ROOT\.odt
    (Default)    REG_SZ    LibreOffice.WriterDocument.1
    Content Type    REG_SZ    application/vnd.oasis.opendocument.text
    PerceivedType    REG_SZ    document

HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1

HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1\ShellNew
    FileName    REG_SZ    C:\Program Files\LibreOffice\share\template\shellnew\soffice.odt

HKEY_CLASSES_ROOT\.odt\OpenWithList

HKEY_CLASSES_ROOT\.odt\OpenWithList\WordPad.exe
    (Default)    REG_SZ

HKEY_CLASSES_ROOT\.odt\OpenWithProgids
    AppXpv9rfrdnqrvf0122088ba0jqxe5sr88z    REG_NONE
    LibreOffice.WriterDocument.1    REG_SZ

HKEY_CLASSES_ROOT\.odt\PersistentHandler
    (Default)    REG_SZ    {7BC0E713-5703-45BE-A29D-5D46D8B39262}

HKEY_CLASSES_ROOT\.odt\shellex

HKEY_CLASSES_ROOT\.odt\shellex\{00021500-0000-0000-C000-000000000046}
    (Default)    REG_SZ    {087B3AE3-E237-4467-B8DB-5A38AB959AC9}

HKEY_CLASSES_ROOT\.odt\shellex\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}
    (Default)    REG_SZ    {3B092F0C-7696-40E3-A80F-68D74DA84210}

================================================

C:\>reg query HKCR\.ods /s

HKEY_CLASSES_ROOT\.ods
    (Default)    REG_SZ    LibreOffice.CalcDocument.1
    Content Type    REG_SZ    application/vnd.oasis.opendocument.spreadsheet

HKEY_CLASSES_ROOT\.ods\LibreOffice.CalcDocument.1

HKEY_CLASSES_ROOT\.ods\LibreOffice.CalcDocument.1\ShellNew
    FileName    REG_SZ    C:\Program Files\LibreOffice\share\template\shellnew\soffice.ods

HKEY_CLASSES_ROOT\.ods\OpenWithProgids
    AppXb2ct2xh8sh7ng9mvrwkkwgbtkmxvv6ar    REG_NONE
    LibreOffice.CalcDocument.1    REG_SZ

HKEY_CLASSES_ROOT\.ods\PersistentHandler
    (Default)    REG_SZ    {7BC0E713-5703-45BE-A29D-5D46D8B39262}

HKEY_CLASSES_ROOT\.ods\shellex

HKEY_CLASSES_ROOT\.ods\shellex\{00021500-0000-0000-C000-000000000046}
    (Default)    REG_SZ    {087B3AE3-E237-4467-B8DB-5A38AB959AC9}

HKEY_CLASSES_ROOT\.ods\shellex\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}
    (Default)    REG_SZ    {3B092F0C-7696-40E3-A80F-68D74DA84210}
============================================================
C:\>reg query HKCR\.odp /s

HKEY_CLASSES_ROOT\.odp
    (Default)    REG_SZ    LibreOffice.ImpressDocument.1
    Content Type    REG_SZ    application/vnd.oasis.opendocument.presentation

HKEY_CLASSES_ROOT\.odp\LibreOffice.ImpressDocument.1

HKEY_CLASSES_ROOT\.odp\LibreOffice.ImpressDocument.1\ShellNew
    FileName    REG_SZ    C:\Program Files\LibreOffice\share\template\shellnew\soffice.odp

HKEY_CLASSES_ROOT\.odp\OpenWithProgids
    AppXy5xs3camjkzrcz169vvpb6wa227tkvnn    REG_NONE
    LibreOffice.ImpressDocument.1    REG_SZ

HKEY_CLASSES_ROOT\.odp\PersistentHandler
    (Default)    REG_SZ    {7BC0E713-5703-45BE-A29D-5D46D8B39262}

HKEY_CLASSES_ROOT\.odp\shellex

HKEY_CLASSES_ROOT\.odp\shellex\{00021500-0000-0000-C000-000000000046}
    (Default)    REG_SZ    {087B3AE3-E237-4467-B8DB-5A38AB959AC9}

HKEY_CLASSES_ROOT\.odp\shellex\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}
    (Default)    REG_SZ    {3B092F0C-7696-40E3-A80F-68D74DA84210}

Not a bump, just a request whether I can provide something else to help this investigation, after the registry keys from the problematic installation were provided on https://bugs.documentfoundation.org/show_bug.cgi?id=130320#c27 ...

I've been suffering the same for a long time.

* Windows 10 Home 1909 64-bit, running at home.
* LibreOffice 6.4.4.2 as of today, but it happened just the same with previous versions.
* In Advanced indexing options, LibreOffice file extensions are associated with "OpenDocument Format Filter" for properties and contents.
* I have a folder with some 50 .odt files I have created myself.

These are the symptoms:

* Contents of .pdf, .docx and many other file types are found in Windows 10 searches.
* Contents of .odt files are not found in Windows 10 searches.
* Rebuilding the index does not cure the issue.
* If I save the file as .docx or .doc, matches in the new .docx or .doc file appear (but of course not in the .odt file).
* If I rename the .odt file as .sxw, matches appear instantly in searches (with no change in format involved!).
* Large icons in Windows File Explorer show a faithful image of the file contents.

Search *has* worked in the past, but only occasionally, and not for long. I cannot tell when did it work, for how long, and which were the special conditions, if any, but I've seen it work a couple times without doing anything special (that I remember).

I'm reasonably tech-savvy, but no Windows expert. With kind guidance I can look through regedit, browse logs if you tell me where they are, or run stuff on a console and report results.

I'd be so happy if this was solved. It looks like a very small bug. I repeat I *have* seen it work in a system, and then again not work without any further changes I could tell.

I'm adding this information in the hope it helps fixing what seems to be a trivial issue (bearing in mind indexing works when you change the file suffix!).

I also hope that some additional information will prompt some activity, as this thread seems dead since february, the issue itself is much older than that, and it is still UNCONFIRMED.

(In reply to Oliver Brinzing from comment #26)
> I forgot to mention: Windows Search writes a log file:
> 
> %ProgramData%\Microsoft\Search\Data\Applications\Windows\GatherLogs\SystemIndex\SystemIndex.1.gthr
> 
> My log file contained an entry for every *.odt file skipped during index process:
> 
> 87f36909  1d5de88  file:C:/Users/me/Documents/blindtext.odt              8000000c  0  80070057  1  2  228
> 88028b62  1d5de88  file:C:/Users/me/Documents/blindtext - Kopie.odt      8000000c  0  80070057  1  2  225
> 88028b62  1d5de88  file:C:/Users/me/Documents/blindtext - Kopie (2).odt  8000000c  0  80070057  1  2  224
> [...]
> 
> 8000000c and 80070057 look like error codes, but i don't know the meaning.


I have looked at this folder in my computer and it contains four .gthr files.
It appears that every day, one is generated.

28/05/2020  15:38             1.042 SystemIndex.1.Crwl
29/05/2020  07:08                 2 SystemIndex.2.Crwl
31/05/2020  09:07                 2 SystemIndex.3.Crwl
01/06/2020  09:17                 2 SystemIndex.4.Crwl
01/06/2020  19:41            26.610 SystemIndex.4.gthr
02/06/2020  09:17                 2 SystemIndex.5.Crwl
02/06/2020  23:00           111.110 SystemIndex.5.gthr
03/06/2020  08:29                 2 SystemIndex.6.Crwl
03/06/2020  19:52            27.120 SystemIndex.6.gthr
04/06/2020  10:23                 2 SystemIndex.7.Crwl
04/06/2020  20:11            13.946 SystemIndex.7.gthr
05/06/2020  07:44                 2 SystemIndex.8.Crwl
05/06/2020  07:44                 0 SystemIndex.8.gthr

On Saturday 30th, the computer was off all day.

There are 95 lines in SystemIndex.4.gthr, and they are exactly the same as the first 95 lines in SystemIndex.5.gthr. 
SystemIndex.5.gthr is longer and goes on with different lines for other files.

The first 88 matching lines are one for each .odt file in my home folder (which is probably one for each .odt file in my computer).

The lines for .odt files always look like this:

ef532ff7  1d638ad  file:C:/Users/Nacho/Documents/G/FileName1.odt           8000000c  2  80070057  2  4294967295 172353
ef574cd8  1d638ad  file:C:/Users/Nacho/Google Drive/TIC/CEF/Filename2.odt  8000000c  2  80070057  2  4294967295 32674
ef5bb568  1d638ad  file:C:/Users/Nacho/Google Drive/TIC/CEF/Filename3.odt  8000000c  2  80070057  2  4294967295 32673
ef643b0a  1d638ad  file:C:/Users/Nacho/Google Drive/TIC/CEF/Filename4.odt  8000000c  2  80070057  2  4294967295 32672

Very similar, but not the same as Oliver Brinzing's. 

The last column seems like a counter of some sort. It went down monotonically for each different filel, as far as I saw.

The column before last is the same for each line in all the gthr files (-1 in my case).

8000000c and 80070057 look like flags. 
The 8000000c value appeared in each line in every file.
The 80070057 value appeared in each line related to an .odt file. Other types of files had different values here. 

Every line in every .gthr file relates to a file somewhere within my home folder, *seemingly* to files created in the past few days. 
There are over 350K files in over 30K folders, of many different types (.pdf, .doc, .exe, .js, .zip, .pdf, .mp4, .mkv ...), and they have not been mentioned (yet?) in a .gthr file.

I *think* I rebuilt the index on May 28th, which is the day of my first comment in this thread and the date for the first .crwl file.

Hello Stuart,

This issue is languishing unassigned and nobody has looked at it since you looked at it last time. Is there something we could do to help get it solved? If a simple rename to .sxw is enough for the indexer to work, there cannot be great obstacles.

For the time being, I'm trying to batch convert all my files to .docx and use .docx as default to get rid of the issue. For those interested in doing that, from the command line:

<path to soffice>\soffice --headless --convert-to docx [--outdir <outputdir>] <pathtodocs>\*.odt 

But GRRRR! The *.odt option does not work and it only works file-by-file.

I have this problem but only for old Open Office Documents. Newly created odt files are index right away. Old are not even when windows indexing is finnished.

I just tried saving a .docx file as .odt hoping the issue had been cured, but the bug persists.

I think the key to get this fixed is that simply renaming the .odt file to .sxw causes the file to be immediately indexed, which means there is an indexer running that understands the .odt structure but for some reason refuses to analyze .odt files. But the bug status remains "UNCONFIRMED", after more than a year, which means there's nobody looking at it.

If you really need your files to be indexed, the solution is change them all to Microsoft .docx format.

FWIW, I have completely uninstalled LibreOffice and done a clean install of 7.1.1, making sure to start in safe mode and wipe out all existing user configuration, but that has not changed anything.

When I save an ODT file with WordPad, its contents are found. When I save one with LibreOffice Writer, its contents are not found.

Issue persists on: Version: 7.5.7.1 (X86_64) / LibreOffice Community
Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126
CPU threads: 6; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: el-GR (el_GR); UI: el-GR
Calc: threaded

That's some laggy response, but had the time so...

(In reply to Oliver Brinzing from comment #26)
> I forgot to mention: Windows Search writes a log file:
> 
> %ProgramData%\Microsoft\Search\Data\Applications\Windows\GatherLogs\SystemInd
> ex
> SystemIndex.1.gthr
> 
> My log file contained an entry for every *.odt file skipped during index
> process:
> 
> 87f36909	1d5de88	file:C:/Users/me/Documents/blindtext.odt	8000000c	0
> 80070057		1	2	228
> 88028b62	1d5de88	file:C:/Users/me/Documents/blindtext - Kopie.odt	8000000c	0
> 80070057		1	2	225
> 88028b62	1d5de88	file:C:/Users/me/Documents/blindtext - Kopie (2).odt
> 8000000c	0	80070057		1	2	224
> [...]
> 
> 8000000c and 80070057 look like error codes, but i don't know the meaning.

I have the exact response, 8000000c. Unfortunately googling around did not produce any useful results in the context of Windows search.

(In reply to Oliver Brinzing from comment #16)
> i did some test using "ifilttst.exe" from:
> https://docs.microsoft.com/en-us/previous-versions/windows/desktop/indexsrv/
> ifilttst
> 
> e.g.:
> ifilttst /i C:\Users\me\Documents\blindtext.odt /l /d /v 3
> ifilttst /i C:\Users\me\Documents\blindtext.sxw /l /d /v 3

Where can ifilttst.exe be downloaded from?

(In reply to Oliver Brinzing from comment #26)
> My log file contained an entry for every *.odt file skipped during index
> process:
> 
> 87f36909	1d5de88	file:C:/Users/me/Documents/blindtext.odt	8000000c	0	80070057		1	2	228
> [...]
> 
> 8000000c and 80070057 look like error codes, but i don't know the meaning.

8000000c means "A concurrent or interleaved operation changed the state of the object, invalidating this operation."

80070057 is from HRESULT_FROM_WIN32; and the Win32 error part (00000057), which might be incomplete due to how the mapping to HRESULT works, *might* mean "The parameter is incorrect.".

What about an antivirus, that might possibly block/scan some files based on extension?

(In reply to Lobotomik from comment #32)
> This issue is languishing unassigned and nobody has looked at it since you
> looked at it last time. Is there something we could do to help get it
> solved? If a simple rename to .sxw is enough for the indexer to work, there
> cannot be great obstacles.

Lol. The greatest obstacle is its reproducibility. There is no description yet, allowing a developer to see it on their system. Some detail about the environment is still unclear - and until it is clarified, nothing could be done.

(In reply to MariaC from comment #34)
> I have this problem but only for old Open Office Documents. Newly created
> odt files are index right away. Old are not even when windows indexing is
> finnished.

(In reply to Gilward Kukel from comment #37)
> When I save an ODT file with WordPad, its contents are found. When I save
> one with LibreOffice Writer, its contents are not found.

The two comments - comment #34 and comment #37 - say the ~opposite things (indeed, "old" in c#34 doesn't necessarily mean "old ODF version", but still). There could be more then one problem mixed here, with similar manifestations...

(In reply to Mike Kaganski from comment #42)
> What about an antivirus, that might possibly block/scan some files based on
> extension?

Made some tests on two AD-joined systems, both running 7.5.7. System 1 is my own, system 2 is a freshly joined to the domain. On System 1, office 365 is installed, whereas on 2 only LibO is installed.

I've forced an index re-creation on both systems. Re-creation on system 2 has finished, whereas on 1 it is still ongoing due to the number of files locally.

In bother cases, examining the gthr file under %programdata%\Microsoft\Search\Data\Applications\Windows\GatherLogs\SystemIndex there are no references to specific files, but it is there on entire directories. A snippet from system 1 which is similar to 2:

1a0153bd	1da0bc7	file:C:/Users/myuser/Τα έγγραφά μου/	80000003	0	0		1	2	390
1a1b8c11	1da0bc7	file:C:/Users/myuser/Templates/	80000003	0	0		1	2	385
1a1b8c11	1da0bc7	file:C:/Users/myuser/Start Menu/	80000003	0	0		1	2	383
1a1b8c11	1da0bc7	file:C:/Users/myuser/SendTo/	80000003	0	0		1	2	382
1a1b8c11	1da0bc7	file:C:/Users/myuser/PrintHood/	80000003	0	0		1	2	379
1a2c3b94	1da0bc7	file:C:/Users/myuser/NetHood/	80000003	0	0		1	2	373
1bec59a5	1da0bc7	file:C:/Users/myuser/Local Settings/	80000003	0	0		1	2	370
1de0e9a0	1da0bc7	file:C:/Users/myuser/Documents/Τα βίντεό μου/	80000003	0	0		1	2	16191
1de34bd6	1da0bc7	file:C:/Users/myuser/Documents/Οι εικόνες μου/	80000003	0	0		1	2	16172
1dea727b	1da0bc7	file:C:/Users/myuser/Documents/Η μουσική μου/	80000003	0	0		1	2	16156
1e2acf64	1da0bc7	file:C:/Users/myuser/Documents/My Videos/	80000003	0	0		1	2	16093
1e2acf64	1da0bc7	file:C:/Users/myuser/Documents/My Pictures/	80000003	0	0		1	2	16092
1e2acf64	1da0bc7	file:C:/Users/myuser/Documents/My Music/	80000003	0	0		1	2	16091
1eee4483	1da0bc7	file:C:/Users/myuser/Documents/Τα βίντεό μου/	80000003	0	0		1	2	21744
1eee4483	1da0bc7	file:C:/Users/myuser/Documents/Οι εικόνες μου/	80000003	0	0		1	2	21743
1eee4483	1da0bc7	file:C:/Users/myuser/Documents/Η μουσική μου/	80000003	0	0		1	2	21742
1eee4483	1da0bc7	file:C:/Users/myuser/Documents/My Videos/	80000003	0	0		1	2	21741
1eee4483	1da0bc7	file:C:/Users/myuser/Documents/My Pictures/	80000003	0	0		1	2	21740
1eee4483	1da0bc7	file:C:/Users/myuser/Documents/My Music/	80000003	0	0		1	2	21739
26e90897	1da0bc7	file:C:/Users/myuser/Cookies/	80000003	0	0		1	2	361
26e90897	1da0bc7	file:C:/Users/myuser/Application Data/	80000003	0	0		1	2	359

Funny thing is I searching for part of the filename works. It's searching for the content that doesn't.

Posting the HKCR/.odt entry from system 2 (the one from system 1 is similar, but has additional entries for the MS Office handler):

>reg query HKCR\.odt /s

HKEY_CLASSES_ROOT\.odt
    (Default)    REG_SZ    LibreOffice.WriterDocument.1
    Content Type    REG_SZ    application/vnd.oasis.opendocument.text
    PerceivedType    REG_SZ    document

HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1

HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1\ShellNew
    FileName    REG_SZ    C:\Program Files\LibreOffice\share\template\shellnew\soffice.odt

HKEY_CLASSES_ROOT\.odt\OpenWithList

HKEY_CLASSES_ROOT\.odt\OpenWithList\WordPad.exe
    (Default)    REG_SZ

HKEY_CLASSES_ROOT\.odt\OpenWithProgids
    LibreOffice.WriterDocument.1    REG_SZ
    Word.OpenDocumentText.12    REG_NONE

HKEY_CLASSES_ROOT\.odt\PersistentHandler
    (Default)    REG_SZ    {7BC0E713-5703-45BE-A29D-5D46D8B39262}

HKEY_CLASSES_ROOT\.odt\shellex

HKEY_CLASSES_ROOT\.odt\shellex\{00021500-0000-0000-C000-000000000046}
    (Default)    REG_SZ    {087B3AE3-E237-4467-B8DB-5A38AB959AC9}

HKEY_CLASSES_ROOT\.odt\shellex\{8895b1c6-b41f-4c1c-a562-0d564250836f}
    (Default)    REG_SZ    {84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}

HKEY_CLASSES_ROOT\.odt\shellex\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}
    (Default)    REG_SZ    {3B092F0C-7696-40E3-A80F-68D74DA84210}


(In reply to Mike Kaganski from comment #43)
> Lol. The greatest obstacle is its reproducibility. There is no description
> yet, allowing a developer to see it on their system. Some detail about the
> environment is still unclear - and until it is clarified, nothing could be
> done.

Indeed, not being able to reproduce this is the major problem here. 

With regard to the environment, all my systems are running Windows 10 22H2, greek locale, fully patched, AD-joined to a single domain.

Furthermore, since some of our systems have MS Office installed and some don't, I employ two GPOs: one to deply the MSI by setting I'm using a couple of transforms to install LibO: one setting MSI property variables to associate MS office files with LibO (for those systems that do not have MS office installed) and one more to completely disassociate MS Office files with LibO (for those systems where MS Office is installed). Attaching the two .MST files here for completeness.

> The two comments - comment #34 and comment #37 - say the ~opposite things
> (indeed, "old" in c#34 doesn't necessarily mean "old ODF version", but
> still). There could be more then one problem mixed here, with similar
> manifestations...

Have the same hunch here... Definitely complicates more an already complicated case.

Created attachment 190527 [details]
MSI transform file to associate MS office files with LibO during GPO-based installations

Transform sets Property\REGISTER_ALL_MSO_TYPES to 1.

Created attachment 190528 [details]
MSI transform file to NOT associate MS office files with LibO during GPO-based installations

Transform sets Property\REGISTER_ALL_MSO_TYPES to 0.

Forgot to mention that AV is installed on both systems. System 2 has a stock Windows 10 defender, whereas System 1 has ESET endpoint protection 10.

(In reply to Mike Kaganski from comment #43)
> Lol. The greatest obstacle is its reproducibility. There is no description
> yet, allowing a developer to see it on their system.

Last year, a user came across this same issue on the LibreOffice subreddit:

- https://www.reddit.com/r/libreoffice/comments/13ocepu/windows_10_explorer_does_not_find_contents_of/jl4fi1e/

Their ODT indexing of LibreOffice files broke right after installing Microsoft OneNote. (Microsoft 365.)

- - -

They were able to correct it by doing:

1. Uninstalled Microsoft Office software.
2. Repaired the LibreOffice installation.
3. Recreated the search index.

Then it worked. (Search index settings say: odt: OpenDocument Format Filter)

- - -

Odd thing with that user was...

Indexing WORKED in:

- ODT created in WordPad
- ODT created in Google Docs

DID NOT in:

- ODT created in LibreOffice 7.5
- ODT created in OpenOffice 4.1

- - -

Side Note: And thanks for the great debugging info in these comments. I was able to use it to figure out what the heck was going on with those "Index Filters".

(In reply to Tex2002ans from comment #48)
> Side Note: And thanks for the great debugging info in these comments. I was
> able to use it to figure out what the heck was going on with those "Index
> Filters".

Really glad the Reddit post helped you. In my case it did not however. That not including the fact that my systems were "virgin"(no M$ office installed ever) ones.