http://bugs.winehq.org/show_bug.cgi?id=15326
Summary: ntdll:NtCreateFile is not parsing the file create string correctly so fails Product: Wine Version: 1.1.4 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs@winehq.org ReportedBy: celticht32@aol.com
ntdll:NtCreateFile L"\??\D:\everquest\C%3A\Program%20Files\Sony\Station\LaunchPad\" not found (c000003a)
should actually be:
c:\Program Files\Sony\Station\LaunchPad\
not the above where it adds the execution directory in front of the string and it should translate %3A to : and %20 to < >
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #1 from chris ahrendt celticht32@aol.com 2008-09-18 20:09:27 --- this problem also effects :
NtQueryFullAttributesFile
as well
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #2 from Jeff Zaroyko jeffzaroyko@gmail.com 2008-09-18 20:44:48 --- Please provide full information when filing a bug report:
* What is the name of the application affected * Is the application available for download * What was the expected behaviour? What didn't work? * How can I reproduce the problem step by step
http://bugs.winehq.org/show_bug.cgi?id=15326
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |-unknown
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2008-09-19 10:08:35 --- My guess is this is a problem elsewhere, e.g. in shlwapi. The %20 and %3a look like URL escaping to me, and so something like UrlCanonicalize shoudl be removing these. You'll need a test case to prove this is indeed a problem in ntdll, but my guess is it's not.
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #4 from chris ahrendt celticht32@aol.com 2008-09-19 12:42:49 --- Well where I noticed it was when I was debugging another issue in everquest and had turned on +ntdll.
While rooting through the copious amounts of output I started seeing the pattern I opened this bug for..
The App is downloadable (trial version) on the web. All I did was start it up and let it run to get to the part I was debugging.
1. see above 2. See above 3. expected behavior see initial report should not have the web tags or the current directory where it is running from placed in front of the string. 4. Load the application turn +ntdll on and run it after installation. log into the launchpad and you should get the bug.
Chris
didn't debug it down to far as I am swamped working on another issue...
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #5 from Juan Lang juan_lang@yahoo.com 2008-09-19 21:18:38 --- Can you put the trial version download link in the URL field, then?
http://bugs.winehq.org/show_bug.cgi?id=15326
chris ahrendt celticht32@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://escapetonorrath.stati | |on.sony.com/
--- Comment #6 from chris ahrendt celticht32@aol.com 2008-09-19 21:21:31 --- here you go
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #7 from Lei Zhang thestig@google.com 2008-09-27 15:48:20 --- Does native shlwapi.dll help then?
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #8 from chris ahrendt celticht32@aol.com 2008-09-27 18:36:25 --- have not tried will try later on tonight if I get a chance...
chris
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #9 from chris ahrendt celticht32@aol.com 2008-09-30 19:49:22 --- Nope...
I/O warning : failed to load external entity "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml"
this is with the native dll. also with the native dll I get the attached exception as well.
Chris
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #10 from chris ahrendt celticht32@aol.com 2008-09-30 19:50:09 --- Created an attachment (id=16389) --> (http://bugs.winehq.org/attachment.cgi?id=16389) Exception when using native dll
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #11 from chris ahrendt celticht32@aol.com 2008-09-30 19:52:05 --- The attachment is with the dll set to native only... if I set to native and builtin I get the regular file error mentioned above and no exception.
chris
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #12 from chris ahrendt celticht32@aol.com 2008-09-30 19:52:51 --- Actually the exception just happened so only way to prevent exception is to not use native DLL.
http://bugs.winehq.org/show_bug.cgi?id=15326
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16389|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #13 from Austin English austinenglish@gmail.com 2009-03-30 13:15:03 --- Is this still an issue in current (1.1.18 or newer) wine?
--- Comment #14 from chris ahrendt celticht32@aol.com 2009-03-30 13:16:09 --- yes
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #15 from chris ahrendt celticht32@aol.com 2009-03-30 13:18:42 --- Current run and results showing string issue:
I/O warning : failed to load external entity "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml"
This is just one example
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #16 from chris ahrendt celticht32@aol.com 2009-04-18 20:24:31 --- Still occuring in the latest GIT Tree
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #17 from chris ahrendt celticht32@aol.com 2009-06-02 20:35:32 --- It looks like the first occurance of the parsing issue here occurs in :
trace:file:FindFirstFileExW L"C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" 0 0x99d438 0 (nil) 0 trace:file:RtlDosPathNameToNtPathName_U (L"C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml",0x99d3f0,0x99d3f8,(nil)) trace:file:RtlGetFullPathName_U (L"C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" 520 0x99d130 0x99d3f8) warn:file:wine_nt_to_unix_file_name L"C%3A\Program%20Files\Sony\Station\LaunchPad\" not found in /home/cahrendt/.wine/dosdevices/d:/everquest trace:file:RtlGetFullPathName_U (L"C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" 520 0x99d48c (nil))
Here is the file test Example which works under windows with the other file error:
#include <stdio.h> #include <stdlib.h>
// enumerated data type, SUCCESS = 0, FAIL = 1 enum {SUCCESS, FAIL};
int main(int argc, char* argv[]) { int c; int reval = SUCCESS;
// declare two file pointers... FILE *fptr1, *fptr2,*fptr3, *fptr4;
// define the file name... char filename1[] = "testone.txt"; char filename2[] = "testtwo.txt"; char filename3[] = "test\testtwo.txt"; char filename4[] = "Cfile:///C%3A/Program%20Files/testfour.txt";
if (!(fptr1 = fopen(filename1, "w"))) { printf("Problem, cannot open %s.\n", filename1); return FAIL; }
if (!(fptr2 = fopen(filename2, "r"))) { printf("Problem, cannot open %s.\n", filename2); return FAIL; }
if (!(fptr3 = fopen(filename3, "w"))) { printf("Problem, cannot open %s.\n", filename3); return FAIL; }
if (!(fptr4 = fopen(filename4, "w"))) { printf("Problem, cannot open %s.\n", filename4); return FAIL; }
printf("File Move test \n-----------------------------------------------------\n"); while ((c = fgetc(fptr2)) != EOF) { fputc(c, fptr1); fputc(c, fptr3); fputc(c, fptr4); putchar(c); } printf("\n"); printf("\n--------------------------------------------------------\n");
// close files... if (!fclose(fptr1)) printf("%s closed successfully\n", filename1); if (!fclose(fptr2)) printf("%s closed successfully\n", filename2); if (!fclose(fptr3)) printf("%s closed successfully\n", filename3); if (!fclose(fptr4)) printf("%s closed successfully\n", filename4);
return SUCCESS; }
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #18 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 22:40:24 --- Your test doesn't prove anything. Most likely the problem starts before the FindFirstFileExW() call. You need to figure out why escaped path has been passed to FindFirstFileExW(), and if that's really causing the failure, or just an application bug, and the problem is somewhere else.
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #19 from chris ahrendt celticht32@aol.com 2009-06-02 22:45:31 --- The test shows the problem with the file being
directory\file instead of c:\dir_level1\directory\file
on windows if you do a fopen on directory\file it opens the directory in the current execution directory and the file within that directory.. So if you are running the file in C:\student on windows it will look for the file c:\student\test\testthree.txt. In wine it does not work this way.
The other issue is a URI parsing issue with the open within kernel32.
The first time in the debug output with either +relay or +file that you see what looks to be a uri type file is in FindFirstFileExW. However the failure also occurs within WriteFile.
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #20 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 23:03:58 --- (In reply to comment #19)
The test shows the problem with the file being directory\file instead of c:\dir_level1\directory\file on windows if you do a fopen on directory\file it opens the directory in the current execution directory and the file within that directory.. So if you are running the file in C:\student on windows it will look for the file c:\student\test\testthree.txt. In wine it does not work this way.
I don't see how it's related to FindFirstFileExW() and fopen() in your test. Besides, fopen() is not a WinAPI, if you want to write a test - use the API sequence which leads to the problem.
The other issue is a URI parsing issue with the open within kernel32. The first time in the debug output with either +relay or +file that you see what looks to be a uri type file is in FindFirstFileExW. However the failure also occurs within WriteFile.
kernel32 is not supposed to know/parse URI names. As both Juan and me pointed out, you need to find out where it comes from.
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #21 from chris ahrendt celticht32@aol.com 2009-06-02 23:06:18 --- I'll track it down tomorrow...
The fopen like I said works on windows.. but will change it to the win32 api for fopen which calls fopen...
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #22 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 23:29:43 --- I've reread the whole bug, and I don't see whether there is a real problem you are trying to debug, or that's just a line in the +ntdll log which made you think that there is a problem somewhere in file APIs?
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #23 from chris ahrendt celticht32@aol.com 2009-06-03 09:15:20 --- There are a couple of problems I found:
first is this
"file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml"
which is the uri of the file. URI's seem not to be parsing correctly so the file is not found
Second:
If the application just does the following:
test\test.txt
windows assumes to take the current running directory and prepends that onto the location. So the above would look like this if the application was running in D:\test
D:\test\test\test.txt
I think the second has to do something with the way files in *nix are handled and might be in the convert to unix subroutine.
As juan knows I have to be careful what I do when debugging. I can not provide a fix for this as I am not allowed under several of my NDA's to do so.. So AJ asked that I just provide test cases.
This is an actual problem with an actual application (everquest 1 and 2 (or any of the sony applications)) while it does not seem to effect the application it still probably should not happen.
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #24 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-03 10:06:44 --- (In reply to comment #23)
There are a couple of problems I found: first is this "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" which is the uri of the file. URI's seem not to be parsing correctly so the file is not found
Again, where this does come from? Is that a real problem at all, or just an application bug?
Second: If the application just does the following: test\test.txt windows assumes to take the current running directory and prepends that onto the location. So the above would look like this if the application was running in D:\test D:\test\test\test.txt
It's supposed to work just fine in Wine.
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #25 from chris ahrendt celticht32@aol.com 2009-06-03 14:35:59 --- First one is the output from wine when running the application..
I am working on a windows w32 app to do the same thing should have it finished today sometime.
The second is again the output from wine when running the app as an error.
If you need I can attach the logs to show you...
chris
http://bugs.winehq.org/show_bug.cgi?id=15326
chris ahrendt celticht32@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16389|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #26 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-03 21:43:38 --- Comment #22 still applies, it's not clear at all what this bug is about. To me it looks like you saw a line a in the log, and assumed that it's a problem of some kind, am I right?
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #27 from chris ahrendt celticht32@aol.com 2009-06-03 22:03:42 --- saw the two lines in the wine log yes
http://bugs.winehq.org/show_bug.cgi?id=15326
--- Comment #28 from chris ahrendt celticht32@aol.com 2009-06-03 22:04:14 --- but the file was in the place where it thought it was
http://bugs.winehq.org/show_bug.cgi?id=15326
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #29 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-03 22:24:55 --- No real problem - invalid then.
http://bugs.winehq.org/show_bug.cgi?id=15326
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-03 22:25:32 --- If you have a real problem, or a test case - feel free to reopen.