http://bugs.winehq.org/show_bug.cgi?id=7102
------- Additional Comments From felix.huber@schyf.de 2007-13-01 04:13 ------- The problem visible to the user is that whenever Winword6 is trying to check for the NON-existence of a file or path, the console where wine was started from shows the error message
fixme:int21:INT21_GetExtendedError Unknown error 123
where actually nothing is wrong. After that, the creation and removal of temporary files is undetermined. I was able to track the cause for this behaviour upto the ntdll and back:
1) Application calls GetFileAttributes with a non-existing path 2) The call is processed in int21.c and forwarded to ntdll 3) ntdll calls the linux function to check for the path requested 4) ntdll returns the internal error code 0xC0000033 5) This error code is mapped to the non-existing DOS/WIN error number 123 6) GetFileAttributes returns this error 123 to the application
... internal application processing
7) Application calls INT21_GetExtendedError 8) int21.c doesn't know this error number and generates the fixme:message
So the problem is that ntdll uses an error code that int21 doesn't know about. In my view, all the error numbers within the WINE functions should be consistent. I would have sent in a patch, but I was not sure which was the place:
1) Change ntdll to return 0xC0000034 (file not found) instead of 0xC0000033 (invalid name) 2) Create a special case in GetFileAttributes to catch error 123 and map it to DOS/WIN errror 2 (file not found) 3) Update INT21_GetExtendedError to map error 123 to error 2.
Option 3 would have the smallest side effect, however, the non-existing DOS/WIN error code 123 would still be visible to the application when GetFileAttributes returns.