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@winehq.org Reporter: l12436@yahoo.com.tw CC: leslie_alistair@hotmail.com, z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47169
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #1 from Erich E. Hoover erich.e.hoover@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?
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #2 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #3 from TOM l12436@yahoo.com.tw --- With commit 92cc7818b2d407ebde39a6b46ead47c0f79fce52 in wine-staging. Skyrim still notify all the mod file is missing.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #4 from Erich E. Hoover erich.e.hoover@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)
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #5 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #6 from Erich E. Hoover erich.e.hoover@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #7 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #8 from Erich E. Hoover erich.e.hoover@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?
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #9 from TOM l12436@yahoo.com.tw --- Created attachment 64489 --> https://bugs.winehq.org/attachment.cgi?id=64489 patch that fix the applying issue.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #10 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #11 from Erich E. Hoover erich.e.hoover@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)
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #12 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #13 from Erich E. Hoover erich.e.hoover@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?
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #14 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #15 from Erich E. Hoover erich.e.hoover@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #16 from TOM l12436@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 ?
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #17 from Erich E. Hoover erich.e.hoover@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #18 from TOM l12436@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); }
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #19 from TOM l12436@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 ?
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #20 from Erich E. Hoover erich.e.hoover@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".
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #21 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #22 from Erich E. Hoover erich.e.hoover@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 );
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #23 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #24 from Erich E. Hoover erich.e.hoover@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)
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #25 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #26 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #27 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #28 from Erich E. Hoover erich.e.hoover@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); }
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #29 from TOM l12436@yahoo.com.tw --- Created attachment 64536 --> https://bugs.winehq.org/attachment.cgi?id=64536 stdout of that game.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #30 from Erich E. Hoover erich.e.hoover@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); }
https://bugs.winehq.org/show_bug.cgi?id=47169
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|z.figura12@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #31 from TOM l12436@yahoo.com.tw --- Created attachment 64538 --> https://bugs.winehq.org/attachment.cgi?id=64538 stdout of that game.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #32 from Erich E. Hoover erich.e.hoover@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); }
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #33 from TOM l12436@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #34 from TOM l12436@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;
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #35 from Erich E. Hoover erich.e.hoover@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.
https://bugs.winehq.org/show_bug.cgi?id=47169
--- Comment #36 from TOM l12436@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 :)
https://bugs.winehq.org/show_bug.cgi?id=47169
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |eb91fab43e93ec9b939e67687a0 | |a52f69dee395d CC| |z.figura12@gmail.com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #37 from Zebediah Figura z.figura12@gmail.com --- Fixed by https://github.com/wine-staging/wine-staging/commit/eb91fab43e93ec9b939e67687a0a52f69dee395d.
https://bugs.winehq.org/show_bug.cgi?id=47169
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #38 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed wine-staging 4.9.