[Bug 47160] New: wine-staging is unable to execute executable which is soft link in linux.
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(a)winehq.org Reporter: l12436(a)yahoo.com.tw CC: leslie_alistair(a)hotmail.com, z.figura12(a)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. -- 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=47160 --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Can you please state what version your using? -- 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=47160 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=47160 --- Comment #2 from TOM <l12436(a)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 -- 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=47160 --- Comment #3 from TOM <l12436(a)yahoo.com.tw> --- Currently using wine-staging 4.8. It just compiled today. -- 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=47160 --- Comment #4 from TOM <l12436(a)yahoo.com.tw> --- Sorry for spamming. I forget to say. I do not have such issue on vanilla wine. Only on wine-staging. -- 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=47160 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=47160 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.8 -- 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=47160 --- Comment #5 from TOM <l12436(a)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. -- 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=47160 --- Comment #6 from pattietreutel <katyaberezyaka(a)gmail.com> --- Please test with 992845eae729391b4ebd328205557f5ca8c70b89 staging commit. Seems commit 082a898ad4b267397cafaef1bcff0f86357f0cdf break symlinks. -- 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=47160 --- Comment #7 from TOM <l12436(a)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. -- 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=47160 --- Comment #8 from TOM <l12436(a)yahoo.com.tw> --- I can confirm 082a898ad4b267397cafaef1bcff0f86357f0cdf break the symlink. when I checkout to 992845eae729391b4ebd328205557f5ca8c70b89 everything is normal. checkout to 082a898ad4b267397cafaef1bcff0f86357f0cdf, symlink 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=47160 --- Comment #9 from Erich E. Hoover <erich.e.hoover(a)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 */ -- 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=47160 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- 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=47160 --- Comment #10 from TOM <l12436(a)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. -- 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=47160 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69(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=47160 Erich E. Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chopinbig(a)tutanota.com --- Comment #11 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- *** Bug 47252 has been marked as a duplicate of this bug. *** -- 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=47160 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |venemo(a)msn.com --- Comment #12 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 47253 has been marked as a duplicate of this bug. *** -- 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=47160 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |92cc7818b2d407ebde39a6b46ea | |d47c0f79fce52 Resolution|--- |FIXED --- Comment #13 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Fix from comment 9 was added in 92cc7818b2d407ebde39a6b46ead47c0f79fce52 Marking FIXED -- 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=47160 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 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.
https://bugs.winehq.org/show_bug.cgi?id=47160 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode(a)gmail.com --- Comment #15 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 47273 has been marked as a duplicate of this bug. *** -- 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=47160 Gabriel Ivăncescu <gabrielopcode(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|CLOSED |REOPENED Ever confirmed|0 |1 --- Comment #16 from Gabriel Ivăncescu <gabrielopcode(a)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. -- 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=47160 lle <llenort(a)aol.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |llenort(a)aol.com --- Comment #17 from lle <llenort(a)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 -- 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=47160 --- Comment #18 from TOM <l12436(a)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 -- 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=47160 --- Comment #19 from Gabriel Ivăncescu <gabrielopcode(a)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? -- 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=47160 --- Comment #20 from TOM <l12436(a)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. -- 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=47160 --- Comment #21 from TOM <l12436(a)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. -- 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=47160 --- Comment #22 from Erich E. Hoover <erich.e.hoover(a)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. -- 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=47160 --- 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)
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. -- 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=47160 --- Comment #24 from Erich E. Hoover <erich.e.hoover(a)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. -- 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=47160 --- Comment #25 from TOM <l12436(a)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: 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.
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. -- 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=47160 --- Comment #26 from Gabriel Ivăncescu <gabrielopcode(a)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? -- 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=47160 --- Comment #27 from TOM <l12436(a)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.
-- 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=47160 --- Comment #28 from Erich E. Hoover <erich.e.hoover(a)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. -- 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=47160 --- Comment #29 from TOM <l12436(a)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. -- 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=47160 --- Comment #30 from Erich E. Hoover <erich.e.hoover(a)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 -- 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=47160 --- Comment #31 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64591 --> https://bugs.winehq.org/attachment.cgi?id=64591 explorer screen shot. -- 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=47160 --- Comment #32 from TOM <l12436(a)yahoo.com.tw> --- Created attachment 64592 --> https://bugs.winehq.org/attachment.cgi?id=64592 screenshot of dir in cmd.exe -- 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=47160 --- Comment #33 from TOM <l12436(a)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. -- 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=47160 --- Comment #34 from Erich E. Hoover <erich.e.hoover(a)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." -- 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=47160 --- Comment #35 from Gabriel Ivăncescu <gabrielopcode(a)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. -- 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=47160 git(a)dougty.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |git(a)dougty.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=47160 --- Comment #36 from lle <llenort(a)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 -- 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=47160 --- Comment #37 from lle <llenort(a)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 -- 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=47160 Erich E. Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #38 from Erich E. Hoover <erich.e.hoover(a)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. -- 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=47160 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #39 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closed fixed staging bugs. -- 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