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
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
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.
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
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
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
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.
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
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
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.
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 :)
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
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
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
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?
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
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
-
David Lee Lambert -
Fabian Cenedese -
Henning Gerhardt -
Marcus Meissner -
Mike Hearn -
Rick Romero -
Vincent Béron