<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Inappropriate Default File Paths Imposed in Custom Installations" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118754#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Inappropriate Default File Paths Imposed in Custom Installations" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118754">bug 118754</a> from <a class="email" href="mailto:ceplaw@gmail.com" title="Jaws <ceplaw@gmail.com>"> Jaws</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>