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