[Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

[Walt Ogburn]

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
>
>