Am Samstag, den 27.08.2005, 14:38 -0700 schrieb Hiji:
It might be the ugly way, but it is the official way.
That's because many Applications are unable to handle it yet.
This is definately *not* a Wine issue because it affects any application which relies on have a static name for the drive - let's make sure we're clear on that. ;)
No! This is not only a Wine issue, it's an issue of all applications which relies on static names. The big mistake: The Volume-Label is optional.
It's possible on windows (since w2k) to work without a Driveletter for your CDROM, ("%SYSTEMROOT%\mountpoint") but they made the same mistake: Using a mountpoint (junction) is optional. When they used the mountpoint-method as default and the driveletter-method as optional fallback for old applications, then all important software would work today without an extra driveletter for removeable media.
It's time to be more flexible. freedesktop.org did a step in the direction, now the applications must follow!
I suspect this "mounting by volume label" won't last past Suse 9.3 since
.. and go backwards? No way!
I haven't read anyone praise this "feature" anywhere.
That's the same when /dev/cdrom or /cdrom comes up as a link to the real device. It doesn't matter, on which controller, port and id your drive is connected; it just works. The link comes up and step by step more applications using this.
And think about logical-volumes. Go backwards, because the admin will define on his own, which physical drive is used and mounted to a specific location? Logical volumes are present for ages in Novell Netware and other systems, arrived Windows since w2k and are working in linux for some years now.
Hi guys,
Sorry if I started a contentious discussion. I have looked into it a little more and found some useful information. There was a discussion on wine-devel about this topic back in March, which I had forgotten. You can find a summary in the Wine newsletter from that month:
http://www.winehq.org/?issue=265#Drive%20Management
What I had in mind was not to break the current system, but to allow an optional alternative method of mapping the drives, e.g. if you have
d: -> /mnt/cdrom d:: -> /dev/hdc
everything will work like now, and if you only have
d:: -> /dev/hdc
wine will figure out where hdc is mounted and map DOS to Unix filenames accordingly.
Looking at the code, though, that doesn't fit in very naturally with the way wine actually does things. What I hadn't understood is that the mapping of DOS to Unix filenames is purely an operation on strings, with no disk access needed: Q:\foo\bar is translated to ~/.wine/dosdevices/q:/foo/bar regardless of whether ~/.wine/dosdevices/q: points to anything meaningful or exists at all. This current system is very neat and simple, and doing anything different would mean introducing a significant amount of extra complication.
The other possibility is to have something in wineserver update the dosdevices symlinks when volumes are mounted. That would also be a significant amount of new stuff in wineserver.
Without doing anything to wine itself, there's one other option: set up a HAL front-end like ivman (http://ivman.sourceforge.net/) to update the dosdevices symlinks when volumes are mounted. This might be the right aswer. A distro like SuSE that wants to use HAL and have things mounted in different places can include ivman scripts in its wine package to automatically do the right thing with the dosdevices links, and then there's no problem. Or wine could check for ivman at the same time it creates .wine, and set up appropriate ivman scripts if it finds it.
- Walter
On Sun, 28 Aug 2005, Detlef Riekenberg wrote:
Am Samstag, den 27.08.2005, 14:38 -0700 schrieb Hiji:
It might be the ugly way, but it is the official way.
That's because many Applications are unable to handle it yet.
This is definately *not* a Wine issue because it affects any application which relies on have a static name for the drive - let's make sure we're clear on that. ;)
No! This is not only a Wine issue, it's an issue of all applications which relies on static names. The big mistake: The Volume-Label is optional.
It's possible on windows (since w2k) to work without a Driveletter for your CDROM, ("%SYSTEMROOT%\mountpoint") but they made the same mistake: Using a mountpoint (junction) is optional. When they used the mountpoint-method as default and the driveletter-method as optional fallback for old applications, then all important software would work today without an extra driveletter for removeable media.
It's time to be more flexible. freedesktop.org did a step in the direction, now the applications must follow!
I suspect this "mounting by volume label" won't last past Suse 9.3 since
.. and go backwards? No way!
I haven't read anyone praise this "feature" anywhere.
That's the same when /dev/cdrom or /cdrom comes up as a link to the real device. It doesn't matter, on which controller, port and id your drive is connected; it just works. The link comes up and step by step more applications using this.
And think about logical-volumes. Go backwards, because the admin will define on his own, which physical drive is used and mounted to a specific location? Logical volumes are present for ages in Novell Netware and other systems, arrived Windows since w2k and are working in linux for some years now.
-- By By ... ... Detlef
On 8/27/05, Walt Ogburn reuben@ugcs.caltech.edu wrote:
Hi guys,
Hi
The other possibility is to have something in wineserver update the dosdevices symlinks when volumes are mounted. That would also be a significant amount of new stuff in wineserver.
Without doing anything to wine itself, there's one other option: set up a HAL front-end like ivman (http://ivman.sourceforge.net/) to update the dosdevices symlinks when volumes are mounted. This might be the right aswer. A distro like SuSE that wants to use HAL and have things mounted in different places can include ivman scripts in its wine package to automatically do the right thing with the dosdevices links, and then there's no problem. Or wine could check for ivman at the same time it creates .wine, and set up appropriate ivman scripts if it finds it.
- Walter
I do agree better drive detection is needed, but I don't agree that the mount point should be found through the d:: type symlink. Better to have something like Ivman call out a wine helper script to read /etc/fstab and make the changes on the fly. Wineserver could check /etc/fstab on start up too. The check on start can be controlled by a setting. Drive letters that are created on the fly are temporary while wineserver is running. The drive letters set up through winecfg or ~/.wine/dosdevices are permament as long as the devices or filesystems do exist.
Ive seen this on the mailinglists once before about installing wine and windows binaries into wine once... amongst several users...
on smaller shared server setups this may be easier to achieve if there was some way to identify a single username/usergroup outside wine as "admin" equivalent within wine...
Im curious... would an /etc/wine existing with username/usergroup markings other than "root:root" for owner:group be usable for indicating a "common" install setup...
when "root" runs "winecfg" and also usable for "templating" when a user runs wine for themselves for the first time...
I know there are pet hates and things to like about any given software
but I am personally most irked by needing to fully install several copies of the same settings and program suite under each user...
just making a template and copying it all doesnt always work, (maybe I just deal with too many computer illiterate users...)
just wondering what if anything is in the current and mapped goals
Jeremy
Send instant messages to your online friends http://au.messenger.yahoo.com
On Sun, 28 Aug 2005 01:56:27 +0200, Walt Ogburn reuben@ugcs.caltech.edu wrote:
Hi guys, Sorry if I started a contentious discussion.
Contentious discussions can be fruitful but I dont see much contention here. It seems that although Detfel is a great fan of making directory names out of what are basically verbose textual labels, no-one else seems too keen at all.
There are too many special characters in text labels (not least of which is the space char) and the probable length of any label description makes it very unsuitable for part of a pathname.
As for suggesting all applications must rewritten to benefit from this amazing new feature: rediculous waste of effort.
I agree with the other poster, I think it is not likely to have a very long life-span. (If it does wine might have to start detecting SuSE on startup!)
What does seems to be a more persistant problem is USB devices which can have different device names every time they are plugged in, unless some very specific udev rules are written by hand.
It seems that wine would have to plug into hotplug events to do anything about this. But wine is not supposed to be a OS with-in an OS it is a compatability library for running windows software, so it seems a line has to be drawn between program functionality and system functions.
8)
-
Belxjander Serechai -
Detlef Riekenberg -
Jesse Allen -
peter＠piments.com -
Walt Ogburn