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?