[Bug 50770] New: Unable to create symlinks to files in a nonexistent directory
https://bugs.winehq.org/show_bug.cgi?id=50770 Bug ID: 50770 Summary: Unable to create symlinks to files in a nonexistent directory Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: martin(a)martin.st CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 69562 --> https://bugs.winehq.org/attachment.cgi?id=69562 Testcase Creating a symlink pointing to a file that doesn't exist, succeeds as it should, e.g. CreateSymbolicLinkA("link", "nonexistentfile") succeeds. However, CreateSymbolicLinkA("link", "nonexistentdir\\nonexistentfile") fails. -- 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=50770 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.3 -- 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=50770 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #1 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Maybe related to bug 50766 (Use of non-null terminated string returned by readlink() breaks symlinks handling) Regards. -- 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=50770 --- Comment #2 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- Thanks Martin, this should be fixed by staging commit 89c049ee68fdbbd4854a3dd2df03c9562bd0c085. Would you mind double checking when you have a chance? -- 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=50770 --- Comment #3 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #2)
Thanks Martin, this should be fixed by staging commit 89c049ee68fdbbd4854a3dd2df03c9562bd0c085. Would you mind double checking when you have a chance?
Yes, the aspect of creating the symlinks is fixed, thanks! This testcase still showcases a different issue, though. These symlinks to a directory can't be removed with DeleteFile on real windows (doing that results in an "Access is denied." error) - but DeleteFile works on wine. Therefore the testcase uses RemoveDirectory to remove directory symlinks, but this produces errors (Directory name invalid.) on wine instead. -- 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=50770 --- Comment #4 from Hans Leidekker <hans(a)meelstraat.net> --- So NT symlinks come in two flavors, file symlinks and directory symlinks, and to remove them you need to use DeleteFile and RemoveDirectory respectively. This means we need to know the symlink type. We can't take it from the target because it may not exist, which suggests it should be encoded in the symlink itself. -- 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=50770 --- Comment #5 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Hans Leidekker from comment #4)
So NT symlinks come in two flavors, file symlinks and directory symlinks, and to remove them you need to use DeleteFile and RemoveDirectory respectively.
This means we need to know the symlink type. We can't take it from the target because it may not exist, which suggests it should be encoded in the symlink itself.
Yes, that's correct. I already have the target type encoded in the symlink, but at the moment it infers it from the type of the target: https://github.com/wine-staging/wine-staging/blob/a11594e19e035f3184ab46a04e... The reason for that is that I don't know how to convert SYMBOLIC_LINK_FLAG_DIRECTORY into a flag/option/whatever for the reparse point, as that's not in the documentation: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/b41f1cb... I used to have it use the information from the opened handle, but I discovered looking into this that that either stopped working or that I had incorrectly believed that it was working before: https://github.com/wine-staging/wine-staging/blob/a2ca43d98b3a45ae3bd66e8c71... Hopefully this is something simple and I'm just not seeing it at the moment, any thoughts? -- 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=50770 --- Comment #6 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Erich E. Hoover from comment #5)
... Hopefully this is something simple and I'm just not seeing it at the moment, any thoughts?
*ugh* The reason this "broke" is that my test script the other day was incorrect. What I had before works perfectly and I failed to pass "/d" to my mklink call. -- 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=50770 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Erich E. Hoover from comment #6)
(In reply to Erich E. Hoover from comment #5)
... Hopefully this is something simple and I'm just not seeing it at the moment, any thoughts?
*ugh* The reason this "broke" is that my test script the other day was incorrect. What I had before works perfectly and I failed to pass "/d" to my mklink call.
Right, but this also means that if you report Unix symlinks as NT symlinks you don't know what type they are when the target doesn't exist. -- 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=50770 --- Comment #8 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Hans Leidekker from comment #7)
... Right, but this also means that if you report Unix symlinks as NT symlinks you don't know what type they are when the target doesn't exist.
That's correct, right now I'm treating dangling unix symlinks as files: https://github.com/wine-staging/wine-staging/blob/3790a7051055e36ef8112c1b0b... However, for symlinks an application didn't create itself they have to check whether they're a file or a directory before deleting them (so as long as we treat them consistently on our end then this will work correctly). You only run into problems with file/directory symlinks when an application creates them a certain way and assumes they stayed that way (doesn't check what type they are before deleting). -- 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=50770 --- Comment #9 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #8)
(In reply to Hans Leidekker from comment #7)
... Right, but this also means that if you report Unix symlinks as NT symlinks you don't know what type they are when the target doesn't exist.
That's correct, right now I'm treating dangling unix symlinks as files: https://github.com/wine-staging/wine-staging/blob/ 3790a7051055e36ef8112c1b0b5e111e0ee7a0ab/patches/ntdll-Junction_Points/0035- ntdll-Treat-undecoded-unix-symlinks-as-NT-symlinks.patch#L91
However, for symlinks an application didn't create itself they have to check whether they're a file or a directory before deleting them (so as long as we treat them consistently on our end then this will work correctly). You only run into problems with file/directory symlinks when an application creates them a certain way and assumes they stayed that way (doesn't check what type they are before deleting).
Right, as long as this only is an issue with dangling symlinks, it might not be that big an issue... And a file/dir/symlink agnostic way of deleting things, CreateFile(path, DELETE, FILE_FLAG_OPEN_REPARSE_POINT), SetFileInformationByHandle(FileDispositionInfo, FILE_DISPOSITION_INFO::DeleteFile = TRUE), should work in either 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=50770 --- Comment #10 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- This should be fixed by staging commit 186c17f4542efb2be15a61138677418c672506a8, if you wouldn't mind checking then I would appreciate 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=50770 --- Comment #11 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #10)
This should be fixed by staging commit 186c17f4542efb2be15a61138677418c672506a8, if you wouldn't mind checking then I would appreciate it.
That particular issue seems to be fixed now too, thanks! However further testing regarding creating symlinks that point at files in a nonexistent directory shows further issues. It seems to work if creating a symlink pointing at e.g. "nonexistentdir\file", but not there's more than one nonexistent directory involved, e.g. creating one pointing at "nonexistent\dir\file" (or another nonexistent target exercised by the testsuites is "C:/This/Path/Should/Not/Exist"). A quick modification to the attached testcase shows these issues. -- 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=50770 --- Comment #12 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- This should now (hopefully) be fully fixed by staging commit 8e5c8cc63b57dbe9b2cf2ff075c12648845b22fa. -- 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=50770 --- Comment #13 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #12)
This should now (hopefully) be fully fixed by staging commit 8e5c8cc63b57dbe9b2cf2ff075c12648845b22fa.
Thanks! I can confirm that those cases are fixed now - however a different case has broken: Now creating a symlink with a target path like "../file" fails (even though it should succeed, regardless of whether the file "../file" relative to the link exists or not). -- 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=50770 --- Comment #14 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- Created attachment 70074 --> https://bugs.winehq.org/attachment.cgi?id=70074 Fix relative path issue (In reply to Martin Storsjö from comment #13)
(In reply to Erich E. Hoover from comment #12)
This should now (hopefully) be fully fixed by staging commit 8e5c8cc63b57dbe9b2cf2ff075c12648845b22fa.
Thanks! I can confirm that those cases are fixed now - however a different case has broken: Now creating a symlink with a target path like "../file" fails (even though it should succeed, regardless of whether the file "../file" relative to the link exists or not).
After investigating this a little bit, this relative symlink issue is actually a new issue due to an upstream change in commit 405666b736f7e471e301f051cfbe68bcbef7e0f6. This commit changes the way that lookup_unix_name converts NT names to unix names and it now fails on relative paths. I'm looking into the best way to fix this (not sure if I should be using another routine or adding a flag, but either way I'll try to get a fix out in short order. I've attached one way to fix it (flag for lookup_unix_name), if you would like to give it a try. -- 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=50770 --- Comment #15 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #14)
Created attachment 70074 [details] Fix relative path issue
(In reply to Martin Storsjö from comment #13)
(In reply to Erich E. Hoover from comment #12)
This should now (hopefully) be fully fixed by staging commit 8e5c8cc63b57dbe9b2cf2ff075c12648845b22fa.
Thanks! I can confirm that those cases are fixed now - however a different case has broken: Now creating a symlink with a target path like "../file" fails (even though it should succeed, regardless of whether the file "../file" relative to the link exists or not).
After investigating this a little bit, this relative symlink issue is actually a new issue due to an upstream change in commit 405666b736f7e471e301f051cfbe68bcbef7e0f6. This commit changes the way that lookup_unix_name converts NT names to unix names and it now fails on relative paths. I'm looking into the best way to fix this (not sure if I should be using another routine or adding a flag, but either way I'll try to get a fix out in short order. I've attached one way to fix it (flag for lookup_unix_name), if you would like to give it a try.
Thanks; the attached patch does seem to fix that particular 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=50770 --- Comment #16 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- This should now be fully fixed by staging commit c91c63a5da1ab7f885bdafb4dbc0da5a49a8a3af, would you mind giving it a try? -- 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=50770 --- Comment #17 from Martin Storsjö <martin(a)martin.st> --- (In reply to Erich E. Hoover from comment #16)
This should now be fully fixed by staging commit c91c63a5da1ab7f885bdafb4dbc0da5a49a8a3af, would you mind giving it a try?
Yup, now this seems to work as it should, thanks! -- 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=50770 Erich E. Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #18 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- Fixed by staging commit c91c63a5da1ab7f885bdafb4dbc0da5a49a8a3af. -- 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=50770 Erich E. Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #19 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- Closing bug, fixed in wine-staging 6.14. -- 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)
-
WineHQ Bugzilla