config converting problem

[Henning Gerhardt]

Hi all,

a friend of me would update the wine package (20030813) from his SuSE 9.0 system 
to the latest availabe package for this system (20040716). After the update following 
error message appears on each start of wine:

....
Warning: the specified Windows directory L"C:\\Windows" is not accessible.
Warning: the specified System directory L"C:\\Windows\\System" is not accessible.

He get me also an output of the first wine start:

Created symlink /home/julian/.wine/dosdevices/c: -> ../${HOME}/.wine/fake_windows
....
Created symlink /home/julian/.wine/dosdevices/y: -> ../${HOME}
....
Warning: the specified Windows directory L"C:\\Windows" is not accessible.
Warning: the specified System directory L"C:\\Windows\\System" is not accessible.


After my advise to get me the content of his "~/.wine/dosdevices", he send me 
the following output:

....
lrwxrwxrwx 1 julian users 28 10. Aug 18:50 c: -> ../%HOME%/.wine/fake_windows
....
lrwxrwxrwx 1 julian users  9 10. Aug 18:50 y: -> ../%HOME%
....

and he send me also his config file (snipped content):

[Drive C]
 "Path" = "${HOME}/.wine/fake_windows"
 "Type" = "hd"
 "Label" = "fake_windows"
 "Filesystem" = "win95"

...

[Drive Y]
 "Type" = "network"
 "Path" = "${HOME}"
 "Label" = "Home"
 "FS" = "win95"

....

(I translated the german dialog with him to english)

I think the problem is the ${HOME} variable which is not parsed / correct replaced 
during the convert process.

Have anyone an idea to solve this problem ? Or is it only a problem of the 
SuSE distribution ?

Regards,

	Henning

[Vincent Béron]

Le mer 11/08/2004 à 04:40, Henning Gerhardt a écrit :
> Hi all,
>
> a friend of me would update the wine package (20030813) from his SuSE 9.0 system 
> to the latest availabe package for this system (20040716). After the update following 
> error message appears on each start of wine:
>
> ....
> Warning: the specified Windows directory L"C:\\Windows" is not accessible.
> Warning: the specified System directory L"C:\\Windows\\System" is not accessible.

Mike, we might have one of the situations causing this error here.
> He get me also an output of the first wine start:
>
> Created symlink /home/julian/.wine/dosdevices/c: -> ../${HOME}/.wine/fake_windows
> ....
> Created symlink /home/julian/.wine/dosdevices/y: -> ../${HOME}
> ....
> Warning: the specified Windows directory L"C:\\Windows" is not accessible.
> Warning: the specified System directory L"C:\\Windows\\System" is not accessible.
>
> After my advise to get me the content of his "~/.wine/dosdevices", he send me 
> the following output:
>
> ....
> lrwxrwxrwx 1 julian users 28 10. Aug 18:50 c: -> ../%HOME%/.wine/fake_windows
> ....
> lrwxrwxrwx 1 julian users  9 10. Aug 18:50 y: -> ../%HOME%
> ....
>
> and he send me also his config file (snipped content):
>
> [Drive C]
>  "Path" = "${HOME}/.wine/fake_windows"
>  "Type" = "hd"
>  "Label" = "fake_windows"
>  "Filesystem" = "win95"
>
> ...
>
> [Drive Y]
>  "Type" = "network"
>  "Path" = "${HOME}"
>  "Label" = "Home"
>  "FS" = "win95"
>
> ....
>
> (I translated the german dialog with him to english)
>
> I think the problem is the ${HOME} variable which is not parsed / correct replaced 
> during the convert process.
>
> Have anyone an idea to solve this problem ? Or is it only a problem of the 
> SuSE distribution ?

It's not SuSE specific. It's a problem from upgrading from a (somewhat)
old to a newer Wine version.

Wine used to understand ${HOME}-style vars in config. This was then
changed to %HOME%-style vars. Current Wine doesn't use config anymore
for drives but uses dosdevices, which is created on the fly from config
if it doesn't exist.

So the problem comes from 2 changes, with only the latter being acted on
automatically.

If you want to fix it, the simplest way would be to create the following
symlinks in ~/.wine/dosdevices:

ln -s ../fake_windows c:
ln -s /home/julian y:

Vincent

[Mike Hearn]

> If you want to fix it, the simplest way would be to create the following
> symlinks in ~/.wine/dosdevices:
>
> ln -s ../fake_windows c:
> ln -s /home/julian y:

Or to delete ~/.wine

I'm not sure what to do about this, except maybe to add back in support 
for ${HOME} style vars. It's clear that people are "using" (at least, 
installing) much older versions than we anticipated.

[Vincent Béron]

Le mer 11/08/2004 à 08:38, Mike Hearn a écrit :
> > If you want to fix it, the simplest way would be to create the following
> > symlinks in ~/.wine/dosdevices:
> >
> > ln -s ../fake_windows c:
> > ln -s /home/julian y:
>
> Or to delete ~/.wine

And lose fake_windows????
> I'm not sure what to do about this, except maybe to add back in support 
> for ${HOME} style vars. It's clear that people are "using" (at least, 
> installing) much older versions than we anticipated.

The problem comes when upgrading from an old version (still supporting
${HOME}) to a newer version (supporting either %HOME% or dosdevices).

The older version, by itself, still works correctly.

Vincent

[Mike Hearn]

> And lose fake_windows????

Yes. Do users keep anything important there? (Answer is: they shouldn't 
do). Data files they create/use should be in their unix home dir, so rm 
~/.wine -rf shouldn't be seen as drastic, they can just reinstall.

I blow away ~/.wine all the time.

thanks -mike

[Vincent Béron]

Le mer 11/08/2004 à 08:58, Mike Hearn a écrit :
> > And lose fake_windows????
>
> Yes. Do users keep anything important there? (Answer is: they shouldn't 
> do). Data files they create/use should be in their unix home dir, so rm 
> ~/.wine -rf shouldn't be seen as drastic, they can just reinstall.

Don't forget that My Documents is on c: by default.

Also, reinstalling all apps just because you upgraded Wine seems a bit
overkill, no?
> I blow away ~/.wine all the time.

I do the same, but as you develop Wine, I'd expect it.

Vincent

[Mike Hearn]

> Don't forget that My Documents is on c: by default.

Hmm, that's true. That should definitely be fixed. I don't even think we 
map the home directory in wineprefixcreate by default, do we? I think 
Marcus' patch adds that.
> Also, reinstalling all apps just because you upgraded Wine seems a bit
> overkill, no?

Well, yeah, but over time I think it becomes necessary as the contents 
of the initial registry/config file change etc ... it's hard to know 
exactly what you need to do so reinstalling is the easiest way.

It sucks, I agree.

[Fabian Cenedese]

> > Also, reinstalling all apps just because you upgraded Wine seems a bit
> > overkill, no?
>
> Well, yeah, but over time I think it becomes necessary as the contents of the initial registry/config file change etc ... it's hard to know exactly what you need to do so reinstalling is the easiest way.
>
> It sucks, I agree.

What was the ultimate bugfix if you have a problem in Windows? Looks like
wine is really getting close to become like Windows :)

bye  Fabi

[Rick Romero]

On Wed, 2004-08-11 at 08:08, Mike Hearn wrote:
> > Don't forget that My Documents is on c: by default.
>
> Hmm, that's true. That should definitely be fixed. I don't even think we 
> map the home directory in wineprefixcreate by default, do we? I think 
> Marcus' patch adds that.
> > Also, reinstalling all apps just because you upgraded Wine seems a bit
> > overkill, no?
>
> Well, yeah, but over time I think it becomes necessary as the contents 
> of the initial registry/config file change etc ... it's hard to know 
> exactly what you need to do so reinstalling is the easiest way.
>
> It sucks, I agree.

I shudder to mention it.. but Win2k supports mounting partitions as a
directories under NTFS (like unix mount).

Does anyone know where that functionality resides?


So instead of just having:
c: = ~/.wine/c_drive
d: = /mnt/cdrom
.....

You could have

c: = ~/.wine/c_drive
c:\My Documents\ = ~/Documents
c:\Program Files\ = ~/Windows Progs
d: = /mnt/cdrom

Then wiping your ~/.wine would preserve your files, and with those apps
that don't require registry settings would just work without a reinstall
(Pegasus Mail is a good example).

Rick

-- 
--
Rick Romero
IT Manager	
Valeo, Inc.	ph: 262.695.4841
Sussex, WI.	fax: [phone]
Rick(a)valeoinc.com

[Mike Hearn]

> You could have
>
> c: = ~/.wine/c_drive
> c:\My Documents\ = ~/Documents
> c:\Program Files\ = ~/Windows Progs
> d: = /mnt/cdrom
>
> Then wiping your ~/.wine would preserve your files, and with those apps
> that don't require registry settings would just work without a reinstall
> (Pegasus Mail is a good example).

I think it would be better to figure out a way to do upgrades better. 
Also when we change something, it seems we need to massively increase 
the amount of time the old way is still valid for. The problem of being 
installing ancient distros then upgrading won't go away anytime soon.

[Rick Romero]

On Wed, 2004-08-11 at 08:50, Mike Hearn wrote:
> > You could have
> >
> > c: = ~/.wine/c_drive
> > c:\My Documents\ = ~/Documents
> > c:\Program Files\ = ~/Windows Progs
> > d: = /mnt/cdrom
> >
> > Then wiping your ~/.wine would preserve your files, and with those apps
> > that don't require registry settings would just work without a reinstall
> > (Pegasus Mail is a good example).
>
> I think it would be better to figure out a way to do upgrades better. 
> Also when we change something, it seems we need to massively increase 
> the amount of time the old way is still valid for. The problem of being 
> installing ancient distros then upgrading won't go away anytime soon.

I guess I was thinking more along the lines of a Wine reinstall to fix
'Windows' problems, not necessarily Wine upgrades.

Just something else to think about :)

-- 
--
Rick Romero
IT Manager	
Valeo, Inc.	ph: 262.695.4841
Sussex, WI.	fax: [phone]
Rick(a)valeoinc.com

[Marcus Meissner]

On Wed, Aug 11, 2004 at 09:06:56AM -0400, Vincent Béron wrote:
> Le mer 11/08/2004 à 08:38, Mike Hearn a écrit :
> > > If you want to fix it, the simplest way would be to create the following
> > > symlinks in ~/.wine/dosdevices:
> > >
> > > ln -s ../fake_windows c:
> > > ln -s /home/julian y:
> >
> > Or to delete ~/.wine
>
> And lose fake_windows????
> > I'm not sure what to do about this, except maybe to add back in support 
> > for ${HOME} style vars. It's clear that people are "using" (at least, 
> > installing) much older versions than we anticipated.
>
> The problem comes when upgrading from an old version (still supporting
> ${HOME}) to a newer version (supporting either %HOME% or dosdevices).
>
> The older version, by itself, still works correctly.

On SUSE:

mv away the fake_windows directory (mv ~/.wine ~/.wine.old).

run wineprefixcreate, it will create a new setup.

Copy over the old tree.

cp -a ~/.wine.old/fake_windows/* ~/.wine/fake_windows/

... You might want to copy over the registries (system.reg and user.reg)
too.

Ciao, Marcus

[Henning Gerhardt]

Hi Marcus, you wrote:
> > > I'm not sure what to do about this, except maybe to add back in support 
> > > for ${HOME} style vars. It's clear that people are "using" (at least, 
> > > installing) much older versions than we anticipated.
> >
> > The problem comes when upgrading from an old version (still supporting
> > ${HOME}) to a newer version (supporting either %HOME% or dosdevices).
> >
> > The older version, by itself, still works correctly.
>
> On SUSE:
>
> mv away the fake_windows directory (mv ~/.wine ~/.wine.old).
>
> run wineprefixcreate, it will create a new setup.

I have a question: Why create wineprefixcreate the "Program Files" and 
"Program Files/Common Files" as a subdirectory of the windows directory instead of 
the root directory ?

I attached a patch to prevent this behaviour.

Bye,

	Henning

[Henning Gerhardt]

Hi Mike, you wrote:
> > If you want to fix it, the simplest way would be to create the following
> > symlinks in ~/.wine/dosdevices:
> >
> > ln -s ../fake_windows c:
> > ln -s /home/julian y:
>
> Or to delete ~/.wine

I think this is not a good idea because of all your own documents or 
installed programs.
> I'm not sure what to do about this, except maybe to add back in support 
> for ${HOME} style vars. It's clear that people are "using" (at least, 
> installing) much older versions than we anticipated.

Personally I would prefer to merge back the support for ${HOME}
variables because I think many other people have the same problem
if they want to upgrade wine.

Regards,

	Henning

[wine] Re: config converting problem

[David Lee Lambert]

On Wed, Aug 11, 2004 at 04:45:20PM +0200, Henning Gerhardt wrote:
> Hi Mike, you wrote:
> > I'm not sure what to do about this, except maybe to add back in support 
> > for ${HOME} style vars. It's clear that people are "using" (at least, 
> > installing) much older versions than we anticipated.
>
> Personally I would prefer to merge back the support for ${HOME}
> variables because I think many other people have the same problem
> if they want to upgrade wine.

Not having totally grokked the code,  I think this raises an important semantic 
issue:  if ~/.wine/dosdevices and the config-file's text conflict,  which has 
priority?  Or should Wine read the config-file and then (effectively) overwrite the 
settings with the contents of ~/.wine/dosdevices?  This won't work if Wine 
automatically builds ~/.dosdevices from scratch.

It seems that mapping one drive to the user's home directory is a common case,  
since many organizations already do this for users via Samba or Netware.  As 
presently implemented,  is there any reason a system administrator shouldn't do

( cd /etc/skel ; mkdir -p .wine/dosdevices ; cd .wine/dosdevices ; ln -s f: ../.. )

where f (for example) is the drive letter used for each user's home directory,  and 
then use a shell script to push the change out retroactively to existing accounts?

-- 
resume at  http://www.cse.msu.edu/~lamber45/resume.htm
PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

[wine] Re: config converting problem

[Vincent Béron]

Le dim 15/08/2004 à 00:21, David Lee Lambert a écrit :
> On Wed, Aug 11, 2004 at 04:45:20PM +0200, Henning Gerhardt wrote:
> > Hi Mike, you wrote:
> > > I'm not sure what to do about this, except maybe to add back in support 
> > > for ${HOME} style vars. It's clear that people are "using" (at least, 
> > > installing) much older versions than we anticipated.
> >
> > Personally I would prefer to merge back the support for ${HOME}
> > variables because I think many other people have the same problem
> > if they want to upgrade wine.
>
> Not having totally grokked the code,  I think this raises an important semantic 
> issue:  if ~/.wine/dosdevices and the config-file's text conflict,  which has 
> priority?  Or should Wine read the config-file and then (effectively) overwrite the 
> settings with the contents of ~/.wine/dosdevices?  This won't work if Wine 
> automatically builds ~/.dosdevices from scratch.

Only ~/.wine/dosdevices is used now. The drive sections in the config is
used to build dosdevices if it doesn't exist, then it is read back as if
existed before.
> It seems that mapping one drive to the user's home directory is a common case,  
> since many organizations already do this for users via Samba or Netware.  As 
> presently implemented,  is there any reason a system administrator shouldn't do
>
> ( cd /etc/skel ; mkdir -p .wine/dosdevices ; cd .wine/dosdevices ; ln -s f: ../.. )
>
> where f (for example) is the drive letter used for each user's home directory,  and 
> then use a shell script to push the change out retroactively to existing accounts?

That will probably cause some problems with the way we currently detect
whether or not to lauch wineprefixcreate, which is the existence or not
of ~/.wine. You should customize your version of wineprefixcreate if
that's what you want to achieve (but it won't be applied to existing
~/.wine dirs, that'll need to be taken care of in another manner.
Updates to ~/.wine between versions are not very well managed right now
in Wine.).

Vincent

[Henning Gerhardt]

Hillo Vincent, your wrote:
> If you want to fix it, the simplest way would be to create the following
> symlinks in ~/.wine/dosdevices:
>
> ln -s ../fake_windows c:
> ln -s /home/julian y:

I get him the same advice and it works now.

Regards,

	Henning