[Bug 47169] New: Skyrim failed to load Data if Data directory is soft linked.
https://bugs.winehq.org/show_bug.cgi?id=47169 Bug ID: 47169 Summary: Skyrim failed to load Data if Data directory is soft linked. Product: Wine-staging Version: 4.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: l12436(a)yahoo.com.tw CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Since wine-staging 4.6, Skyrim will report all MOD is missing if Data directory is soft linked. I Tested the same modify that I commit in https://bugs.winehq.org/show_bug.cgi?id=47160. The notify is gone. I suspect is another BUG from Junction_Points. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 pattietreutel <katyaberezyaka(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #1 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- Hi TOM, Are you saying that the fix from Bug #47160 also fixes this problem or that even with that fix that you still have an issue? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #2 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #1)
Hi TOM,
Are you saying that the fix from Bug #47160 also fixes this problem or that even with that fix that you still have an issue?
With that fix, I still have this issue. I may try wine-staging fix latter. I have noiced an update in repo. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #3 from TOM <l12436(a)yahoo.com.tw> --- With commit 92cc7818b2d407ebde39a6b46ead47c0f79fce52 in wine-staging. Skyrim still notify all the mod file is missing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #4 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #3)
With commit 92cc7818b2d407ebde39a6b46ead47c0f79fce52 in wine-staging. Skyrim still notify all the mod file is missing.
Okay, thanks for the information. Are you sure that it stopped working in wine-staging 4.6? (the updated Junction Points patches were first introduced in 4.7) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #5 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #4)
(In reply to TOM from comment #3)
With commit 92cc7818b2d407ebde39a6b46ead47c0f79fce52 in wine-staging. Skyrim still notify all the mod file is missing.
Okay, thanks for the information. Are you sure that it stopped working in wine-staging 4.6? (the updated Junction Points patches were first introduced in 4.7)
My bad, I mean since 4.7 include 4.7. 4.6 is work version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #6 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #5)
(In reply to Erich E. Hoover from comment #4)
(In reply to TOM from comment #3)
With commit 92cc7818b2d407ebde39a6b46ead47c0f79fce52 in wine-staging. Skyrim still notify all the mod file is missing.
Okay, thanks for the information. Are you sure that it stopped working in wine-staging 4.6? (the updated Junction Points patches were first introduced in 4.7)
My bad, I mean since 4.7 include 4.7. 4.6 is work version.
No problem, this helps me know where to look. I will review the 4.7 changes and get back to you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #7 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #6)
(In reply to TOM from comment #5)
(In reply to Erich E. Hoover from comment #4)
(In reply to TOM from comment #3)
With commit 92cc7818b2d407ebde39a6b46ead47c0f79fce52 in wine-staging. Skyrim still notify all the mod file is missing.
Okay, thanks for the information. Are you sure that it stopped working in wine-staging 4.6? (the updated Junction Points patches were first introduced in 4.7)
My bad, I mean since 4.7 include 4.7. 4.6 is work version.
No problem, this helps me know where to look. I will review the 4.7 changes and get back to you.
Thanks for help. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #8 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #7)
(In reply to Erich E. Hoover from comment #6)
... No problem, this helps me know where to look. I will review the 4.7 changes and get back to you.
Thanks for help.
I am not seeing anything obvious, would you mind applying the junction point patches one at a time and seeing which one causes the program to break? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #9 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64489 --> https://bugs.winehq.org/attachment.cgi?id=64489 patch that fix the applying issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #10 from TOM <l12436(a)yahoo.com.tw> --- I suspect is the patch "ntdll-Junction_Points/0017-server-Properly-handle-file-symlink-deletion.patch". After applying "0017-server-Properly-handle-file-symlink-deletion.patch" and fix applying issue, The issue occur. But I need to fix the patch "server-File_Permissions/0002-server-Allow-to-open-files-without-any-permission-bi.patch" to apply "ntdll-Junction_Points/0017-server-Properly-handle-file-symlink-deletion.patch", I can not determine which cause this issue. I just know these two patch change cause this issue. The attachment is the way that I fix "0002-server-Allow-to-open-files-without-any-permission-bi.patch" just revert some change that cause issue. I hope this may help you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #11 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #10)
I suspect is the patch "ntdll-Junction_Points/0017-server-Properly-handle-file-symlink-deletion. patch". After applying "0017-server-Properly-handle-file-symlink-deletion.patch" and fix applying issue, The issue occur.
But I need to fix the patch "server-File_Permissions/0002-server-Allow-to-open-files-without-any- permission-bi.patch" to apply "ntdll-Junction_Points/0017-server-Properly-handle-file-symlink-deletion. patch", I can not determine which cause this issue. I just know these two patch change cause this issue.
The attachment is the way that I fix "0002-server-Allow-to-open-files-without-any-permission-bi.patch" just revert some change that cause issue.
I hope this may help you.
Yes, I am very surprised that that patch appears to be responsible for your issue. Would you please try replacing: lstat( fd->unix_name, &st ); with: fstat( fd->unix_fd, &st ); and see if that fixes the problem for you? (this change will break some of the reparse point behavior, but it is useful to know if it fixes your issue) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #12 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #11)
(In reply to TOM from comment #10)
I suspect is the patch "ntdll-Junction_Points/0017-server-Properly-handle-file-symlink-deletion. patch". After applying "0017-server-Properly-handle-file-symlink-deletion.patch" and fix applying issue, The issue occur.
But I need to fix the patch "server-File_Permissions/0002-server-Allow-to-open-files-without-any- permission-bi.patch" to apply "ntdll-Junction_Points/0017-server-Properly-handle-file-symlink-deletion. patch", I can not determine which cause this issue. I just know these two patch change cause this issue.
The attachment is the way that I fix "0002-server-Allow-to-open-files-without-any-permission-bi.patch" just revert some change that cause issue.
I hope this may help you.
Yes, I am very surprised that that patch appears to be responsible for your issue. Would you please try replacing: lstat( fd->unix_name, &st ); with: fstat( fd->unix_fd, &st ); and see if that fixes the problem for you? (this change will break some of the reparse point behavior, but it is useful to know if it fixes your issue)
After a quick test. It seems work. No warning now. I may make sure my test is correct. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #13 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #12)
(In reply to Erich E. Hoover from comment #11)
... Yes, I am very surprised that that patch appears to be responsible for your issue. Would you please try replacing: lstat( fd->unix_name, &st ); with: fstat( fd->unix_fd, &st ); and see if that fixes the problem for you? (this change will break some of the reparse point behavior, but it is useful to know if it fixes your issue)
After a quick test. It seems work. No warning now. I may make sure my test is correct.
If you go back to the lstat version does it break again? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #14 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #13)
(In reply to TOM from comment #12)
(In reply to Erich E. Hoover from comment #11)
... Yes, I am very surprised that that patch appears to be responsible for your issue. Would you please try replacing: lstat( fd->unix_name, &st ); with: fstat( fd->unix_fd, &st ); and see if that fixes the problem for you? (this change will break some of the reparse point behavior, but it is useful to know if it fixes your issue)
After a quick test. It seems work. No warning now. I may make sure my test is correct.
If you go back to the lstat version does it break again?
yes, change back to lstat, issue occur again. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #15 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #14)
... yes, change back to lstat, issue occur again.
Great, try replacing it with this: { int ret = lstat( fd->unix_name, &st ); if (ret == -1) fprintf(stderr, "'%s' '%s' %m\n", name, fd->unix_name); } and then run it and see what gets printed out. I am very curious as to what is happening here, since the exact cause will dictate the appropriate fix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #16 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64523 --> https://bugs.winehq.org/attachment.cgi?id=64523 stdout of fprintf log I did not see any actually print out. did I need to run wineserver manually ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #17 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #16)
Created attachment 64523 [details] stdout of fprintf log
I did not see any actually print out. did I need to run wineserver manually ?
That is very strange, you may need to kill the wineserver if it is already running - but it should print out if lstat failed. You might try having it print out unconditionally as a test (remove 'if (ret == -1)') to confirm that your change got included in the build. It is possible that lstat is not failing, but for some reason it is not returning the same result as fstat. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #18 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64531 --> https://bugs.winehq.org/attachment.cgi?id=64531 stdout of lstat and fstat I saw that lstat only test Data directory and nothing else. fstat still load the esp under the Data. fstat log is generated by only changing lstat( fd->unix_name, &st ); to fstat( fd->unix_fd, &st ); current code { fstat( fd->unix_fd, &st ); fprintf(stderr, "'%s' '%s' %m\n", name, fd->unix_name); } -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #19 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #17)
(In reply to TOM from comment #16)
Created attachment 64523 [details] stdout of fprintf log
I did not see any actually print out. did I need to run wineserver manually ?
That is very strange, you may need to kill the wineserver if it is already running - but it should print out if lstat failed. You might try having it print out unconditionally as a test (remove 'if (ret == -1)') to confirm that your change got included in the build. It is possible that lstat is not failing, but for some reason it is not returning the same result as fstat.
and I was wondering, %m did not need anything pass to it ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #20 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #18)
Created attachment 64531 [details] stdout of lstat and fstat
I saw that lstat only test Data directory and nothing else. fstat still load the esp under the Data. ...
There is a lot in these logs and I do not know what to look for (there are lots of Data directory printouts). Could you give me a line number or something to search for so that I can see exactly what you mean? I am very surprised that you get nothing when you compare the return value to -1 to restrict the fprintf to failed calls. (In reply to TOM from comment #19)
... and I was wondering, %m did not need anything pass to it ?
No, %m returns the human-readable error string for the current value of "errno". -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #21 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #20)
(In reply to TOM from comment #18)
Created attachment 64531 [details] stdout of lstat and fstat
I saw that lstat only test Data directory and nothing else. fstat still load the esp under the Data. ...
There is a lot in these logs and I do not know what to look for (there are lots of Data directory printouts). Could you give me a line number or something to search for so that I can see exactly what you mean? I am very surprised that you get nothing when you compare the return value to -1 to restrict the fprintf to failed calls.
I am also surprised that it did not return failed. Around 29753 in stdout-lstat and stdout-fstat which is get the state of "/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data". You will start saw the difference on lstat and fstat. With fstat(), Skyrim will also load the esm and esp under the Data. For some reason, lstat is skipping all the esm, esp under that directory.
(In reply to TOM from comment #19)
... and I was wondering, %m did not need anything pass to it ?
No, %m returns the human-readable error string for the current value of "errno".
OK, learn a lesson. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #22 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #21)
... I am also surprised that it did not return failed.
Around 29753 in stdout-lstat and stdout-fstat which is get the state of "/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data". You will start saw the difference on lstat and fstat. With fstat(), Skyrim will also load the esm and esp under the Data. For some reason, lstat is skipping all the esm, esp under that directory. ...
I have a thought. Try changing this (down from the lstat a little): unsigned int err; struct inode *inode = get_inode( st.st_dev, st.st_ino, fd->unix_fd ); int is_link = S_ISLNK(st.st_mode), is_dir; to this: int is_link = S_ISLNK(st.st_mode), is_dir; struct inode *inode; unsigned int err; fstat( fd->unix_fd, &st ); inode = get_inode( st.st_dev, st.st_ino, fd->unix_fd ); -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #23 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #22)
(In reply to TOM from comment #21)
... I am also surprised that it did not return failed.
Around 29753 in stdout-lstat and stdout-fstat which is get the state of "/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data". You will start saw the difference on lstat and fstat. With fstat(), Skyrim will also load the esm and esp under the Data. For some reason, lstat is skipping all the esm, esp under that directory. ...
I have a thought. Try changing this (down from the lstat a little): unsigned int err; struct inode *inode = get_inode( st.st_dev, st.st_ino, fd->unix_fd ); int is_link = S_ISLNK(st.st_mode), is_dir; to this: int is_link = S_ISLNK(st.st_mode), is_dir; struct inode *inode; unsigned int err; fstat( fd->unix_fd, &st ); inode = get_inode( st.st_dev, st.st_ino, fd->unix_fd );
nope, issue still occur. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #24 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #23)
... nope, issue still occur.
Darn, well - now we try to dig into what codepath it is taking in each case. Please try the following with both lstat and fstat: if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) fprintf(stderr, "Data mode: %06o\n", st.st_mode); (this should also reduce the spurious data in the log so we are mostly looking at what we want to see) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #25 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #24)
(In reply to TOM from comment #23)
... nope, issue still occur.
Darn, well - now we try to dig into what codepath it is taking in each case. Please try the following with both lstat and fstat: if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) fprintf(stderr, "Data mode: %06o\n", st.st_mode);
(this should also reduce the spurious data in the log so we are mostly looking at what we want to see)
ask one thing, the server/fd.c change only need to update wineserver binary ? although I have try replace other binary. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #26 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64532 --> https://bugs.winehq.org/attachment.cgi?id=64532 stdout of that game with modified fprintf. I change you code to. if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) { fprintf(stderr, "Path: '%s', Data mode: %06o\n", fd->unix_name, st.st_mode); } More clearly about what data mode belong to which path. I have notice one thing. In lstat Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Data mode: 120777 in fstat Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Data mode: 040755 different data mode. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #27 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64533 --> https://bugs.winehq.org/attachment.cgi?id=64533 Additional debug stdout. Search "/Data'," or around 99638 I have print most of the code sequence. after the lstat. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #28 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #26)
... More clearly about what data mode belong to which path.
Good call.
I have notice one thing. In lstat Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Data mode: 120777 in fstat Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Data mode: 040755
different data mode.
Yes, this is to be expected. The "040" prefix identifies it as a directory, where the "120" prefix identifies symbolic links. Both cases drop into the "grab the inode and do more" codepath (which is good, this is expected). I would say the next thing to check is what happens here: /* decode symlink type */ fstat( fd->unix_fd, &st ); is_dir = S_ISDIR(st.st_mode); So, after that I would put something like this: if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) { fprintf(stderr, "After Path: '%s', Data mode: %06o\n", fd->unix_name, st.st_mode); } -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #29 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64536 --> https://bugs.winehq.org/attachment.cgi?id=64536 stdout of that game. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #30 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #29)
Created attachment 64536 [details] stdout of that game.
Okay, so it is changing the mode correctly (see line 7371 in both files): After Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Data mode: 040755 Right before "/* check directory options */" would you please add?: if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) { fprintf(stderr, "Path: '%s', Mode: %06o, Dir?: %d, Options: %x\n", fd->unix_name, st.st_mode, is_dir, options); } -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|z.figura12(a)gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #31 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64538 --> https://bugs.winehq.org/attachment.cgi?id=64538 stdout of that game. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #32 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #31)
Created attachment 64538 [details] stdout of that game.
That is so weird, we see the same thing in both cases: Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Mode: 040755, Dir?: 1, Options: 21 I do not see how any of the error cases will get hit, would you mind putting something like this in each error case there (replace "A" with B/C/D/etc. for each one)?: if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) { fprintf(stderr, "A Path: '%s'\n", fd->unix_name); } -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #33 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #32)
(In reply to TOM from comment #31)
Created attachment 64538 [details] stdout of that game.
That is so weird, we see the same thing in both cases: Path: '/swap/wine/skyrim/dosdevices/d:/The.Elder.Scrolls.V.Skyrim/Data', Mode: 040755, Dir?: 1, Options: 21
I do not see how any of the error cases will get hit, would you mind putting something like this in each error case there (replace "A" with B/C/D/etc. for each one)?: if (strstr(fd->unix_name, "The.Elder.Scrolls.V.Skyrim/Data")) { fprintf(stderr, "A Path: '%s'\n", fd->unix_name); }
I have debug myself, I also did not see any error in it. very weird, but BUG still there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #34 from TOM <l12436(a)yahoo.com.tw> --- OK I accidiently found it. The "*mode" right after the lstat seems not re-assign to the mode that fstat return. If I add a "*mode = st.st_mode" right after the fstat, issue gone. Is that Intend to return the mode that lstat return or just a BUG? current code. /* decode symlink type */ fstat( fd->unix_fd, &st ); *mode = st.st_mode; -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #35 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to TOM from comment #34)
... The "*mode" right after the lstat seems not re-assign to the mode that fstat return.
If I add a "*mode = st.st_mode" right after the fstat, issue gone. Is that Intend to return the mode that lstat return or just a BUG? ...
Wow, clearly I totally missed that. The mode should be from the target, not from the link. I will get an update for this put together right away. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 --- Comment #36 from TOM <l12436(a)yahoo.com.tw> --- (In reply to Erich E. Hoover from comment #35)
(In reply to TOM from comment #34)
... The "*mode" right after the lstat seems not re-assign to the mode that fstat return.
If I add a "*mode = st.st_mode" right after the fstat, issue gone. Is that Intend to return the mode that lstat return or just a BUG? ...
Wow, clearly I totally missed that. The mode should be from the target, not from the link. I will get an update for this put together right away.
Thanks for the fix :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |eb91fab43e93ec9b939e67687a0 | |a52f69dee395d CC| |z.figura12(a)gmail.com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #37 from Zebediah Figura <z.figura12(a)gmail.com> --- Fixed by <https://github.com/wine-staging/wine-staging/commit/eb91fab43e93ec9b939e67687a0a52f69dee395d>. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47169 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #38 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closing Fixed wine-staging 4.9. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org