All, I am having some considerable problems dealing with a simple issue. In .wine/dosdevices, devices are listed followed by a colon like in dos. This makes perfect sense except that the colon is often used in UNIX to separate elements of a path description and has special meaning tto some programs. Under solaris this causes problems with the runtime loader which can't dlopen a filename containing a colon, and seems to be problematic for stat as well.
What is wrong with listing them without the colon so we don't risk these OS incompatibilities or perhaps adapt the code to accept the links with or without an appended colon.
Comments anyone ?
On Tue, 18 Apr 2006 22:38:11 +1000 Robert Lunnon bobl@optushome.com.au wrote:
All, I am having some considerable problems dealing with a simple issue. In .wine/dosdevices, devices are listed followed by a colon like in dos. This makes perfect sense except that the colon is often used in UNIX to separate elements of a path description and has special meaning tto some programs. Under solaris this causes problems with the runtime loader which can't dlopen a filename containing a colon, and seems to be problematic for stat as well.
What is wrong with listing them without the colon so we don't risk these OS incompatibilities or perhaps adapt the code to accept the links with or without an appended colon.
Comments anyone ?
I want to add that gdb under Darwin can't find such files under some conditions (thinking that : is a path separator).
-- Ph.
Robert Lunnon bobl@optushome.com.au writes:
All, I am having some considerable problems dealing with a simple issue. In .wine/dosdevices, devices are listed followed by a colon like in dos. This makes perfect sense except that the colon is often used in UNIX to separate elements of a path description and has special meaning tto some programs. Under solaris this causes problems with the runtime loader which can't dlopen a filename containing a colon, and seems to be problematic for stat as well.
What is wrong with listing them without the colon so we don't risk these OS incompatibilities or perhaps adapt the code to accept the links with or without an appended colon.
It could be changed, but there are some serious backwards compatibility issues. I think wrapping dlopen would be a lot easier, especially since we already have a wrapper for it.
On Wednesday 19 April 2006 04:26, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
All, I am having some considerable problems dealing with a simple issue. In .wine/dosdevices, devices are listed followed by a colon like in dos. This makes perfect sense except that the colon is often used in UNIX to separate elements of a path description and has special meaning tto some programs. Under solaris this causes problems with the runtime loader which can't dlopen a filename containing a colon, and seems to be problematic for stat as well.
What is wrong with listing them without the colon so we don't risk these OS incompatibilities or perhaps adapt the code to accept the links with or without an appended colon.
It could be changed, but there are some serious backwards compatibility issues. I think wrapping dlopen would be a lot easier, especially since we already have a wrapper for it.
This is the approach I took before but for some reason you didn't accept the patch in process.c related to starting unix lib type applications. The work-around was to change to the lib directory locate the pwd chdir back, then start the lib using the actual path.rather than the link. There may be another way to find the target directory of a link more elegantly but I don't know it. Anyway, I maintained this delta but it has now expired with the changes in process.c and need to be rewritten anyway.
While this course of action (eliminating the colon) is prone to some compatibility issues in the short term I think in the longer term it will enhance portability and compatibility and therefore reduce the maintenance cost of "dosdevices" going forward (And perhaps solve a few latent issues for non-linux OSen)
Bob
Robert Lunnon bobl@optushome.com.au writes:
This is the approach I took before but for some reason you didn't accept the patch in process.c related to starting unix lib type applications. The work-around was to change to the lib directory locate the pwd chdir back, then start the lib using the actual path.rather than the link. There may be another way to find the target directory of a link more elegantly but I don't know it. Anyway, I maintained this delta but it has now expired with the changes in process.c and need to be rewritten anyway.
realpath() should be a lot easier. And you really want to do that in wine_dlopen, process.c is not the only place that can load files from a DOS drive.
On Friday 21 April 2006 03:35, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
This is the approach I took before but for some reason you didn't accept the patch in process.c related to starting unix lib type applications. The work-around was to change to the lib directory locate the pwd chdir back, then start the lib using the actual path.rather than the link. There may be another way to find the target directory of a link more elegantly but I don't know it. Anyway, I maintained this delta but it has now expired with the changes in process.c and need to be rewritten anyway.
realpath() should be a lot easier. And you really want to do that in wine_dlopen, process.c is not the only place that can load files from a DOS drive.
Assuming this works, you say that other places load files cia a dos drive (and I see a mkdir across this link too) is there a key place to put the resolving code to catch these accesses too ?
(This is why I wanted to change the link name - all the unknown places where this link might need to be resolved)
Robert Lunnon bobl@optushome.com.au writes:
Assuming this works, you say that other places load files cia a dos drive (and I see a mkdir across this link too) is there a key place to put the resolving code to catch these accesses too ?
Do functions like mkdir really fail on these too? I was under the impression that it was only dlopen(). I can understand dlopen wanting to do strange things with the path, but I'd certainly expect raw system calls to be able to handle them properly.
-
Alexandre Julliard -
Phil Krylov -
Robert Lunnon