[Libreoffice-bugs] [Bug 118754] Inappropriate Default File Paths Imposed in Custom Installations

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=118754

--- Comment #5 from Jaws <ceplaw at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180829/fb791d69/attachment-0001.html>