https://bugs.winehq.org/show_bug.cgi?id=47160
Bug ID: 47160 Summary: wine-staging is unable to execute executable which is soft link in linux. Product: Wine-staging Version: unspecified 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 recently wine-staging version, wine-staging is no longer able to successful recognize soft link directory or executable.
I have many directory is soft link to save disk space.
I can not found which patch cause this issue.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #1 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Can you please state what version your using?
https://bugs.winehq.org/show_bug.cgi?id=47160
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #2 from TOM l12436@yahoo.com.tw --- Created attachment 64392 --> https://bugs.winehq.org/attachment.cgi?id=64392 stdout for execute soft linked executable.
execute command.
WINEESYNC=0 WINEDEBUG=+all wine ./test.exe test.exe is linked for GLTest.exe
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #3 from TOM l12436@yahoo.com.tw --- Currently using wine-staging 4.8. It just compiled today.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #4 from TOM l12436@yahoo.com.tw --- Sorry for spamming. I forget to say. I do not have such issue on vanilla wine. Only on wine-staging.
https://bugs.winehq.org/show_bug.cgi?id=47160
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=47160
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.8
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #5 from TOM l12436@yahoo.com.tw --- Created attachment 64393 --> https://bugs.winehq.org/attachment.cgi?id=64393 Testing for fixing soft link issue
I disable part of Junction_Points, and the linking issue is gone.
This is the patch that I tested, and I manually fix the other patch for applying successfully.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #6 from pattietreutel katyaberezyaka@gmail.com --- Please test with 992845eae729391b4ebd328205557f5ca8c70b89 staging commit. Seems commit 082a898ad4b267397cafaef1bcff0f86357f0cdf break symlinks.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #7 from TOM l12436@yahoo.com.tw --- (In reply to pattietreutel from comment #6)
Please test with 992845eae729391b4ebd328205557f5ca8c70b89 staging commit. Seems commit 082a898ad4b267397cafaef1bcff0f86357f0cdf break symlinks.
OK, I will tested latter.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #8 from TOM l12436@yahoo.com.tw --- I can confirm 082a898ad4b267397cafaef1bcff0f86357f0cdf break the symlink. when I checkout to 992845eae729391b4ebd328205557f5ca8c70b89 everything is normal. checkout to 082a898ad4b267397cafaef1bcff0f86357f0cdf, symlink break.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #9 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to TOM from comment #8)
I can confirm 082a898ad4b267397cafaef1bcff0f86357f0cdf break the symlink. when I checkout to 992845eae729391b4ebd328205557f5ca8c70b89 everything is normal. checkout to 082a898ad4b267397cafaef1bcff0f86357f0cdf, symlink break.
If you have the chance, would you please update again and open dlls/ntdll/file.c:get_file_info and add: stat( path, st ); right before the line: /* symbolic links always report size 0 */
https://bugs.winehq.org/show_bug.cgi?id=47160
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #10 from TOM l12436@yahoo.com.tw --- (In reply to Erich E. Hoover from comment #9)
(In reply to TOM from comment #8)
I can confirm 082a898ad4b267397cafaef1bcff0f86357f0cdf break the symlink. when I checkout to 992845eae729391b4ebd328205557f5ca8c70b89 everything is normal. checkout to 082a898ad4b267397cafaef1bcff0f86357f0cdf, symlink break.
If you have the chance, would you please update again and open dlls/ntdll/file.c:get_file_info and add: stat( path, st ); right before the line: /* symbolic links always report size 0 */
Seems worked. symlink is work again. Thanks for help.
https://bugs.winehq.org/show_bug.cgi?id=47160
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47160
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chopinbig@tutanota.com
--- Comment #11 from Erich E. Hoover erich.e.hoover@gmail.com --- *** Bug 47252 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47160
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |venemo@msn.com
--- Comment #12 from Zebediah Figura z.figura12@gmail.com --- *** Bug 47253 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47160
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |92cc7818b2d407ebde39a6b46ea | |d47c0f79fce52 Resolution|--- |FIXED
--- Comment #13 from Gijs Vermeulen gijsvrm@gmail.com --- Fix from comment 9 was added in 92cc7818b2d407ebde39a6b46ead47c0f79fce52 Marking FIXED
https://bugs.winehq.org/show_bug.cgi?id=47160
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed wine-staging 4.9.
https://bugs.winehq.org/show_bug.cgi?id=47160
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com
--- Comment #15 from Zebediah Figura z.figura12@gmail.com --- *** Bug 47273 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47160
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|CLOSED |REOPENED Ever confirmed|0 |1
--- Comment #16 from Gabriel Ivăncescu gabrielopcode@gmail.com --- I'm posting here since it's duplicate of my original bug, though I'm not sure if it's 100% the same thing (let me know if I should file a new bug).
I've done more testing, and unfortunately it seems it's still a problem, so I'm reopening this bug. There still seems to be an issue with symlinks to files now, instead of directories. Make a Unix symlink to a .txt file and then you can't open it in wine's own notepad, it shows up as empty. Total Commander reports the file's size as 0 bytes and its Lister View displays it as empty as well.
Strangely, though, some other applications work when opening the file. This includes wine's own cmd 'type' command, so if you launch wine cmd and do 'type text.txt' on the symlink, it will display its contents.
https://bugs.winehq.org/show_bug.cgi?id=47160
lle llenort@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |llenort@aol.com
--- Comment #17 from lle llenort@aol.com --- Hello,
can confirm that wine-staging 4.9 breaks soft links to files. I wrote a script for a big game mod an use soft links to setup the game modes and starting with wine-staging 4.8 the game can't start.
Using winefile and try to start the game exe (hl.exe) a message window pop up and tell me that the file can't be checked.
It's a really strange behavior :-(
Thank for your support.
lle
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #18 from TOM l12436@yahoo.com.tw --- (In reply to Gabriel Ivăncescu from comment #16)
I'm posting here since it's duplicate of my original bug, though I'm not sure if it's 100% the same thing (let me know if I should file a new bug).
I've done more testing, and unfortunately it seems it's still a problem, so I'm reopening this bug. There still seems to be an issue with symlinks to files now, instead of directories. Make a Unix symlink to a .txt file and then you can't open it in wine's own notepad, it shows up as empty. Total Commander reports the file's size as 0 bytes and its Lister View displays it as empty as well.
Strangely, though, some other applications work when opening the file. This includes wine's own cmd 'type' command, so if you launch wine cmd and do 'type text.txt' on the symlink, it will display its contents.
It seems like another bug https://bugs.winehq.org/show_bug.cgi?id=47169 Although it is also fixed in wine-staging 4.9
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #19 from Gabriel Ivăncescu gabrielopcode@gmail.com --- That bug appears to be about symlinks to directories. Now I'm talking about symlinks to files. Did you try to make a symlink to a text file and open it in wine's notepad? Does it work for you with wine-staging-4.9?
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #20 from TOM l12436@yahoo.com.tw --- (In reply to Gabriel Ivăncescu from comment #19)
That bug appears to be about symlinks to directories. Now I'm talking about symlinks to files. Did you try to make a symlink to a text file and open it in wine's notepad? Does it work for you with wine-staging-4.9?
actually although it is symbol link to directory. but the BUG also happened on file can not read.
OK I saw it. file can not read through notepad.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #21 from TOM l12436@yahoo.com.tw --- found it.
/* return information about the destination (unless this is a dangling symlink) */ stat( path, st ); /* symbolic links always report size 0 */ st->st_size = 0; /* symbolic links (either junction points or NT symlinks) are "reparse points" */ *attr |= FILE_ATTRIBUTE_REPARSE_POINT;
This code "st->st_size = 0;" causing file being empty and can not read normally. Need develop of winehq to investigate.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #22 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to TOM from comment #21)
found it.
/* return information about the destination (unless this is a dangling symlink) */ stat( path, st ); /* symbolic links always report size 0 */ st->st_size = 0; /* symbolic links (either junction points or NT symlinks) are "reparse points" */ *attr |= FILE_ATTRIBUTE_REPARSE_POINT;
This code "st->st_size = 0;" causing file being empty and can not read normally. Need develop of winehq to investigate.
Interesting, that was added specifically to fix some failing tests in msvcp. It may be that this behavior is dependent upon something else, but I will have to investigate and get back to you.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #23 from TOM l12436@yahoo.com.tw --- (In reply to Erich E. Hoover from comment #22)
(In reply to TOM from comment #21)
found it.
/* return information about the destination (unless this is a dangling symlink) */ stat( path, st ); /* symbolic links always report size 0 */ st->st_size = 0; /* symbolic links (either junction points or NT symlinks) are "reparse points" */ *attr |= FILE_ATTRIBUTE_REPARSE_POINT;
This code "st->st_size = 0;" causing file being empty and can not read normally. Need develop of winehq to investigate.
Interesting, that was added specifically to fix some failing tests in msvcp. It may be that this behavior is dependent upon something else, but I will have to investigate and get back to you.
Thanks for your investigate. I think this may cause many program work abnormal.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #24 from Erich E. Hoover erich.e.hoover@gmail.com --- Ok, this is rather complicated - but can be simplified down to two cases: 1) some functions return the characteristics of the target (GetFileSize) 2) some functions return the characteristics of the link (GetFileAttributesEx)
In my attempt to fix case #2, I inadvertently broke case #1 because I did not realize that GetFileSize was a situation of case #1.
So, if you would not mind - please revert ntdll-Junction_Points/0015-ntdll-Correctly-report-fd-based-file-info-for-symlin.patch and see if this fixes your problem. If it does then I'll get together an updated version of the patches with more tests for this edge case.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #25 from TOM l12436@yahoo.com.tw --- (In reply to Erich E. Hoover from comment #24)
Ok, this is rather complicated - but can be simplified down to two cases:
- some functions return the characteristics of the target (GetFileSize)
- some functions return the characteristics of the link
(GetFileAttributesEx)
In my attempt to fix case #2, I inadvertently broke case #1 because I did not realize that GetFileSize was a situation of case #1.
So, if you would not mind - please revert ntdll-Junction_Points/0015-ntdll-Correctly-report-fd-based-file-info-for- symlin.patch and see if this fixes your problem. If it does then I'll get together an updated version of the patches with more tests for this edge case.
YEP, It work with 0015-ntdll-Correctly-report-fd-based-file-info-for-symlin.patch not applied, but I need to fix 0003-ntdll-Implement-storing-DOS-attributes-in-NtSetInfor.patch to make sure wine-staging apply successfully.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #26 from Gabriel Ivăncescu gabrielopcode@gmail.com --- I can confirm reverting that patch allows notepad (and other apps) to open the symlink files. However, the size is still reported as zero, is this intended?
I'm guessing it's the case on Windows, so technically it's more correct to return 0, though having "invisible" file symlinks was pretty nice. Hopefully it won't break anything though (if apps rely on the file size). And I guess it's needed to match Windows behavior.
Still wondering if it's possible to only apply this "Windows-correct" behavior on specially encoded symlinks (i.e. those created from within wine itself, not outside of it) and keep reporting the file's size as before otherwise. Would that be too much of a burden?
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #27 from TOM l12436@yahoo.com.tw --- I can confirm this, Still need this modify to make sure it return correct size.
(In reply to TOM from comment #21)
found it.
/* return information about the destination (unless this is a dangling symlink) */ stat( path, st ); /* symbolic links always report size 0 */ st->st_size = 0; /* symbolic links (either junction points or NT symlinks) are "reparse points" */ *attr |= FILE_ATTRIBUTE_REPARSE_POINT;
This code "st->st_size = 0;" causing file being empty and can not read normally. Need develop of winehq to investigate.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #28 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Gabriel Ivăncescu from comment #26)
I can confirm reverting that patch allows notepad (and other apps) to open the symlink files. However, the size is still reported as zero, is this intended?
I'm guessing it's the case on Windows, so technically it's more correct to return 0, though having "invisible" file symlinks was pretty nice. Hopefully it won't break anything though (if apps rely on the file size). And I guess it's needed to match Windows behavior.
Still wondering if it's possible to only apply this "Windows-correct" behavior on specially encoded symlinks (i.e. those created from within wine itself, not outside of it) and keep reporting the file's size as before otherwise. Would that be too much of a burden?
How are you seeing a file size of zero? The correct behavior is to report the target size for certain functions (GetFileSize) but to report the "link size" (0) for other functions (GetFileAttributesEx) or if you open the file with FILE_FLAG_OPEN_REPARSE_POINT. This is just like how on Linux you will see the size of the target under normal circumstances and see the "link size" only if you use special functions (lstat) or open the file with O_NOFOLLOW|O_PATH.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #29 from TOM l12436@yahoo.com.tw --- (In reply to Erich E. Hoover from comment #28)
(In reply to Gabriel Ivăncescu from comment #26)
I can confirm reverting that patch allows notepad (and other apps) to open the symlink files. However, the size is still reported as zero, is this intended?
I'm guessing it's the case on Windows, so technically it's more correct to return 0, though having "invisible" file symlinks was pretty nice. Hopefully it won't break anything though (if apps rely on the file size). And I guess it's needed to match Windows behavior.
Still wondering if it's possible to only apply this "Windows-correct" behavior on specially encoded symlinks (i.e. those created from within wine itself, not outside of it) and keep reporting the file's size as before otherwise. Would that be too much of a burden?
How are you seeing a file size of zero? The correct behavior is to report the target size for certain functions (GetFileSize) but to report the "link size" (0) for other functions (GetFileAttributesEx) or if you open the file with FILE_FLAG_OPEN_REPARSE_POINT. This is just like how on Linux you will see the size of the target under normal circumstances and see the "link size" only if you use special functions (lstat) or open the file with O_NOFOLLOW|O_PATH.
command: "wine cmd /c dir" you will see the file that linked report size 0.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #30 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to TOM from comment #29)
... command: "wine cmd /c dir" you will see the file that linked report size 0.
That sounds like a bug in wine's cmd, as it should not show a size at all for symlinks: https://ipggi.files.wordpress.com/2009/09/windows-symbolic-links3.png?w=663
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #31 from TOM l12436@yahoo.com.tw --- Created attachment 64591 --> https://bugs.winehq.org/attachment.cgi?id=64591 explorer screen shot.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #32 from TOM l12436@yahoo.com.tw --- Created attachment 64592 --> https://bugs.winehq.org/attachment.cgi?id=64592 screenshot of dir in cmd.exe
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #33 from TOM l12436@yahoo.com.tw --- (In reply to Erich E. Hoover from comment #30)
(In reply to TOM from comment #29)
... command: "wine cmd /c dir" you will see the file that linked report size 0.
That sounds like a bug in wine's cmd, as it should not show a size at all for symlinks: https://ipggi.files.wordpress.com/2009/09/windows-symbolic-links3.png?w=663
OK, I saw it. explorer show correct size. but cmd dir show zero.
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #34 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to TOM from comment #33)
... OK, I saw it. explorer show correct size. but cmd dir show zero.
At some point we'll need to update wine cmd - it currently only shows <DIR>, it should also report <SYMLINK>, <SYMLINKD>, and <JUNCTION>. The way this works should not break any existing programs, since this reporting is specific to the way that FindFirstFile/FindNextFile works for symlinks, from MSDN: "If the path points to a symbolic link, the WIN32_FIND_DATA buffer contains information about the symbolic link, not the target."
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #35 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Yeah, it reports size 0 in file managers like Total Commander, presumably because they do use FindFirstFile/FindNextFile to enumerate the directory contents. I know that it's Windows behavior to do this, and I'm not aware if any app actually breaks when using symlinks yourself (except well, having the "wrong" size reported in file managers).
Would it be too much of a burden to keep raw unix symlinks like before, and encoding Windows symlinks specially? (like it's done for Junctions I believe). It's a fairly minor thing though, so just wondering if it's an easy change.
Obviously, this patchset's behavior must be enabled for Wine-created symlinks since it's what apps would expect. Unix symlinks, on the other hand, are just convenience and shouldn't matter if they are not shown as such to windows apps.
https://bugs.winehq.org/show_bug.cgi?id=47160
git@dougty.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |git@dougty.com
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #36 from lle llenort@aol.com --- I totally agree. Linux symlinks to files an even to directories must be invisible to the windows SW in wine. The windows treatment of symlinks are important for windows SW created symlinks only.
I think this will be the best choice. The rework will result in better windows SW compatibility.
all the Best... lle
https://bugs.winehq.org/show_bug.cgi?id=47160
--- Comment #37 from lle llenort@aol.com --- Hello, thanks for fixing this in wine-staging 4.10. Everything works for my Mod. The links to directories and to executable programs.
Again... many thanks to all of you geniuses.. you are the Best of Bests :-)
lle
https://bugs.winehq.org/show_bug.cgi?id=47160
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #38 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to lle from comment #37)
Hello, thanks for fixing this in wine-staging 4.10. Everything works for my Mod. The links to directories and to executable programs.
Again... many thanks to all of you geniuses.. you are the Best of Bests :-)
lle
Awesome, thanks for letting me know.
https://bugs.winehq.org/show_bug.cgi?id=47160
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #39 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closed fixed staging bugs.