[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #47 from Michail Pappas --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #46 from Michail Pappas --- Created attachment 190528 --> https://bugs.documentfoundation.org/attachment.cgi?id=190528=edit MSI transform file to NOT associate MS office files with LibO during GPO-based installations Transform sets Property\REGISTER_ALL_MSO_TYPES to 0. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #45 from Michail Pappas --- Created attachment 190527 --> https://bugs.documentfoundation.org/attachment.cgi?id=190527=edit MSI transform file to associate MS office files with LibO during GPO-based installations Transform sets Property\REGISTER_ALL_MSO_TYPES to 1. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #44 from Michail Pappas ---
(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:
1a0153bd1da0bc7 file:C:/Users/myuser/Τα έγγραφά μου/8003
0 0 1 2 390
1a1b8c111da0bc7 file:C:/Users/myuser/Templates/ 80030
0 1 2 385
1a1b8c111da0bc7 file:C:/Users/myuser/Start Menu/8003
0 0 1 2 383
1a1b8c111da0bc7 file:C:/Users/myuser/SendTo/80030
0 1 2 382
1a1b8c111da0bc7 file:C:/Users/myuser/PrintHood/ 80030
0 1 2 379
1a2c3b941da0bc7 file:C:/Users/myuser/NetHood/ 80030
0 1 2 373
1bec59a51da0bc7 file:C:/Users/myuser/Local Settings/8003
0 0 1 2 370
1de0e9a01da0bc7 file:C:/Users/myuser/Documents/Τα βίντεό μου/
80030 0 1 2 16191
1de34bd61da0bc7 file:C:/Users/myuser/Documents/Οι εικόνες μου/
80030 0 1 2 16172
1dea727b1da0bc7 file:C:/Users/myuser/Documents/Η μουσική μου/
80030 0 1 2 16156
1e2acf641da0bc7 file:C:/Users/myuser/Documents/My Videos/
80030 0 1 2 16093
1e2acf641da0bc7 file:C:/Users/myuser/Documents/My Pictures/
80030 0 1 2 16092
1e2acf641da0bc7 file:C:/Users/myuser/Documents/My Music/
80030 0 1 2 16091
1eee44831da0bc7 file:C:/Users/myuser/Documents/Τα βίντεό μου/
80030 0 1 2 21744
1eee44831da0bc7 file:C:/Users/myuser/Documents/Οι εικόνες μου/
80030 0 1 2 21743
1eee44831da0bc7 file:C:/Users/myuser/Documents/Η μουσική μου/
80030 0 1 2 21742
1eee44831da0bc7 file:C:/Users/myuser/Documents/My Videos/
80030 0 1 2 21741
1eee44831da0bc7 file:C:/Users/myuser/Documents/My Pictures/
80030 0 1 2 21740
1eee44831da0bc7 file:C:/Users/myuser/Documents/My Music/
80030 0 1 2 21739
26e908971da0bc7 file:C:/Users/myuser/Cookies/ 80030
0 1 2 361
26e908971da0bc7 file:C:/Users/myuser/Application Data/ 8003
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_SZLibreOffice.WriterDocument.1
Content TypeREG_SZapplication/vnd.oasis.opendocument.text
PerceivedTypeREG_SZdocument
HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1
HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1\ShellNew
FileNameREG_SZC:\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.1REG_SZ
Word.OpenDocumentText.12REG_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---C000-0046}
(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
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #43 from Mike Kaganski --- (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... -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #42 from Mike Kaganski --- (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 > 800c0 800700571 2 228 > [...] > > 800c and 80070057 look like error codes, but i don't know the meaning. 800c 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 (0057), 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? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #41 from Michail Pappas --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #40 from Michail Pappas --- 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 > 800c0 > 80070057 1 2 228 > 88028b62 1d5de88 file:C:/Users/me/Documents/blindtext - Kopie.odt > 800c0 > 80070057 1 2 225 > 88028b62 1d5de88 file:C:/Users/me/Documents/blindtext - Kopie (2).odt > 800c 0 800700571 2 224 > [...] > > 800c and 80070057 look like error codes, but i don't know the meaning. I have the exact response, 800c. Unfortunately googling around did not produce any useful results in the context of Windows search. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #39 from Michail Pappas --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #38 from QA Administrators --- Dear Michail Pappas, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 Gilward Kukel changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #37 from Gilward Kukel --- When I save an ODT file with WordPad, its contents are found. When I save one with LibreOffice Writer, its contents are not found. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #36 from Lobotomik --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #35 from Lobotomik --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #34 from MariaC --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #33 from Lobotomik --- (In reply to Lobotomik from comment #32) > 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: > > \soffice --headless --convert-to docx [--outdir > ] \*.odt > > But G! The *.odt option does not work and it only works file-by-file. >From a cmd line, from the folder where .odt files are: for %i in (*.odt) do "\soffice" --headless --convert-to docx --outdir "%i" -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #32 from Lobotomik --- 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: \soffice --headless --convert-to docx [--outdir ] \*.odt But G! The *.odt option does not work and it only works file-by-file. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||0771 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #31 from Lobotomik --- 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 > 800c 0 80070057 1 2 228 > 88028b62 1d5de88 file:C:/Users/me/Documents/blindtext - Kopie.odt > 800c 0 80070057 1 2 225 > 88028b62 1d5de88 file:C:/Users/me/Documents/blindtext - Kopie (2).odt > 800c 0 80070057 1 2 224 > [...] > > 800c 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:4126.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:5227.120 SystemIndex.6.gthr 04/06/2020 10:23 2 SystemIndex.7.Crwl 04/06/2020 20:1113.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 800c 2 80070057 2 4294967295 172353 ef574cd8 1d638ad file:C:/Users/Nacho/Google Drive/TIC/CEF/Filename2.odt 800c 2 80070057 2 4294967295 32674 ef5bb568 1d638ad file:C:/Users/Nacho/Google Drive/TIC/CEF/Filename3.odt 800c 2 80070057 2 4294967295 32673 ef643b0a 1d638ad file:C:/Users/Nacho/Google Drive/TIC/CEF/Filename4.odt 800c 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). 800c and 80070057 look like flags. The 800c 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #30 from Lobotomik --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #29 from AngelaAngie --- Nice post for any query and help related to this or any other, you should go to https://rs4264979.wixsite.com/mysite/post/hoe-hp-printerfout-79-op-te-lossen;>Klantenservice Belgie -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #28 from Michail Pappas --- 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 ... -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #27 from Michail Pappas ---
(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_SZLibreOffice.WriterDocument.1
Content TypeREG_SZapplication/vnd.oasis.opendocument.text
PerceivedTypeREG_SZdocument
HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1
HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1\ShellNew
FileNameREG_SZC:\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
AppXpv9rfrdnqrvf0122088ba0jqxe5sr88zREG_NONE
LibreOffice.WriterDocument.1REG_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---C000-0046}
(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_SZLibreOffice.CalcDocument.1
Content TypeREG_SZapplication/vnd.oasis.opendocument.spreadsheet
HKEY_CLASSES_ROOT\.ods\LibreOffice.CalcDocument.1
HKEY_CLASSES_ROOT\.ods\LibreOffice.CalcDocument.1\ShellNew
FileNameREG_SZC:\Program
Files\LibreOffice\share\template\shellnew\soffice.ods
HKEY_CLASSES_ROOT\.ods\OpenWithProgids
AppXb2ct2xh8sh7ng9mvrwkkwgbtkmxvv6arREG_NONE
LibreOffice.CalcDocument.1REG_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---C000-0046}
(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_SZLibreOffice.ImpressDocument.1
Content TypeREG_SZapplication/vnd.oasis.opendocument.presentation
HKEY_CLASSES_ROOT\.odp\LibreOffice.ImpressDocument.1
HKEY_CLASSES_ROOT\.odp\LibreOffice.ImpressDocument.1\ShellNew
FileNameREG_SZC:\Program
Files\LibreOffice\share\template\shellnew\soffice.odp
HKEY_CLASSES_ROOT\.odp\OpenWithProgids
AppXy5xs3camjkzrcz169vvpb6wa227tkvnnREG_NONE
LibreOffice.ImpressDocument.1REG_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---C000-0046}
(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}
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #26 from Oliver Brinzing --- 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: 87f369091d5de88 file:C:/Users/me/Documents/blindtext.odt 800c0 800700571 2 228 88028b621d5de88 file:C:/Users/me/Documents/blindtext - Kopie.odt 800c0 800700571 2 225 88028b621d5de88 file:C:/Users/me/Documents/blindtext - Kopie (2).odt 800c0 800700571 2 224 [...] 800c and 80070057 look like error codes, but i don't know the meaning. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #25 from Michail Pappas --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #24 from V Stuart Foote --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #23 from Michail Pappas ---
(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?
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #22 from Oliver Brinzing ---
Created attachment 157740
--> https://bugs.documentfoundation.org/attachment.cgi?id=157740=edit
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}"
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #21 from Oliver Brinzing --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #20 from Mike Kaganski --- 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... -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #19 from Michail Pappas --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #18 from Mike Kaganski --- Could there be difference in filter registration between 32- and 64-bit registry? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #17 from Oliver Brinzing --- (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 ? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #16 from Oliver Brinzing --- 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... -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #15 from Michail Pappas --- Created attachment 157614 --> https://bugs.documentfoundation.org/attachment.cgi?id=157614=edit 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
Michail Pappas changed:
What|Removed |Added
Ever confirmed|1 |0
Status|NEEDINFO|UNCONFIRMED
--- Comment #14 from Michail Pappas ---
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_SZOpenDocument Format Filter
HKEY_CLASSES_ROOT\CLSID\{7BC0E710-5703-45be-A29D-5D46D8B39262}\InprocServer32
(Default)REG_SZC:\Program
Files\LibreOffice\program\shlxthdl\ooofilt.dll
ThreadingModelREG_SZApartment
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)?
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #13 from Oliver Brinzing --- (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... -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #12 from V Stuart Foote --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #11 from Michail Pappas --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #10 from V Stuart Foote ---
(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
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #9 from Michail Pappas ---
(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)?
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #8 from Oliver Brinzing --- Created attachment 157581 --> https://bugs.documentfoundation.org/attachment.cgi?id=157581=edit test blindtext files -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #7 from Oliver Brinzing --- Created attachment 157580 --> https://bugs.documentfoundation.org/attachment.cgi?id=157580=edit 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #6 from Oliver Brinzing --- 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 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #5 from V Stuart Foote --- > (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 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320
--- Comment #4 from V Stuart Foote ---
(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"
--
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #3 from Michail Pappas --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 --- Comment #2 from Mike Kaganski --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=10 ||0879 Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 CC||mikekagan...@hotmail.com, ||tima...@gmail.com, ||vstuart.fo...@utsa.edu --- Comment #1 from V Stuart Foote --- 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)? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 130320] LibO 6: Windows 10 content indexing does not work
https://bugs.documentfoundation.org/show_bug.cgi?id=130320 Michail Pappas changed: What|Removed |Added Summary|LibO 6: Windows 10 indexing |LibO 6: Windows 10 content |does not work |indexing does not work -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
