"Michael" == Michael Wetherell mike.wetherell@ntlworld.com writes:
Michael> On Friday 14 Jun 2002 6:20 pm, Uwe Bonnes wrote: >> some application (xilinx webpack) dind't find it's initialisation >> file when started in the debugger ("winedbg bin/nt/webpack.exe" >> versus "wine bin/nt/exepack" started in "l:/xilinx"). As trap there >> is also a directory "l:/xilinx/xilinx". The starting process (wine or >> winedbg) set the current working directory to l: and when winedbg >> started the user process, DRIVE_Chdir in DIR_Init set the current >> directory to "l:/xilinx/xilinx". This was caused by >> DRIVE_FindDriveRoot not returning an absolute path.
Michael> I'm sorry about that, I should have forseen it. Your patch does Michael> of course fix it (and that's how it was before) but I think it Michael> might be better to make the change to DIR_Init() instead Michael> though.
That's what my first try was. However I thought fixing the (perceived) root of the problem was better.
Michael> I think the trouble with trying to return the leading slash in Michael> the result of DRIVE_FindDriveRoot() is that whether you get an Michael> absolute or relative path depends on whether we are at a Michael> drive's root or not, rather than whether the input unix path is Michael> absolute or not.
Michael> So since DRIVE_FindDriveRoot() can't always do it correctly I Michael> think it would probably be better if it didn't do it at all, Michael> that way the caller knows they have to deal with it rather than Michael> it working some of the time, but other times giving rise subtle Michael> problems.
I find only two calls to DRIVE_FindDriveRoot("find -type f -name *.c |xargs grep DRIVE_FindDriveRoot") and in both cases we have an absolute path ( returned from cwd() or checked for a slash as the first character). So I think we can live with DRIVE_FindDriveRoot being imperfect, as long as long as with return a leading slash. But if you have a better solution, please let me test.
Bye