When I operate with "c:\nonexist_subdir" and "c:\nonexist_subdir" filenames in Wine and in NT5, most of API functions set the same LastError. That functions are:
OpenFile() CreateFileA() SetCurrentDirectoryA() FindFirstFileA() GetFileAttributesA()
But if I call this: IShellFolder_ParseDisplayName(IDesktopFolder, NULL, NULL, cNonExistDirW, NULL, &newPIDL, 0)
then I get two different codes: * for the first one HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), * for the second one E_FAIL.
This is true for winME and win2k (and not for Wine).
Do we need to distinguish between these two filenames in Wine? If so, on top of what functions should it be implemented?
Do someone know, how native IShellFolder_ParseDisplayName works in the case of IDesktopFolder? I think the double-slash in the filename has something to do with object names, but I have no ground here.
* On Sat, 16 Jul 2005, Saulius Krasuckas wrote:
When I operate with "c:\nonexist_subdir" and "c:\nonexist_subdir"
...
then I get two different codes:
- for the first one HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND),
- for the second one E_FAIL.
...
Do someone know, how native IShellFolder_ParseDisplayName works in the case of IDesktopFolder? I think the double-slash in the filename has something to do with object names, but I have no ground here.
Hmm, I noticed calls with double backslashed filenames introduces large execution delays on winME. And as GLE is set to ERROR_BAD_NETPATH after a FindFirstFileA("c:\\nonexist", &WIN32_FIND_DATA) call in winME, now I think earlier mentioned difference may have something to do with UNC naming. If second filename somehow gets interpreted as refering to some servername, then I understand the reason of the delays.
Any ideas on how to should I change the last ok-check in the test [1]? It fails only on wine. Would todo_wine be appropriate here?
[1] http://www.winehq.org/hypermail/wine-patches/2005/06/0809.html
-
Saulius Krasuckas