I don't think %ProgramData% is a good location for files that are not designed to be modified after install.

Maybe will be better to make only a 32 bit version of the help installer and modify LibreOffice to look for help on the 32 bit program folder?  Or better, LibreOffice should look for a registry key (on the 32 bit view of the registry), so the user can choose another volume to install (let's not use our SSDs to store files that don't need to be fast to open, right?).

This way it won't matter if the user installs the 32 bit or the 64 bit version of LibreOffice, neither if the user chooses another folder to install the help files.

(In reply to João Paulo from comment #1)
> I don't think %ProgramData% is a good location for files that are not
> designed to be modified after install.

I disagree.
As MS describes at [1],

> FOLDERID_ProgramData ... This folder is used for application data that is not
> user specific. For example, an application can store a spell-check dictionary,
> a database of clip art, or a log file in the CSIDL_COMMON_APPDATA folder.
> This information will not roam and is available to anyone using the computer.

The described use case aligns well with the case here. Downloaded spell-check dictionary is also not intended for modifications after installations (user spell-check dictionaries are kept in per-user directories), and e.g. that location may open an option to allow downloading the help right from the program.

I dislike the idea of registry-configurable place for the help pack. Having a well-known location is better IMO, and would limit registry configurations used by LibreOffice (which is OS-specific behaviour).

[1] https://docs.microsoft.com/en-us/windows/win32/shell/csidl

Hi @Mike!

I think the examples Microsoft chose leads to interpretation ambiguity/confusion and security issues.  Let me explain my point of view:

> FOLDERID_ProgramData ... This folder is used for application data that is not
> user specific. For example, an application can store a spell-check dictionary,
> a database of clip art, or a log file in the CSIDL_COMMON_APPDATA folder.

The NTFS security settings on "C:\ProgramData" allows any user to read any file, folder and subfolder (unless there is a setting denying it on any file or subfolder), and it also allows any user to create any files or subfolders, and also allows the file or subfolder creator to change any security setting on that file.  Epson even apply additional security settings to one subfolder of the EPSON subfolder (the "EPSON\<printer model>" folder), NVIDIA change the security settings entirely on its subfolder (big mistake IMHO), and Mozilla adds the user who first installed any of its software as a permanent administrator of its Mozilla subfolder (I don't know why, as that is not needed by the Mozilla Maintenance Service which runs under the Local System Account).

* A database of clip art can be changed over time, as users create or erase clip art files on their shared folders, or the cloud server provides new clip arts.  That is the intent of a database, right?  To be machine-changeable if the software installer change (and of course their consuming software should be written against buffer-overflow exploits -- or this database is used only for locally installed clip arts under %ProgramFiles% or %CommonProgramFiles%);

* A log file is obviously a file type that can change over time, logging certain user, software or system activities and events.  Ideally, the software installer should set the security permissions to not allow the user to erase the file or remove data from it.

* Now there is the "spell-check dictionary" to understand.  You wrote:

> Downloaded spell-check dictionary is also not intended for modifications after installations (user spell-check dictionaries are kept in per-user directories), and e.g. that location may open an option to allow downloading the help right from the program.

I agree with you that %ProgramData% **could** be used for the spell-check dictionaries, but as they are more like software resources than modifiable data files, it's best to leave them together with LibreOffice under %ProgramFiles% (after all %ProgramFiles% was made for it).

But my concerns about the help files are because we would have then the following scenarios:

* Administrator Alice installs LibreOffice.  User Bob (not an administrator) decides to install LibreOffice Help to %ProgramData%\LibreOffice, which he can because the NTFS default security allows it.  User Charlie (not an administrator) wants to update the LibreOffice Help files (in the event they are updated), but he can't, because the files created by Bob can be replaced only by Bob and an administrator.

* User Alice (an administrator) installs LibreOffice to %ProgramFiles%\LibreOffice and LibreOffice Help to %ProgramData%\LibreOffice.  Neither User Bob or User Charlie can update the help files in the event they are updated before the next LibreOffice release.  So what is the point of "open[ing] an option to allow downloading the help right from the program"?

Of course the above scenarios can be corrected by tweaking the security permissions before %ProgramData%\LibreOffice is created by any non-admin user, but IMHO this is difficult to do correctly.  And I have a question:  **Is the LibreOffice Offline Help Viewer really hardened against security bugs?**

So, if LibreOffice Help installers are to be merged, maybe the best course of action (after agreeing with you that a registry configurable place for it is a bad idea and a well-known location is better) would be installing them only under %ProgramFiles% (even on 64 bit OS), then making LibreOffice 32 and 64 bits search for it using first %ProgramFiles% and if not found there trying %ProgramW6432%, as the latter will translate to %ProgramFiles% on 64 bit and ARM64 OSes according to "https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details#environment-variables".