@Mike, I thought you could be interested in this issue...

Well - the program files part seems relevant (needs checking if and why is it so). User profile part is irrelevant, since roaming profile is where per-user data is kept, and that is by design. (Portable version could have it done differently possibly.)

I couldn't reproduce the Program Files problem with 6.1.1.1.

What I did: on a test Win7x64sp1 box (with no prior LO installation), I launched LibreOffice_6.1.1.1_Win_x64.msi. I chose custom install, path was set to C:\LibreOfficeCustom, and both top-level list elements were set to install with all sub-elements (= full install). After installation, I re-checked both C:\Program Files, and C:\Program Files (x86) to see that no LibreOffice directories are present there.

Of course, I also have checked that our MSI has proper directory structure, i.e., all LibreOffice components reference INSTALLLOCATION or another directories which in turn reference INSTALLLOCATION. So, that seems to be OK.

Please provide more details how can the problem (specifically with Program Files!) be reproduced.

FYI: the *default* user profile directory is defined in install location's program/bootstrap.ini, and by default, it is

> UserInstallation=$SYSUSERCONFIG/LibreOffice/4

on Windows, i.e., it points to system user profile's subdirectory. One can change the default location by editing the bootstrap.ini. One can also start a LibreOffice instance using a non-default profile location using -env:UserInstallation=file:///tmp/test command line switch (see https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html).

I'm afraid this is going off on a tangent a bit: I pointed out a fundamental design flaw and am getting some hacking advice.

(1) I don't have 6.1.1.1 or its msi to reproduce the fixes alleged above. This appears to be a prerelease version; and as I noted, this has been a consistent problem for years, back into the 4.x days.

(2) The failure of NOTICE is STILL a substantial problem, even with the purported fixes. On another machine for a version 5.0.x installation approximately two years ago, a colleague tried editing bootstrap.ini, pointing to a custom folder he expected Windows 8.1 to create... but because the folder didn't exist PRIOR TO installation (expecting the installer to create it, as is normal for any Linus or Windows program, but there's no record of why that creation failed), the installer silently reverted to its default location, gave no error flag of any kind, and eventually caused loss of three weeks' customization work* when Windows had to be reinstalled.

In short, DO NOT make a claim that things are going to location X without providing at minimum a notice that they're going somewhere else.

(3) At a more basic level, dictionaries (in particular) and templates (when dealing with professional/organizational restrictions) ARE NOT USER DATA. It's not limited to LibreOffice by any means (MSOffice is worse, and the less said about anything from Adobe and Oracle the better), but that's not an excuse -- only an explanation that program designers are still stuck on "if it doesn't come out of the compiler, it's merely data and should all be treated the same" as a model. It's not binary: Executables, parametric information that affects the way the executable operates, and actual user-modified-for-output data are fundamentally different. Put another way, "choose this template" is a helluva lot closer to something that one would have done with a command-line switch in the pre-GUI days than to actual "data"... but it's still not the same thing as the program itself.

At a fundamental level, the "by design put it in a user folder" IS WRONG. Each of the following nontrivial, nonunique events blows it up:
    An operating-system reinstall or repair caused by an unrelated disk error (e.g., a partition error), which necessarily wipes out the entire %user hierarchy
    An emergency, temporary shift of a person in an organization that is explicitly NOT networked (perhaps different physical locations, perhaps on laptops that have to be operated where there's no network connectivity), meaning that even organization/profession defaults are not available -- let alone that person's actual customization
    Recovery from (and even protection from) a hack -- for example, some malware out there in the wild leaves non %user/%windows/%program files folders pretty much alone
    Training of new users on standardization
    Remote recovery of "data files" from a backup that requires use of command-line parameters

I can accept BY DEFAULT put it in a user folder because that's the stupidity of the OS designs... but DO NOT make the pretense, upon installation, that "all" files are going to a custom folder/hierarchy when they're not. BOTH the initial installer parameters AND the installer's output need to explicitly notify the user, AND tell the user how to change those parameters (digging into a man page that isn't visible until the installer finishes running is just a little bit self-defeating... unless one of the other fundamental assumptions is that installs are always done with a live internet connection and the program's home page visible).

(4) Per Mike's comment of 11:22:09, which bootstrap.ini file is this? The one that I've edited before on Windows systems (in, if I recall, System32) then forces ALL user files/folders thereafter -- not just the program one is then installing -- into the new UserInstallation location, which has some... interesting effects on already-installed programs, and on how already-installed programs interact with new ones. Mike, if you mean a different bootstrap.ini on a Windows system, please specify the full file path... and test the proposed changes against other effects on that machine so I know if I had a nonreproducible problem. Further, this DOESN'T fix the problem noted above: Dictionaries, templates, and macros simply ARE NOT "user data," even when customized for a particular user, if only because they're "active" for every other file that the user is operating upon.

* Which matters a lot: It was a law practice and document parameters (and even dictionaries) are rigid and substantially different from the defaults. By itself, that's fine; but that's also PRECISELY why putting all customization into a user-linked folder is fundamentally bad program design. That presumes that the user-linked folder is independent of operating system integrity, and that's not the most robust assumption one can make.

Of course, writing "install location's program/bootstrap.ini" does not tell which bootstrap.ini is meant.

And there's no changes in installer in this regard in *several* releases, so 5.0 would work the same (just tested the installer of 5.0.1.2).

This is not a board for random accusations. If there is a problem where some program files go to "C:\Program Files" when you select a different install directory, then please provide direct steps to reproduce this *bug* (I had taken my time to check what you wrote (as I mentioned), and that wasn't able to reproduce). If you also want to be able to change the way how user data is *defined* (a) or stored (b), then file separate *enhancement requests* for each of those items. And in any case, the tone of both OP's posts does not imply a positive attitude.

I'm afraid we're having different "reproducibility" experiences, and without knowing more about what you're looking at (such as full paths) I can't figure it out either. Since there's no separate bootstrap.ini unique to LibreOffice available for editing when installing from the .msi, I had to assume that referred to the Windows system-level file... and I was able to reproduce the nonconforming behavior on a different Windows 7 machine for a 6.0.1 install since my last message. Editing the system-level bootstrap.ini breaks other programs. And changing it back to prevent it from breaking other programs will, no doubt, have interesting effects on any LibreOffice updates.

My "tone" is a result of a combination of a lingering headache and minor annoyance that a six-week-old bug note got its first responses (in a very defensively-toned flurry) claiming "unable to reproduce" and providing other incomplete suggestions, and should not be taken otherwise. This board system does not allow meaningful formatting that doesn't look like shouting IN ALL CAPS. 

That said, I'm entirely uncertain how as a non-insider I'm supposed to know that a disagreement with a fundamental design precept that results in continued errors on my systems and others around me in similar situations should be characterized as an "enhancement" and not a "bug." To someone from my 1970s-trained programming background, this is a "bug"; it's similar to the inability to change between US-letter and A4 on anything other than a document-by-document basis, unless one changed the entire machine's settings and reinstalled, in early versions of WinWord and Excel.

For the record: I have just downloaded OOo 3.3.0 from http://archive.apache.org/dist/incubator/ooo/stable/3.3.0/OOo_3.3.0_Win_x86_install-wJRE_en-US.exe, and tested it using the procedure from comment 3. I couldn't reproduce the problem with Program Files (x86) directory. Here is the screencast:

http://youtu.be/mIlfIyG4ENM?hd=1

As you can see, there's no OpenOffice directories/files in Program Files both before and after the installation. So I doubt there's a problem which you described in your initial message under the first asterisk. The same happens when I install 5.1.0.2 or 6.1.1.1.

Also, I doubt that it's me who needs to describe "about what I'm looking at". It's the reporter who needs to describe unambiguously where to look at to see the problem, since that person is the one who sees the problem. Still, I mentioned the paths explicitly several times (Program Files and Program Files (x86)), and hope that the video also aids at understanding where *I* was looking.

I also hope that the video helps understanding what "install location's program/bootstrap.ini" might possibly mean. I was under impression that LibreOffice (like its predecessor OpenOffice.org) does have its separate bootstrap.ini.

Of course, I must always remember that if something was considered good in 1970s, then it's The True Thing which couldn't have changed during the decades of progress. Then, of course, the fact that initial message was answered that long (by volunteers trying their best to handle all reports) is the real reason why the *initial* message is such rude. And when reading about "defensively-toned flurry", I keep remembering the great article by Simon Tatham named "How to Report Bugs Effectively" [1], which could shed some light on why we tell that we cannot reproduce, and ask for reliable steps (no, we don't claim our software is fine; it's just we cannot see the problem, and ask you to help us see it). If you take it that way, I cannot help.

[1] https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

(In reply to Jaws from comment #7)
> Since there's no separate bootstrap.ini unique to
> LibreOffice available for editing when installing from the .msi

Install LibreOffice and then before starting it go to <installation path>/program. There you will find the bootstrap.ini file.

I suggest, that you first discuss the different ways to install LibreOffice on mailing list or forum. It is possible to install LibreOffice totally into one folder, including the user settings.

(In reply to Regina Henschel from comment #9)
> It is possible to install LibreOffice totally into
> one folder, including the user settings.

... and portable installer (mentioned in comment 2, and available at [1]) does just that.

[1] https://www.libreoffice.org/download/portable-versions/

Dear Jaws,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp