On Fri, Apr 05, 2002 at 01:16:11PM -0500, Vincent Béron wrote:
Enrico Horn a écrit :
Hi
On Friday 05 April 2002 19:06, Andreas Mohr wrote:
On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote:
Hello!
Function CreateFileA get this file path (just for example):
C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lodAs you can see the correct path should be:
C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lodThis lead to error message "Can't initialize resources.Possible disk problem."
I see the problem in the function DOSFS_DoGetFullPathName(), which in the end removes the ending backslash from the path. The attached patch fixes it.
Bye, Martin
Yep, that might fix *your* problem, but don't you think that code snippet might have been there for a purpose ?
To find out this purpose was the purpose of my mail "DOSFS_DoGetFullPathName" I sent to this list more than a week ago. Until now no real answer has been given.
Are you sure that simply completely removing code doesn't break anything here in other cases ?
I cant think of any situation where this might be needed. I may be wrong though. Yet so far I have no explanation for this piece of code and removing it seems to work fine.
Enrico farmboy1@subdimension.com
I tracked it to a patch by Uwe Bonnes, around the 2000/04/28. It brought the dos_fs.c revision from 1.46 to 1.47. The CVS comment is: "DOSFS_DoGetFullPathName: rewrite to return resulta like OSR2".
Have you tried to run HOMAM III under OSR2? Or even just a call to the proper Win32 API? It might be just some different behaviours under different Windows falvours...
As to which of the two is what we want, I can't help you on that.
Actually GetFullPathName was known to have some trailing \ issue. So this had to be fixed somehow. It just astonished me a bit to see some code part completely removed instead of a "real" fix. But he said that he can't think of any occasion where it breaks, so it might be ok.
Probably a candidate for regression testing, though ;-)