Ok, I thing i got it now. You are asking for a configuration option in e.g. ~/.wine/config to enable or disable UNC support like this: yup...
A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.
Eric Pouech wrote:
Ok, I thing i got it now. You are asking for a configuration option in e.g. ~/.wine/config to enable or disable UNC support like this: yup...
Sorry I haven't had time to test the patch. I'm jazzed this is making progress. I agree with the other poster that this approach of reading /etc/mtab and looking for smbfs mounts is a complete kludge, but it is definitely the way to go for the near future. A real solution is going to be an intense amount of work, and I don't want to wait... As for .wine/config, I dunno how important configurability is; if they have the filesystem mounted, and a UNC reference to it comes in, seems like there's no reason not to use it; that's why the smbfs was mounted, isn't it? - Dan
Dan Kegel <dank(a)kegel.com> writes:
I agree with the other poster that this approach of reading /etc/mtab and looking for smbfs mounts is a complete kludge, but it is definitely the way to go for the near future.
I'm not so sure. If we depend on users having configured drives for the smbfs mounts, we might just as well ask them to configure UNC paths too, and avoid parsing /etc/mtab. For instance we could simply have something like: [Drive F] "Path" = "/mnt/whatever" "Server" = "foo" and then \\foo\x would mean the same thing as f:\x. This way you can also fake network mounts using the local filesystem. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Dan Kegel <dank(a)kegel.com> writes:
I agree with the other poster that this approach of reading /etc/mtab and looking for smbfs mounts is a complete kludge, but it is definitely the way to go for the near future.
I'm not so sure. If we depend on users having configured drives for the smbfs mounts, we might just as well ask them to configure UNC paths too, and avoid parsing /etc/mtab. For instance we could simply have something like:
[Drive F] "Path" = "/mnt/whatever" "Server" =
I assume you meant "Server" = "foo"
and then \\foo\x would mean the same thing as f:\x. This way you can also fake network mounts using the local filesystem.
I agree that faking network mounts is a good thing, but parsing mtab makes for much easier configuration. Instead of forcing the user to add a server field, wine can figure it out itself. Isn't that a good thing? Why force the user to enter in duplicate info? Dan
Dan Kegel <dank(a)kegel.com> writes:
I agree that faking network mounts is a good thing, but parsing mtab makes for much easier configuration. Instead of forcing the user to add a server field, wine can figure it out itself. Isn't that a good thing? Why force the user to enter in duplicate info?
Because you have to enter all the info for the drive configuration anyway. I agree doing everything dynamically would be better, but it's a lot more complex. An ugly hack to parse /etc/mtab just for smb mounts doesn't really seem better or easier to understand than having to put this info in the drive config. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Dan Kegel <dank(a)kegel.com> writes:
I agree that faking network mounts is a good thing, but parsing mtab makes for much easier configuration. Instead of forcing the user to add a server field, wine can figure it out itself. Isn't that a good thing? Why force the user to enter in duplicate info?
Because you have to enter all the info for the drive configuration anyway. I agree doing everything dynamically would be better, but it's a lot more complex. An ugly hack to parse /etc/mtab just for smb mounts doesn't really seem better or easier to understand than having to put this info in the drive config.
Just how terrible is parsing /etc/mtab? It doesn't look like much code. I'd be happy to provide a nice OO wrapper object for it if that would make you happier. It would then no longer be an ugly hack. Would that satisfy you? Or are you fundamentally opposed to it for some other reason than code clarity? And about ease of use. Consider my application: I wanted to run SourceSafe, so I set up a file in /etc/rc.d to perform the needed smbmount, edited .wine/config to map a drive letter to the mounted smb volume, and wrote a shell script to invoke sourcesafe. All is well except that the darn master ss.ini has a UNC in it that is used only at the very end of a checkin to log the activity; thus my checkins work, but aren't logged, which is eventually going to annoy my boss. With the UNC/mtab hack, things would magically start working properly. With your proposed change, I'd have to go into .wine/config *again* and enter in a duplicate copy of the server and share name, which would be annoying, especially if anything changed; maintaining duplicate info is a pain. Do you disagree? Perhaps you enjoy maintaining duplicate tables by hand? Now, I can imagine something that would make us both happy, namely for native Windows approaches to persistant drive letter mapping to actually work, getting rid of the need for editing .wine/config at all. But that's a lot of work; you'd need to link a userspace smb client into wineserver, I think. - Dan
Dan Kegel <dank(a)kegel.com> writes:
Just how terrible is parsing /etc/mtab? It doesn't look like much code. I'd be happy to provide a nice OO wrapper object for it if that would make you happier. It would then no longer be an ugly hack. Would that satisfy you? Or are you fundamentally opposed to it for some other reason than code clarity?
Code clarity is one thing (it should be probably using getmntent and friends), performance is another (parsing /etc/mtab on each CreateFile is *not* a good idea), but mainly I'm opposed to the concept of configuring everything by hand except magically getting smb shares through /etc/mtab, when they may not at all reflect what you want the Windows application to see. It doesn't fit in the current configuration philosophy. Now of course the config philosophy can be changed, but it must remain coherent.
With the UNC/mtab hack, things would magically start working properly. With your proposed change, I'd have to go into .wine/config *again* and enter in a duplicate copy of the server and share name, which would be annoying, especially if anything changed; maintaining duplicate info is a pain. Do you disagree?
I don't doubt it works just fine for your specific case; but it would make things a lot more mysterious and harder to understand. And it would require people who don't want Wine to access their shares to edit their config to prevent trouble. I think it's much better to require people who want it to make the minimal effort of adding a line in the config, instead of making people who don't want it do extra troubleshooting. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
but mainly I'm opposed to the concept of configuring everything by hand except magically getting smb shares through /etc/mtab, when they may not at all reflect what you want the Windows application to see.
OK, I give up. Go ahead and make a UNC hack that simply lets the user edit .wine/config to redirect UNC paths to particular local paths. It needn't even touch the drive letters, unless that makes it easier to implement. Whatever you do will help me run my application better than it runs currently. In the distant future, perhaps after release of wine 1.0, some more sophisticated approach to UNC paths and drive mappings can be tackled. - Dan
Alexandre Julliard wrote:
Dan Kegel <dank(a)kegel.com> writes:
Just how terrible is parsing /etc/mtab? It doesn't look like much code. I'd be happy to provide a nice OO wrapper object for it if that would make you happier. It would then no longer be an ugly hack. Would that satisfy you? Or are you fundamentally opposed to it for some other reason than code clarity?
Code clarity is one thing (it should be probably using getmntent and friends), performance is another (parsing /etc/mtab on each CreateFile is *not* a good idea), but mainly I'm opposed to the concept of configuring everything by hand except magically getting smb shares through /etc/mtab, when they may not at all reflect what you want the Windows application to see. It doesn't fit in the current configuration philosophy. Now of course the config philosophy can be changed, but it must remain coherent.
I don't doubt that we don't want to be parsing /etc/mtab on each CreateFile, but I will put in a word for some modifications to the configuration philosophy when it comes to drive letters. One of the problems we've come across recently is this: for games that use copy protection, we need to have direct access to the device that a CD-ROM drive uses. For the moment, this relys on the user to manually configure their drive letters. From what we've seen, doing so is beyond the ken of many of our users. As such, we've http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com
Alexandre Julliard wrote:
Dan Kegel <dank(a)kegel.com> writes:
Just how terrible is parsing /etc/mtab? It doesn't look like much code. I'd be happy to provide a nice OO wrapper object for it if that would make you happier. It would then no longer be an ugly hack. Would that satisfy you? Or are you fundamentally opposed to it for some other reason than code clarity?
Code clarity is one thing (it should be probably using getmntent and friends), performance is another (parsing /etc/mtab on each CreateFile is *not* a good idea), but mainly I'm opposed to the concept of configuring everything by hand except magically getting smb shares through /etc/mtab, when they may not at all reflect what you want the Windows application to see. It doesn't fit in the current configuration philosophy. Now of course the config philosophy can be changed, but it must remain coherent.
I don't doubt that we don't want to be parsing /etc/mtab on each CreateFile, but I will put in a word for some modifications to the configuration philosophy when it comes to drive letters. One of the problems we've come across recently is this: for games that use copy protection, we need to have direct access to the device that a CD-ROM drive uses. For the moment, this relys on the user to manually configure their drive letters. From what we've seen, doing so is beyond the ken of many of our users. As such, we've put together a scheme for parsing /etc/fstab on startup (not mtab: the drive may not be mounted), and automatically adding drive letters for each iso9660 filesystem listed. The patch (to the WineX tree) is here: http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ We're happy to contribute this in our next outward merge if people think it's useful. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com
As such, we've put together a scheme for parsing /etc/fstab on startup (not mtab: the drive may not be mounted), and automatically adding drive letters for each iso9660 filesystem listed. The patch (to the WineX tree) is here:
http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/
We're happy to contribute this in our next outward merge if people think it's useful.
Gavriel, Why do you only parse ISO9660? Many new games are coming out now in a DVD-ROM format which uses the UDF filesystem (if you mount it as ISO9660 then you can only use the 1st gigabyte).. How about improving the patch to include UDF parsing in /etc/fstab? -- Hetz Ben Hamo hetz(a)kde.org
Gavriel State <gav(a)transgaming.com> writes:
I don't doubt that we don't want to be parsing /etc/mtab on each CreateFile, but I will put in a word for some modifications to the configuration philosophy when it comes to drive letters.
Sure, I'm absolutely not opposed to that. It's clear that the current mechanism is not very user-friendly nor very flexible. The first thing to do would be to make it possible to change drive mappings at run-time, and then have them integrated as much as possible with the Unix environment, detecting all local filesystems, partition types, media changes, possibly even calling mount/umount from Wine, etc. What I want to avoid, and your patch is a good example of that, is the multiplication of ad-hoc hacks that solve a very specific problem without addressing the more global issue. Both your patch and Stefan's UNC patch contain pieces that will be part of the global solution; but they need to fit in a more general framework to be acceptable. -- Alexandre Julliard julliard(a)winehq.com
On Thu, 6 Dec 2001, Dan Kegel wrote:
Alexandre Julliard wrote:
and then \\foo\x would mean the same thing as f:\x. This way you can also fake network mounts using the local filesystem.
I agree that faking network mounts is a good thing, but parsing mtab makes for much easier configuration. Instead of forcing the user to add a server field, wine can figure it out itself. Isn't that a good thing? Why force the user to enter in duplicate info?
Dan
Why force the users to use samba to simulate UNC? Has Wine really any business to go crawling through mtab looking for resources it can make available to windows programs? Wineinstall can do this if it likes, and generate [Drive X] with "Server" =, and the Wine Administrator can change them if _it_ likes. I am more comfortable to believe Wine will only mess where I tell it it can mess. What IS UNC, anyway? :-/ Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
lawson_whitney(a)juno.com wrote:
On Thu, 6 Dec 2001, Dan Kegel wrote:
Alexandre Julliard wrote:
and then \\foo\x would mean the same thing as f:\x. This way you can also fake network mounts using the local filesystem.
I agree that faking network mounts is a good thing, but parsing mtab makes for much easier configuration. Instead of forcing the user to add a server field, wine can figure it out itself. Isn't that a good thing? Why force the user to enter in duplicate info?
Why force the users to use samba to simulate UNC? Has Wine really any business to go crawling through mtab looking for resources it can make available to windows programs?
Until Wine has smbclient code linked into it, and a way to set up persistant network drive mappings, I'm afraid there is no other choice.
Wineinstall can do this if it likes, and generate [Drive X] with "Server" =, and the Wine Administrator can change them if _it_ likes.
Unfortunately, this is something users should be able to do at any time, not just at install time.
I am more comfortable to believe Wine will only mess where I tell it it can mess.
Fine, you can turn the feature off. Note that you'd be silly to do so, since the feature I'm proposing only looks at directories already available to Wine programs, and would thus have very little chance of causing trouble.
What IS UNC, anyway? :-/
On the off chance you're serious, UNC stands for Universal Naming Convention, and it means the \\host\share\foo style of filenames one can use to avoid using network drive letters. - Dan
participants (6)
-
Alexandre Julliard -
Dan Kegel -
Eric Pouech -
Gavriel State -
Hetz Ben-Hamo -
lawson_whitney＠juno.com