Observed behaviour: On a Windows7-64 Enterprise system the configuration settings (Tools->Options) are lost when the Windows user account utilizes a roaming profile. The problem does not occur when using local profiles and does not affect the Java settings (Tools->Options->LibreOffice->Java). Expected behavior: The configuration settings are kept independent of the type of profile used. LibO versions affected: I first encountered this bug in the LibO 3.5 series (with 3.5.4 and 3.5.5 definitively being affected) and is it still present in 3.6 RC2 and RC4. How to reproduce: 1. Start LibO on a Windows system from a user account with roaming profiles 2. Open the configuration setting (Tools->Options) 3. Perform changes (e.g. under LibreOffice->User Data) and press ok. 4. Open the configuration settings again: The modifications are still there. 5. Quit and re-start LibO 6. Open the configuration settings: The modifications are gone.
Not reproducible on libo 3.5.3 and libo 3.5.6.1 roaming profils on a 2008R2 domain opening a new session on a seven x64 computer. changing an option of libo (memory usage 20 -> 200 MB) closing session checking the roaming profile on the server opening a session on another computer seven x32 the option is with libo
I tested it again with LibO 3.5.6.2 and the problem persists. Therefore here some further information: In my setup, for users with roaming profiles, %APPDATA% points to a UNC (\\<server>\<share>\AppData\<user>), while for users with local profiles it points to the default Win7 location using a local path (C:\Users\<user>\AppData\Roaming). For both - local and roaming users - the configuration directory structure (including/below %APPDATA%\LibreOffice\3\user) is created when first starting LibO. However, %APPDATA%\LibreOffice\3\user\registrymodifications.xcu (which holds the majority of config options) is only created for local users. It further seems like roaming users cannot read from this file, since pasting a copy from a local user into the existing tree structure of a roaming user does not transfer the respective settings (they do not appear in the Tools->Options dialog). Hence the question: Does your %APPDATA% point to a UNC or not?
Additional tests with older versions showed that the problem does not exist in LibO 3.4.6 but is first appears in 3.5.0. I therefore consider this to be a regression (-> setting keyword, rising priority, changing version).
Still present in 3.6.1 rc2.
> > Hence the question: Does your %APPDATA% point to a UNC or not? no, it does not it's a simple roaming profile. all the profile is uploaded to the server and downloaded to the station when needed.
The problem is still present in LibO 3.6.2.2. Below you will find a procedure for Windows 7 that should allow to reproduce the problem without requiring an Active Directory, a Windows Server or actual roaming profiles. All you need is a normal network share with read/write access (hereafter termed "\\server\share"). As it can be seen in the procedure, the critical environment variable is apparently not APPDATA but USERPROFILE, from which LibO seems to reconstruct the APPDATA path by appending "\AppData\Roaming". 1. Create the following test folders on the share \\server\share\libotest \\server\share\libotest\AppData \\server\share\libotest\AppData\Roaming 2. Map \\server\share to a drive letter (hereafter termed "X:) 3. Open the Windows command line and change to the LibO program directory (e.g. "C:\Program Files (x86)\LibreOffice 3.6\program") 4. Check your USERPROFILE environment variable: 'echo %USERPROFILE%' -> by default this will point to "C:\Users\<username>" 5. Set the USERPROFILE to the test directory on the mapped drive: 'set USERPROFILE=X:\libotest' 6. Start LibO via the command line: 'soffice.exe' It is important to do this from the command line, otherwise the default USERPROFILE will be used. -> LibO should start now, and a config directory "LibreOffice" should be created in X:\libotest\AppData\Roaming 7. Perform the test as described in the original description (2012-07-30) -> the modifications to the settings should be maintained -> In the config directory, "3\user\registrymodifications.xcu" will be created 8. Quit LibO and delete the config directory from X:\libotest\AppData\Roaming 9. Set the USERPROFILE to the test directory using the UNC: 'set USERPROFILE=\\server\share\libotest' 10. Again start LibO via the command line (as in 6.) and test (as in 7.): -> the config directory "LibreOffice" should be created in \\server\share\libotest\AppData\Roaming -> the modifications to the settings are lost. -> "3\user\registrymodifications.xcu" will not be created in the config directory.
The problem is resolved in both LibO 3.6.4.3 and 4.0.0.2 rc.