Issue 23780 - sversion.ini is not a good solution, untill we can use %USERPROFILE%
Summary: sversion.ini is not a good solution, untill we can use %USERPROFILE%
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC Windows 2000
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2003-12-22 09:52 UTC by hallstein
Modified: 2013-08-07 15:26 UTC (History)
3 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description hallstein 2003-12-22 09:52:09 UTC
I run roaming profiles in my Windows-network, and the roaming profile's path 
is "connected" to the Windows %USERPROFILE% variable.  I see OpenOffice uses 
the sversion.ini file to tell where OO is installed. However, this might not be 
a good solution, considering that the Profile dirname might change. This is due 
to the fact that sometimes Windows have another profile with the same name, 
which might be an old profile "hanging around", e.g. the old user lost it 
connection to the server during synchronization with Roaming Profile network 
container.   Or maybe there are several duplicate usernames, but all are from 
different thrusted domains..  Windows then uses e.g. C:\Documents and 
Settings\username.DOMAIN  to sort them out..    

OpenOffice should be as any other Windows application; trust the %USERPROFILE% 

So, how about activating some kind of %USERPROFILE% variable-support in 
sversion.ini ?  It would certainly help me and all my desktops. Now I have to 
make some kind of user-loginscript that alters this sversions.ini EVERY time a 
user logs in (vbscript that gets the profile dir and fixes the sversions). This 
is really not the best choice for me, who live in an environment where my users 
are also managed by other domain-admins in other trusted domains, where i have 
no control over loginscripts (yes we are a BIG domain with tens thousands of 
Comment 1 Olaf Felka 2003-12-22 10:05:52 UTC
of @ hallstein: Please have a look at We
are on the way.
of @ cj: Please keep in mind.
Comment 2 hallstein 2003-12-22 10:14:09 UTC
can somebody please make a soffice.exe that can interpret this %USERPROFILE% so 
I'm solving my problem before new year? I'm on a very tight schedule here.
Comment 3 hallstein 2003-12-22 10:20:21 UTC
or forget that, this will make my clients non-working on other networks.  we 
all share their same roaming profile. i better make a loginscript-hack
Comment 4 christian.jansen 2004-03-23 16:19:37 UTC
Cj -> IS: Hi Ingo, this reqest makes sense. Could you keep this in mind for the
native installer stuff? Thx.
Comment 5 2004-12-02 10:56:05 UTC
sversion.ini is no longer used. The soffice.exe reads the path to the user from
the bootstrap.ini in "UserInstallation=$SYSUSERCONFIG/.staroffice8".
The path to the installation is stored in  the Windows registry in

IS -> LO: Does the soffice.exe use the Windows variable %USERPROFILE% ?
I think we set this task to OOo later. How do you think about this.
Comment 6 lo 2007-03-06 16:39:55 UTC
dispatching to framework group
Comment 7 carsten.driesner 2007-03-08 10:42:02 UTC
cd: Accepted.

cd->hro: Do we support %USERPROFILE% in sal?