*** Bug 36948 has been marked as a duplicate of this bug. ***

Created attachment 46438 [details]
List of 64-bit Windows Registry errors with LibO installed

Hmm, it seems that these x64 DLLs are built if "BUILD_X64" is set in the build environment. I don't see anything that would set it though. In an old 3.3.1 build tree I find in solenv/config/sooo330.ini the line "BUILD_X64 TRUE". I assume this sooo330.ini file is/was part of the Hamburg OpenOffice.org Release Engineering or whatever build environment, and was not used in a normal OOo build, and certainly not in a LibreOffice build. (And it has by now been deleted from LibreOffice.)

So I wonder, if we would make that BUILD_X64 always be set when building LibreOffice for Windows, would the necessary x64 DLLs be produced then? Anyway, it is certainly too late to start experimenting with this now for 3.4. The DLLs in question were not included with LibreOffice 3.3.x either, were they?

Setting platform to x86, as far as I know this field is supposed to specify the *LibreOffice* code, not the OS. And LibreOffice itself is x86 even on x64 Windows. (Except then for these couple of DLLs mentioned in this bug report, when we eventually start producing and distributing them.)

Taking this.

The 64-bit shell extension now builds in master. No idea if it actually works... Will keep this bug open until I have verified that.

I modified Status to Assigned due to facts

How can a user fix this bug in his installation?
Is there any workaround?

(In reply to comment #0)
> Overview: Installing LibO causes text of all ODF files subsequently saved in
> LibO or OOo to be invisible in Windows Search in 64-bit versions of Windows.
> 
> Steps to Reproduce:
> 1) Originally install OpenOffice.org in a 64-bit version of Windows.
> 2) Create/edit a file in any ODF format in OOo.
> 3) Close the document, saving on exit.
> 4) Use Windows search to successfully find the ODF file from words in the text
> of the document.
> 5) Leave OOo installed.
> 
> Steps 1-5 are optional, but demonstrate that Windows search finds text in ODF
> documents with OOo installed.
> 
> 6) Install LibO in the 64-bit version of Windows.
> 7) Create/edit a file in any ODF format in either LibO or OOo.
> 8) Close the document, saving on exit.
> 9) Search for words in the text of the ODF document using Windows search. The
> ODF document will not appear in search results.
> 
> Actual Results:
> Installation of LibO prevents any ODF document saved on closing from being
> found in Windows search results, both in LibO and OOo.
> 
> [Note: Saving an ODF document in LibO or OOo during editing, rather than at
> closing does not trigger Windows to index the file, so the previous index state
> persists. This may be considered a separate bug.]
> 
> Expected Results:
> The ODF document appears in Windows search results for a search on any words
> exisiting in the text of the document.
> 
> Build and Platform:
> LibO 3.3.2 release, Windows 7 64-bit SP1, also reported on Windows Vista
> 64-bit.
> 
> Additional Information:
> The attached file contains a report on errors in the Windows Registry with OOo
> 3.3.0 plus  by LibO 3.3.2 installed in that sequence.
> 
> The following 3 files are missing from the LibO installation:
> C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\shlxthdl_x64.dll
> C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\ooofilt_x64.dll
> C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\propertyhdl_x64.dll
> 
> Files of these names are present in the equivalent OpenOffice.org 3 folder.
> However, note that the following 32-bit files differ from the files of the same
> names in the equivalent OpenOffice.org folder:
> C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\shlxthdl.dll
> C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\ooofilt.dll
> C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\propertyhdl.dll
> 
> It is the installation of LibO that breaks the "OpenDocument Format Filter"
> registry key  which previously pointed to the OOo version of ooofilt_x64.dll,
> and points it to the missing file in the LibO installation instead. This file
> is necessary for Windows to index ODF files. There are other errors as listed
> in the attached file.
> 
> This post on the LibO Forum provides another report:
> "IFilter Not Found Error with Windows Indexing on 64bit Windows Vista"
> http://en.libreofficeforum.org/node/338

(In reply to comment #8)
> (In reply to comment #0)
> > Overview: Installing LibO causes text of all ODF files subsequently saved in
> > LibO or OOo to be invisible in Windows Search in 64-bit versions of Windows.
> > 
> > Steps to Reproduce:
> > 1) Originally install OpenOffice.org in a 64-bit version of Windows.
> > 2) Create/edit a file in any ODF format in OOo.
> > 3) Close the document, saving on exit.
> > 4) Use Windows search to successfully find the ODF file from words in the text
> > of the document.
> > 5) Leave OOo installed.
> > 
> > Steps 1-5 are optional, but demonstrate that Windows search finds text in ODF
> > documents with OOo installed.
> > 
> > 6) Install LibO in the 64-bit version of Windows.
> > 7) Create/edit a file in any ODF format in either LibO or OOo.
> > 8) Close the document, saving on exit.
> > 9) Search for words in the text of the ODF document using Windows search. The
> > ODF document will not appear in search results.
> > 
> > Actual Results:
> > Installation of LibO prevents any ODF document saved on closing from being
> > found in Windows search results, both in LibO and OOo.
> > 
> > [Note: Saving an ODF document in LibO or OOo during editing, rather than at
> > closing does not trigger Windows to index the file, so the previous index state
> > persists. This may be considered a separate bug.]
> > 
> > Expected Results:
> > The ODF document appears in Windows search results for a search on any words
> > exisiting in the text of the document.
> > 
> > Build and Platform:
> > LibO 3.3.2 release, Windows 7 64-bit SP1, also reported on Windows Vista
> > 64-bit.
> > 
> > Additional Information:
> > The attached file contains a report on errors in the Windows Registry with OOo
> > 3.3.0 plus  by LibO 3.3.2 installed in that sequence.
> > 
> > The following 3 files are missing from the LibO installation:
> > C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\shlxthdl_x64.dll
> > C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\ooofilt_x64.dll
> > C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\propertyhdl_x64.dll
> > 
> > Files of these names are present in the equivalent OpenOffice.org 3 folder.
> > However, note that the following 32-bit files differ from the files of the same
> > names in the equivalent OpenOffice.org folder:
> > C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\shlxthdl.dll
> > C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\ooofilt.dll
> > C:\Program Files (x86)\LibreOffice 3\Basis\program\shlxthdl\propertyhdl.dll
> > 
> > It is the installation of LibO that breaks the "OpenDocument Format Filter"
> > registry key  which previously pointed to the OOo version of ooofilt_x64.dll,
> > and points it to the missing file in the LibO installation instead. This file
> > is necessary for Windows to index ODF files. There are other errors as listed
> > in the attached file.
> > 
> > This post on the LibO Forum provides another report:
> > "IFilter Not Found Error with Windows Indexing on 64bit Windows Vista"
> > http://en.libreofficeforum.org/node/338

I reported this same issue at http://en.libreofficeforum.org/node/338,

Do you need any testing with this? (I really want to switch to LibreOffice but this is a major issue preventing the switch.)

Tor, This bug persists in LibO 3.4.1 OOO340m1 (Build:103). Is the 64-bit shell extension supposed to be in this build?

I said master, didn't I?

Sorry, I'm only a user, I didn't realise what "master" meant. I wasn't sure if you were waiting for verification from a Windows user. Apologies.

Tor, Is there any way we can progress this? Perhaps it would not take long to test it so that it could be in a release build soon?

I think adding this functionality back could be considered a feature, and thus not suitable for the 3.4 branch.

With true respect, I disagree. This is not a feature but a bug. The bug obviates searching on a Windows x64 system because the bug alters the search indexing capability on install. In other words, this is not a nice-to-have feature but a bug that undermines system searches. Due to the prevalence of x64 systems and the seriousness of the bug, this is an obstacle to adopting LibreOffice. (The bug appeared, according to the timeline, after the OpenOffice 3.3 and LibreOffice 3.3x fork.)

I intend this post respectfully, but this is a bug. As an end user, the bug has kept me from switching to LibreOffice due to the seriousness.

It's commit f33232a3ff67d7a4def830fa6fda78ef5f255ae7 in master that then should be perhaps cherry-picked to the 3.4 branch.

I do believe this should be cherry-picked to the 3.4 branch, and it is unlikely to cause new problems. 

Note that if testing that x64 Windows indexing function is restored, an ODF file must be saved when closing the file (for some reason, saving during editing will not trigger Windows indexing, at least in Windows 7).

BTW, does this search of ODF files work even on 32-bit Windowses for LO 3.3.x? What about 3.4.x? I am not 100% sure how to test myself, as I have never had the need for this functionality...

OK, I cherry-picked that commit (adapted to apply) to my 3-4 branch, built it, verified that the ooofilt_x64.dll, propertyhdl_x64.dll and shlxthdl_x64.dll (in addition to the 32-bit ones) got installed in <LO>\Basis\program\shlxthdl on my 64-bit WS2008R2, but even after a fresh login, none of these were loaded into explorer.exe.

Actually, I don't know how to search inside documents in Windows 7 (or Ws2008R2)... Do I need to turn on some indexing service first? Anyway, just for providing a preview of ODF documents (as it does for MS Office and .txt files) it should be using some of these dlls, right? Also, I don't know how to turn on document preview in Explorer in XP (the only 32-bit Windows I have), or is that functionality not available there?

Re-assigning to Jesús who showed interest in digging into this on IRC...

Created attachment 52573 [details]
Old master commit backported to 3-4

To search for files containing one or more words (in Windows 7 anyway), bring up the Windows Start Menu by clicking the Windows icon in the taskbar, then type the words in the search box on the Start Menu. Alternatively, type in the search box at the top right of any Windows Explorer window. Note that only some locations are indexed, mainly the user's folders excluding AppData - type Indexing Options in the Start Menu to see what is indexed. It is easy to test by searching for a word saved in a .txt file or most other file types that contain some text.

Need to find someone with access to a 32-bit Windows to see if it works for ODF files in 32-bit Windows. Always necessary to be aware that for LibO or OOo to trigger indexing, the file has to be saved during closing the file - this is not the case for files saved by other applications (eg Notepad, Notepad++, Wordpad), so LibO seems not to trigger the normal indexing process when doing File>Save (this also means Windows Documents library does not get updated unless the file is saved during closing). With LibO installed, when LibO or OOo save a file during closing the file, this triggers indexing for the file, but the result is that previous index information for the file is removed and no new indexing is created.

Not sure what Tor meant in Comment 19 where he says "verified that the ooofilt_x64.dll, propertyhdl_x64.dll and shlxthdl_x64.dll ... got installed in <LO>\Basis\program\shlxthdl on my 64-bit WS2008R2, but even after a fresh login, none of these were loaded into explorer.exe." What does it mean for these files to be installed in the correct folder but not loaded into explorer.exe (please excuse my ignorance)?

Tor mentions document preview in Explorer (Comment 19). I don't think the preview pane has ever worked for ODF files in Windows Explorer even though the OOo Quickstarter had its own document previews. It would be nice to have document previews!

I can confirm it works well in Windows 2008 Server R2 32 bits and it doesn't work in Windows 2008 Server R2 64 bits.

I change the platform of the bug report.

I have created a build with Tor's patch for testing purposes only:

http://dl.dropbox.com/u/193133/LibO_3.4.3rc1_Win_x86_install_en-US.exe

I can't test until tomorrow, so if anyone else want to help, you are welcome :)

p.s. the patch needed some massage in my Windows XP as cygwin didn't like the spaces in the PATH.

Tor's patch really improves the situation, because the other shell extensions are working now but search still doesn't work for me. Can anyone else test the build and report?

Test Date: 2011-10-24

First, thank you for taking on this bug fix.

Test Platform:
--Windows XP SP3 (plus all subsequent updates)
--AMD Turion x64 processor
--Fresh install of special version of LibO listed above at http://dl.dropbox.com/u/193133/LibO_3.4.3rc1_Win_x86_install_en-US.exe (2011-10-23 version)
--Used all defaults for special LibO install

Post Install Check:
--Checked MS Windows Indexing Services...Advanced Features...Files
------The Indexing Service reports the correct install location for all LibO related file extensions but the DLLs do not appear to have any x64 indicators. (I mention this but am not sure whether it is relevant.)
--Created test directory (Test Libre)
--Verified that Windows Indexing will index the test directory.


Test:
--Opened newly installed Writer from Desktop icon.
--Created a new document using Writer.
--Inserted simple unique test phrase in document text.
--As recommended, closed Writer and when prompted to save, saved the file to the test directory.
--Opened Windows Control Panel...Indexing
--Manually selected Rebuild Index. (minimal directories selected to minimize indexing).
--Waited for manual indexing to complete. (Prompt stated 'indexing complete.')
--Used Windows XP Search...Advanced to search for the unique identifier saved in the document text. Note, I specifically searched for TEXT within the document and not for any filename attributes so we can verify that the indexing of CONTENT apparently works.
--After a short wait, document WAS FOUND by Windows XP Search.

But the whole point of the patch was to fix the build of the 64-bit shell extension DLLs, so it should have no effect on how the shell extension works on a 32-bit Windows...

So, to double-check, bugzilla@abbacan.com , are you running a 32- or 64-bit Windows XP?

And if it as 64-bit XP, is the Explorer process still 32-bit? I have never had 64-bit XP, I don't know...

LibreOffice 3.4.4 code freeze it's today. I don't want to hurry and push Tor's patch as we are still not sure if it works or not.

I want to make more tests and fix this properly.

My mistake.

My Windows XP Media Center appears to be running x32 NOT x64--despite the x64 processor. (My mistake.) This explains why the Indexing DLLs are the x32 versions and not the x64 versions. My test was NOT effective.

If anyone else needs to test a Windows system to see whether the system is x32 or x64, see the Microsoft article entitled 'How to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system.' http://support.microsoft.com/kb/827218 (http://support.microsoft.com/kb/827218) 

Sorry.

UPDATE--SECOND TEST--True x64 Windows Used
Test Date: 2011-10-24

Second Test Platform:
--Windows 7 Home Premium (plus all updates)
--x64 Intel i3 x64 Dual Core Processor
--Fresh install of special version of LibO listed above at
http://dl.dropbox.com/u/193133/LibO_3.4.3rc1_Win_x86_install_en-US.exe
(2011-10-23 version)
--Used all defaults for special LibO install

Pre-Install Check:
--Manually verified a true x64 Windows 7 OS

Post Install Check:
--Checked MS Windows Indexing Services...Advanced Features...Files
--OpenDocuments all listed in file indexing list (ODT, etc.)
--Created test directory (/Test Libre)
--Verified that Windows Indexing will index the test directory

Second Test:
--Opened newly installed LibreOffice instance from the Desktop icon and selected Writer (text document).
--Created a new document using Writer.
--Inserted two, simple unique test phrases in document text.
--As recommended, closed Writer and when prompted to save, saved the file to
the test directory.
--Opened Windows Control Panel...Indexing
--Manually selected Rebuild Index.
--Waited for manual indexing to complete. (Prompt stated 'indexing complete.')
--Used Windows 7 x64 Standard Search... [from Start Menu] to search for the unique identifier saved previously in the document text. Note, I specifically searched for TEXT within the document and not for any file name attributes so we can verify that the indexing of CONTENT apparently works.
--After a short wait, document WAS FOUND by Windows 7 x64 Search.
--Repeated for second unique phrase--second phrase also found. 

Conclusion:
The revisions seem to work on my test system (Windows 7 x64) after a clean install.

System: x64 PC (AMD Athlon II X4 630)
OS: Windows 7 SP1 64-bit confirmed

I confirm that the patched build:
http://dl.dropbox.com/u/193133/LibO_3.4.3rc1_Win_x86_install_en-US.exe
given in Comment 24 works correctly in Windows x64 indexing. It also functions as expected in general (including producing file thumbnails in Windows Explorer).

I installed the build from Comment 24 after uninstalling the standard LibO 3.4.3 build. I did no other special steps. Windows "Indexing options" confirmed that my index is already complete.

I find that (almost) all unencrypted ODF files can be found by searching for words in the contents as described in Comment 22. This works for (almost) all files including the following:

* files I have not opened since the new install
* files newly saved in the new install by File>Exit (whether newly created or old files modified and saved) including indexing of new content
* files newly saved in the new install by File>Save (whether newly created or old files modified and saved) including indexing of new content

[Note: Windows Libraries and indexing can behave erratically (at least on my system) when recognising newly saved files, but this problem is not restricted to ODF files. After a short delay, if the folder is in a Windows Library, the library should update. Sometimes the library seems to be locked, then it may not index the file. Don't know if this is a standard problem or eg caused by my anti-virus. This is more likely to happen if the file is saved by File>Save, but apparently can succeed or fail either way.]

The patched build seems to be working correctly in all respects. Thanks for the work done on this.

I don't know the mechanism whereby the complete index was so rapidly up-to-date once these DLLs were fixed, but they are clearly essential to permit indexing/searches to function. I confirm the following DLLs are present following installation of the new build:

C:\Program Files (x86)\LibreOffice 3.4\Basis\program\shlxthdl\shlxthdl_x64.dll
C:\Program Files (x86)\LibreOffice 3.4\Basis\program\shlxthdl\ooofilt_x64.dll
C:\Program Files (x86)\LibreOffice 3.4\Basis\program\shlxthdl\propertyhdl_x64.dll
C:\Program Files (x86)\LibreOffice 3.4\Basis\program\shlxthdl\shlxthdl.dll
C:\Program Files (x86)\LibreOffice 3.4\Basis\program\shlxthdl\ooofilt.dll
C:\Program Files (x86)\LibreOffice 3.4\Basis\program\shlxthdl\propertyhdl.dll

UPDATE--THIRD TEST----Windows VISTA Test--True x64 Windows Used
Test Date: 2011-10-25

Findings Summary:
"Dirty" install of http://dl.dropbox.com/u/193133/LibO_3.4.3rc1_Win_x86_install_en-US.exe
(2011-10-23 version--Comment #24 above) installs correctly and indexing works on a x64 Windows Vista System.

Second Test Platform:
--Windows Vista Home Premium (plus all updates)
--x64 Intel Core DUO x64 Processor
--"Dirty" install of special version of LibO listed above at
http://dl.dropbox.com/u/193133/LibO_3.4.3rc1_Win_x86_install_en-US.exe
(2011-10-23 version)
----By a dirty install, I simply installed over an OpenOffice 3.3 install. I did not remove OpenOffice before installing the LibreOffice install.
--Used all defaults for special LibO install

Pre-Install Check:
--Manually verified a true x64 Windows Vista OS

Test:
--Opened newly installed LibreOffice instance from the Desktop icon and
selected Writer (text document).
--Created a new document using Writer.
--Inserted one, simple, unique test phrase into the document text.
--As recommended, closed Writer and when prompted to save, saved the file to
the test directory.
--Used Windows Vista x64 Standard Search... [from Start Menu] to search for the
unique identifier saved previously in the document text. Note, I specifically
searched for TEXT within the document and not for any file name attributes so
we can verify that the indexing of CONTENT apparently works.
--After a short wait, document WAS FOUND by Windows Vista x64 Search.

Conclusion:
The revisions seem to work on my test system (Windows Vista x64) even after a "dirty" install.

The fix has been integrated into the LibreOffice 3.4 branch and will be in the LibreOffice 3.4.4 release.

If LibreOffice 3.4.4 RC1 works fine, I will close this bug.

I am using the LibreOffice 3.4.4 RC1 build all day and it works fine on 64-bit, including Windows search of ODF file contents. Many thanks Tor and Jesus for fixing this.

Do other users find that Windows Libraries and Indexing generally do not update when LibO or OOo do File>Save? It seems LibO/OOo do something different when saving on File>Exit that makes Windows respond. Files saved by other applications do not have this problem. Perhaps I may get round to making a bug report ;) . I also have one .ods file that corrupts number formatting on File>Save and on auto-saving for AutoRecovery, but not on File>Exit.

The official binaries for LibreOffice 3.4.4 RC1 should be available by the end of the week, Oct 28, 2011. Those are the ones to test :)

Please fill other bug reports for the rest of the issues. Having detailed, clear, and well organized bug reports is key to get the problems solved.

And last but not least: good job!

Preliminary test binaries are available here:

http://dev-builds.libreoffice.org/pre-releases/win/x86/

If they work, I close the bug :)

Yes, the LibO 3.4.4RC1 (Build:401) at http://dev-builds.libreoffice.org/pre-releases/win/x86/ works fine for Windows Search contents indexing on Windows 7 64-bit, whether installed clean or installed over 3.4.3. The 32-bit and 64-bit DLLs are installed correctly :)

Fixed in LibreOffice 3.4.4.

*** Bug 35842 has been marked as a duplicate of this bug. ***