[Bug 12401] New: Support junction points, i.e. DeviceIoCtl( FSCTL_SET_REPARSE_POINT/FSCTL_GET_REPARSE_POINT)
http://bugs.winehq.org/show_bug.cgi?id=12401
Summary: Support junction points, i.e. DeviceIoCtl(FSCTL_SET_REPARSE_POINT/FSCTL_GET_REPARSE_PO INT) Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
Junction points are one of Microsoft's answers to symlinks. Unix symlinks could be mapped into junction points. This would allow applications (e.g. Picasa) avoid following symlinks if they wanted to.
Also, the .net 2 installer would be happier in winxp mode if wine supported junction points (see bug 10601): "The .NET 2.0 Framework installer checks if the target volume is NTFS filesystem type and then uses the FSCTL_SET_REPARSE_POINT ioctl (used for mount points and junctions) to create junction points for each registered assembly in Windows SxS directory to GAC assembly directory (link target). Basically the junction point is used to redirect access from one directory to another."
Tommy Kho posted a patch to add a conformance test for getting and setting junction points, http://www.winehq.org/pipermail/wine-patches/2006-March/024956.html but it was not accepted.
http://bugs.winehq.org/show_bug.cgi?id=12401
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |10601
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #1 from Austin English austinenglish@gmail.com 2008-10-17 14:42:26 --- Still present in git.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #2 from Austin English austinenglish@gmail.com 2009-01-03 13:17:44 --- *** Bug 12787 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=12401
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #3 from Austin English austinenglish@gmail.com 2009-01-19 15:14:54 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=12401
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #4 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-01-20 11:43:15 --- I submitted patches to add Junction Point tests based on comments received by Tommy Kho for his above patches, as well as some feedback I received on an earlier set.
However, I haven't had any clear feedback on them, so I suspect they'll prolly just rot away in the wine-patches list until someone does the implementation to go with them.
http://www.winehq.org/pipermail/wine-patches/2009-January/067226.html http://www.winehq.org/pipermail/wine-patches/2009-January/067227.html
http://bugs.winehq.org/show_bug.cgi?id=12401
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=12401
Aric Stewart aric@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aric@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #5 from Aric Stewart aric@codeweavers.com 2010-11-03 07:46:47 CDT --- Created an attachment (id=31702) --> (http://bugs.winehq.org/attachment.cgi?id=31702) remove asserts
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #6 from Aric Stewart aric@codeweavers.com 2010-11-03 07:48:37 CDT --- Apologies, that attachment is for a different unrelated bug. Please disregard.
http://bugs.winehq.org/show_bug.cgi?id=12401
Aric Stewart aric@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #31702|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=12401
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |25535
http://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |27108
http://bugs.winehq.org/show_bug.cgi?id=12401
wineatic test051102@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |test051102@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Version|unspecified |20040615 OS/Version|other |All
http://bugs.winehq.org/show_bug.cgi?id=12401
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |-unknown Version|20040615 |unspecified OS/Version|All |other
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru 2011-12-27 21:04:33 CST --- 'All' is almost never a proper platform selection, and a version 2004* for a bug reported in 2008.
http://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.59.
--- Comment #8 from André H. nerv@dawncrow.de 2011-12-28 08:01:02 CST --- Filling Version by reporting date...
http://bugs.winehq.org/show_bug.cgi?id=12401
Chris Boyle winehq@chris.boyle.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@chris.boyle.name
http://bugs.winehq.org/show_bug.cgi?id=12401
David davidsboogs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |davidsboogs@gmail.com
--- Comment #9 from David davidsboogs@gmail.com 2011-12-31 21:40:23 CST --- Oddly enough it doesn't seem to have been mentioned here that this is the big blocker for installing the .NET 4 Framework, which is itself blocking an ever larger assortment of apps that I want to use in Wine (mostly games)
As such, can someone please recommend for me the best way to set a bounty? I tried searching, but I couldn't find how to set one for Wine, and don't know where better to ask. (Or if anyone knows other ways to encourage this to be seen by the devs as the major issue that it is for me, I'd love to hear it)
Thanks, - David
http://bugs.winehq.org/show_bug.cgi?id=12401
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=12401
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #10 from Erich Hoover ehoover@mines.edu 2012-04-11 19:34:58 CDT --- (In reply to comment #9)
Oddly enough it doesn't seem to have been mentioned here that this is the big blocker for installing the .NET 4 Framework, which is itself blocking an ever larger assortment of apps that I want to use in Wine (mostly games) ...
Is this really blocking .NET 4.0? According to AppDB .NET 4.0 can be installed with winetricks...
http://bugs.winehq.org/show_bug.cgi?id=12401
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|27108 |
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #11 from Dan Kegel dank@kegel.com 2012-04-11 20:27:53 CDT --- winetricks uses several workarounds to get dotnet40 installed. That doesn't quite count as fixed.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #12 from Erich Hoover ehoover@mines.edu 2012-04-11 21:03:10 CDT --- (In reply to comment #11)
winetricks uses several workarounds to get dotnet40 installed. That doesn't quite count as fixed.
Sorry if I wasn't clear, I didn't mean to suggest that it was fixed. It just sounds like "blocking" might be too strong of a statement. If this really is a big deal then I'm rather surprised that no one has looked into it yet, is it really that hard to find the correct place to call symlink()?
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #13 from Austin English austinenglish@gmail.com 2012-04-11 21:09:40 CDT --- (In reply to comment #12)
(In reply to comment #11)
winetricks uses several workarounds to get dotnet40 installed. That doesn't quite count as fixed.
Sorry if I wasn't clear, I didn't mean to suggest that it was fixed. It just sounds like "blocking" might be too strong of a statement. If this really is a big deal then I'm rather surprised that no one has looked into it yet, is it really that hard to find the correct place to call symlink()?
It's no longer blocking, the workarounds were made with more recent wine after that comment was made (thanks to Focht).
http://bugs.winehq.org/show_bug.cgi?id=12401
runetmember@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |runetmember@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #14 from Erich Hoover ehoover@mines.edu 2012-06-18 11:12:17 CDT --- Created attachment 40594 --> http://bugs.winehq.org/attachment.cgi?id=40594 Patch series to add support for junction points
I've been putting together a patch series to add support for Junction Points and I've been testing with the Code Project example application "MakeLink" ( http://appdb.winehq.org/objectManager.php?sClass=application&iId=14166 ). I'd really appreciate it if any interested parties would take a look at these patches and send me their feedback, thanks!
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #15 from André H. nerv@dawncrow.de 2012-06-18 12:43:40 CDT --- Hi Erich, here my list: * Start with tests * merge Patch 1 & 2 * is symlink(), readlink(), unlink() portable? I bet they are, but why are we checking for them in configure? * IO_REPARSE_TAG_MOUNT_POINT? why not e.g. IO_REPARSE_TAG_SYMLINK? * Patch 6 looks suspicious, but I’m not familiar with the code.
Hope that helps, and thanks for taking that on
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #16 from Erich Hoover ehoover@mines.edu 2012-06-18 15:06:22 CDT --- (In reply to comment #15)
...
- merge Patch 1 & 2
You sure Patch 1 and 2 should be together? It seems weird to me to put support for one of the functions along with the stubs for the others, should I maybe just drop patch 1 and do what I need to do in 2, 3, and 4 instead?
...
- IO_REPARSE_TAG_MOUNT_POINT? why not e.g. IO_REPARSE_TAG_SYMLINK?
It is my understanding that IO_REPARSE_TAG_MOUNT_POINT is for directories and IO_REPARSE_TAG_SYMLINK is for files. The application that I'm testing with only supports IO_REPARSE_TAG_MOUNT_POINT.
- Patch 6 looks suspicious, but I’m not familiar with the code.
Some applications require the FILE_ATTRIBUTE_REPARSE_POINT flag to be set. Since stat() does not report symlinks (it reports the attributes of the "real" file) it is therefore necessary to call lstat() and report that the S_IFLNK flag is set. Would you prefer that it only OR the S_IFLNK flag?
Hope that helps, and thanks for taking that on
Yes, thanks so much for your feedback - I'll see what I can do!
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #17 from André H. nerv@dawncrow.de 2012-06-18 15:19:01 CDT --- (In reply to comment #16)
(In reply to comment #15)
...
- merge Patch 1 & 2
You sure Patch 1 and 2 should be together? It seems weird to me to put support for one of the functions along with the stubs for the others, should I maybe just drop patch 1 and do what I need to do in 2, 3, and 4 instead?
yes, that's better i think
...
- IO_REPARSE_TAG_MOUNT_POINT? why not e.g. IO_REPARSE_TAG_SYMLINK?
It is my understanding that IO_REPARSE_TAG_MOUNT_POINT is for directories and IO_REPARSE_TAG_SYMLINK is for files. The application that I'm testing with only supports IO_REPARSE_TAG_MOUNT_POINT.
therefor the tests
- Patch 6 looks suspicious, but I’m not familiar with the code.
Some applications require the FILE_ATTRIBUTE_REPARSE_POINT flag to be set. Since stat() does not report symlinks (it reports the attributes of the "real" file) it is therefore necessary to call lstat() and report that the S_IFLNK flag is set. Would you prefer that it only OR the S_IFLNK flag?
if the rest of lst.st_mode can differ, then yes, otherwise it should be fine.
Hope that helps, and thanks for taking that on
Yes, thanks so much for your feedback - I'll see what I can do!
np
http://bugs.winehq.org/show_bug.cgi?id=12401
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=12401
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40594|0 |1 is obsolete| |
--- Comment #18 from Erich Hoover ehoover@mines.edu 2012-06-18 23:37:24 CDT --- Created attachment 40600 --> http://bugs.winehq.org/attachment.cgi?id=40600 Patch series to add support for junction points [v2]
I've updated the patch series for junction points to address Andre's comments. I'm not sure why Wine checks for symlink and readlink in configure though, both are standard for _POSIX_C_SOURCE >= 200112L ...
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #19 from André H. nerv@dawncrow.de 2012-06-19 13:15:22 CDT --- (In reply to comment #18)
Created attachment 40600 [details] Patch series to add support for junction points [v2]
I've updated the patch series for junction points to address Andre's comments.
1-3 and 5 are much better now.
4: * do we really want to advertise junction point support for every fs? [1] 6: * more tests, please. 95 test line changes are suspicious regarding junctionpoints * test special cases not only create, read, delete per ioctl, but use e.g. DeleteFile() to delete the link and see what happens, delete the target and see what happens, ... * sticking to only "c:" could be avoided. GetTempFileName doesn't even ensure to get a tempfile on c:, so rather do GetTempFileName first and check the volume from the returned path. * all these skip() makes me nervous, maybe some more win_skip() when appropriate. Further i think they can be reduced. * maybe you can manage to split the tests, so that you can add creation tests to patch 1, reading tests to patch 2, ...
Anyway, you did a good job.
[1] http://superuser.com/questions/429034/how-do-i-create-a-symlink-on-ntfs-from... (and on fat(every kind of), hpfs, ... we also can't symlink, to be fair no one should run wine on them, but maybe the data is stored there, not sure)
http://bugs.winehq.org/show_bug.cgi?id=12401
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40600|0 |1 is obsolete| |
--- Comment #20 from Erich Hoover ehoover@mines.edu 2012-06-19 19:21:49 CDT --- Created attachment 40614 --> http://bugs.winehq.org/attachment.cgi?id=40614 Patch series to add support for junction points [v3]
I've attached an updated patch, see below.
(In reply to comment #19)
...
- do we really want to advertise junction point support for every fs? [1]
No, the way I currently have it we would only advertise support if the filesystem is NOT one of the following: ISO9660, UDF, FAT16, or FAT32. I looked rather extensively at a way to test for symlink support and I've so far been unable to find a way to do this without actually trying to create a link.
...
- test special cases not only create, read, delete per ioctl, but use e.g.
DeleteFile() to delete the link and see what happens, delete the target and see what happens,
I've added several more test cases and spread them out throughout the patches so that each case goes with the appropriate code. This actually exposed a problem that currently exists in deleting a symlink that's a folder, at this time Wine fails to handle that properly (fix in patch 5).
...
- all these skip() makes me nervous, maybe some more win_skip() when
appropriate. Further i think they can be reduced.
Please see if this version looks more acceptable.
... Anyway, you did a good job.
Thanks! I think the only thing that's not covered now is symlinks (Vista+ feature), but I figured that I should start with junction points first.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #21 from Erich Hoover ehoover@mines.edu 2012-06-20 12:02:41 CDT --- (In reply to comment #20)
... Thanks! I think the only thing that's not covered now is symlinks (Vista+ feature), but I figured that I should start with junction points first.
After testing with the .NET 2.0 installer, I realized something that I'd appreciate some feedback about: the way I've done this so far creates an absolute path link. For example: /home/ehoover/.wine/dosdevices/c:/windows/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a links to: /home/ehoover/.wine/dosdevices/c:/windows/winsxs/x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790
It seems to me that this technique has the disadvantage that if users relocate their Wine directory that these links would break. So, do you guys think I should replace "/home/ehoover/.wine/dosdevices/" with the appropriate number of up directory references (../../../../../ in this case).
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #22 from André H. nerv@dawncrow.de 2012-06-20 13:03:39 CDT --- (In reply to comment #20)
(In reply to comment #19)
...
- do we really want to advertise junction point support for every fs? [1]
No, the way I currently have it we would only advertise support if the filesystem is NOT one of the following: ISO9660, UDF, FAT16, or FAT32. I looked rather extensively at a way to test for symlink support and I've so far been unable to find a way to do this without actually trying to create a link.
OK
...
- test special cases not only create, read, delete per ioctl, but use e.g.
DeleteFile() to delete the link and see what happens, delete the target and see what happens,
I've added several more test cases and spread them out throughout the patches so that each case goes with the appropriate code. This actually exposed a problem that currently exists in deleting a symlink that's a folder, at this time Wine fails to handle that properly (fix in patch 5).
That's a problem for patch 1, there you can't clean up the test... if RemoveDirectoryW(path); in patch 1 also removes the containing symlink then that's ok, otherwise i'd suggest to do: * patch 1: creation without tests * patch 2: deleting with tests for creation and deleting * patch 3: reading with tests ...
minor issues: for your tests please add ok() calls after e.g. CreateDirectoryW so it's easier to why something fails, in case that happens. intendation problems in tests of patch 1,2 and 5 like e.g. at CreateFileW in patch 1
...
- all these skip() makes me nervous, maybe some more win_skip() when
appropriate. Further i think they can be reduced.
Please see if this version looks more acceptable.
Yes
(In reply to comment #21)
(In reply to comment #20)
... Thanks! I think the only thing that's not covered now is symlinks (Vista+ feature), but I figured that I should start with junction points first.
After testing with the .NET 2.0 installer, I realized something that I'd appreciate some feedback about: the way I've done this so far creates an absolute path link. For example: /home/ehoover/.wine/dosdevices/c:/windows/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a links to: /home/ehoover/.wine/dosdevices/c:/windows/winsxs/x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790
It seems to me that this technique has the disadvantage that if users relocate their Wine directory that these links would break. So, do you guys think I should replace "/home/ehoover/.wine/dosdevices/" with the appropriate number of up directory references (../../../../../ in this case).
That diserves an own patch at the end of the patchset i'd say.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #23 from Erich Hoover ehoover@mines.edu 2012-06-20 13:18:07 CDT --- (In reply to comment #22)
... That's a problem for patch 1, there you can't clean up the test... if RemoveDirectoryW(path); in patch 1 also removes the containing symlink then that's ok, ...
You can't actually hit that test under Wine until patch 6 exposes junction point support.
(In reply to comment #21)
... It seems to me that this technique has the disadvantage that if users relocate their Wine directory that these links would break. So, do you guys think I should replace "/home/ehoover/.wine/dosdevices/" with the appropriate number of up directory references (../../../../../ in this case).
That diserves an own patch at the end of the patchset i'd say.
Yeah, this may actually be non-trivial - it appears that wine does not always work off of the path within the dosdevices folder.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #24 from Austin English austinenglish@gmail.com 2012-06-20 13:20:00 CDT --- (In reply to comment #21)
(In reply to comment #20)
... Thanks! I think the only thing that's not covered now is symlinks (Vista+ feature), but I figured that I should start with junction points first.
After testing with the .NET 2.0 installer, I realized something that I'd appreciate some feedback about: the way I've done this so far creates an absolute path link. For example: /home/ehoover/.wine/dosdevices/c:/windows/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a links to: /home/ehoover/.wine/dosdevices/c:/windows/winsxs/x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790
It seems to me that this technique has the disadvantage that if users relocate their Wine directory that these links would break. So, do you guys think I should replace "/home/ehoover/.wine/dosdevices/" with the appropriate number of up directory references (../../../../../ in this case).
Makes sense, the C:\ -> drive_c symlink does the same (and is the only symlink by default that is internal to the wineprefix): austin@aw25 ~/.wine $ find . -type l -exec ls -al {} ; lrwxrwxrwx 1 austin austin 13 Jun 19 14:07 ./drive_c/users/austin/My Pictures -> /home/austin/ lrwxrwxrwx 1 austin austin 20 Jun 19 14:07 ./drive_c/users/austin/Desktop -> /home/austin/Desktop lrwxrwxrwx 1 austin austin 12 Jun 19 14:07 ./drive_c/users/austin/My Documents -> /home/austin lrwxrwxrwx 1 austin austin 13 Jun 19 14:07 ./drive_c/users/austin/My Music -> /home/austin/ lrwxrwxrwx 1 austin austin 13 Jun 19 14:07 ./drive_c/users/austin/My Videos -> /home/austin/ lrwxrwxrwx 1 austin austin 10 Jun 19 14:07 ./dosdevices/c: -> ../drive_c lrwxrwxrwx 1 austin austin 1 Jun 19 14:07 ./dosdevices/z: -> / lrwxrwxrwx 1 austin austin 8 Jun 19 14:07 ./dosdevices/d:: -> /dev/sr0
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #25 from André H. nerv@dawncrow.de 2012-06-20 13:30:35 CDT --- (In reply to comment #23)
(In reply to comment #22)
... That's a problem for patch 1, there you can't clean up the test... if RemoveDirectoryW(path); in patch 1 also removes the containing symlink then that's ok, ...
You can't actually hit that test under Wine until patch 6 exposes junction point support.
Still it would happen on Windows, so again it depends on
if RemoveDirectoryW(path); in patch 1 also removes the containing symlink
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #26 from Erich Hoover ehoover@mines.edu 2012-06-20 13:33:40 CDT --- (In reply to comment #25)
... Still it would happen on Windows, so again it depends on
if RemoveDirectoryW(path); in patch 1 also removes the containing symlink
I'll double check that I haven't done something stupid, but RemoveDirectoryW works fine on symlinks/jncpts on Windows - so the problem is only on our end (until patch 5 is applied). The issue is that a RemoveDirectoryW corresponds to rmdir(), so attempting to use RemoveDirectoryW on a symlink under Wine (created this way or by the user) will result in failure.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #27 from Erich Hoover ehoover@mines.edu 2012-06-20 13:46:14 CDT --- (In reply to comment #24)
... Makes sense, the C:\ -> drive_c symlink does the same (and is the only symlink by default that is internal to the wineprefix): ...
Yeah, the only problem is that Wine works out of ./.wine/drive_c/ instead of ./.wine/dosdevices/c:/. So, I'll have to track that down before I can make it work this way. It'll also be necessary to change the link if the file is moved, since all junction points on Windows are absolute paths.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #28 from André H. nerv@dawncrow.de 2012-06-20 13:57:36 CDT --- (In reply to comment #26)
(In reply to comment #25)
... Still it would happen on Windows, so again it depends on
if RemoveDirectoryW(path); in patch 1 also removes the containing symlink
I'll double check that I haven't done something stupid, but RemoveDirectoryW works fine on symlinks/jncpts on Windows - so the problem is only on our end (until patch 5 is applied). The issue is that a RemoveDirectoryW corresponds to rmdir(), so attempting to use RemoveDirectoryW on a symlink under Wine (created this way or by the user) will result in failure.
Oh, i got confused a bit. At least you should note that in the patch. Doublechecking is a good idea anyway ;) After that, fix the minor issues i told you and send it...
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #29 from Erich Hoover ehoover@mines.edu 2012-06-20 18:45:47 CDT --- (In reply to comment #28)
... Oh, i got confused a bit. At least you should note that in the patch. Doublechecking is a good idea anyway ;) After that, fix the minor issues i told you and send it...
Done, I think I got everything this time. It did give me an opportunity to spot a missing RemoveDirectory, so that was a good check :)
[1/7] http://source.winehq.org/patches/data/87434 [2/7] http://source.winehq.org/patches/data/87435 [3/7] http://source.winehq.org/patches/data/87436 [4/7] http://source.winehq.org/patches/data/87437 [5/7] http://source.winehq.org/patches/data/87438 [6/7] http://source.winehq.org/patches/data/87439 [7/7] http://source.winehq.org/patches/data/87440
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #30 from Erich Hoover ehoover@mines.edu 2012-06-21 12:13:12 CDT --- (In reply to comment #29)
... [1/7] http://source.winehq.org/patches/data/87434 [2/7] http://source.winehq.org/patches/data/87435 [3/7] http://source.winehq.org/patches/data/87436 [4/7] http://source.winehq.org/patches/data/87437 [5/7] http://source.winehq.org/patches/data/87438 [6/7] http://source.winehq.org/patches/data/87439 [7/7] http://source.winehq.org/patches/data/87440
A comment from Hans Leidekker on wine-devel:
This is not an atomic operation since you need two Unix calls. So you would need locking or rollback to deal with possible races. ... I don't see a way to fix this other than adding a new primitive to the kernel.
Any thoughts? Would it be "good enough" to just lock the directory as far as Wine is concerned?
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #31 from Dan Kegel dank@kegel.com 2012-06-21 12:21:22 CDT --- You could move FILE_CreateSymlink into wineserver. Then it would be atomic from the point of view of wine apps, at least.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #32 from Hans Leidekker hans@meelstraat.net 2012-06-22 02:57:26 CDT --- (In reply to comment #31)
You could move FILE_CreateSymlink into wineserver. Then it would be atomic from the point of view of wine apps, at least.
It races with all filesystem operations, basically. For example, a file or directory with the same name could be created between the call to rmdir and symlink. So you would need to move all of them to the server.
And you'd still give up consistency with the filesystem's view outside of Wine.
If the goal is to get .NET 2.0 to install without changing the Windows version our time is probably better spent on fixing builtin fusion.
It can already install .NET 4.0 and I'm aware of only one bug that blocks running a simple .NET 2.0 app after installing the runtime with builtin fusion.
The bug is that the mscorlib assembly has a set of extra files (with extension .nlp) that should be installed alongside mscorlib.dll. They are present in the source directory but I haven't yet figured out how fusion determines that it needs to copy them.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #33 from Erich Hoover ehoover@mines.edu 2012-06-22 08:06:01 CDT --- (In reply to comment #32)
... If the goal is to get .NET 2.0 to install without changing the Windows version our time is probably better spent on fixing builtin fusion. ...
Personally, my goal is to support symlinks. I use them all the time and there are a variety of Windows applications that get upset about it. I'm not really excited about it, but when I get some time I'm going to talk with the kernel folks about adding support for an atomic replacement of a directory with a symlink. You can already atomically replace a directory with a directory, so I imagine that they won't be too resistant to the idea.
http://bugs.winehq.org/show_bug.cgi?id=12401
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=12401
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #34 from Erich Hoover ehoover@mines.edu 2012-07-03 11:52:29 CDT --- (In reply to comment #33)
... when I get some time I'm going to talk with the kernel folks about adding support for an atomic replacement of a directory with a symlink. ...
I sent an email to linux-fsdevel a little over a week ago and haven't had a reply, do you guys know of a better list to contact?
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #35 from Dan Kegel dank@kegel.com 2012-07-03 17:22:29 CDT --- I see your message: http://marc.info/?l=linux-fsdevel&m=134037958809770&w=2 I think the answer is probably "they'll always consider a patch", so they didn't feel the need to reply. Just go for it!
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #36 from André H. nerv@dawncrow.de 2012-07-04 12:26:35 CDT --- I'm not sure if it's the right way to get a new function into linux. What about the other systems? What about older systems?
Maybe a wine internal lock should be enough, every other case seems not that likely to happen.
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #37 from Erich Hoover ehoover@mines.edu 2012-07-17 10:31:31 CDT --- (In reply to comment #36)
I'm not sure if it's the right way to get a new function into linux. What about the other systems? What about older systems?
Maybe a wine internal lock should be enough, every other case seems not that likely to happen.
Ok, so I've been thinking about this a bit (a poorly thought idea is unlikely to make it into the kernel) and I have a thought that I'd like everyone's feedback on.
My thought is to make a "fileswap()" routine that is similar to rename() but is intended to atomically swap out two files. This way the feature can be useful to a large class of applications and still provide us with the functionality that we need. I'm thinking that from a user-space perspective it would operate like so: --- int fileswap(const char *patha, const char *pathb, int flags); --- where "flags" would have some options to allow requiring both paths to be files, both paths to be directories, or one path to be a directory and one to be a symlink to a directory. Another couple of flags would be for deleting either "patha" or "pathb" after the swap has been completed.
I think this approach should also lend itself toward the creation of libs/port/fileswap.c, allowing us to kludge together a solution for other systems (suggested by Dan). What do you guys think?
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #38 from Dan Kegel dank@kegel.com 2012-07-17 12:16:31 CDT --- Googling around finds a few people asking how to swap files atomically https://lkml.org/lkml/2010/11/25/330 so the idea might resonate.
For what it's worth, MacOSX has an exchangedata() call that is similar but only works for files, not directories.
http://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |32523
http://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33997
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #39 from André H. nerv@dawncrow.de 2013-07-12 14:12:24 CDT --- @Erich, what's the status on that?
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #40 from Erich Hoover erich.e.hoover@gmail.com 2013-07-12 14:21:14 CDT --- (In reply to comment #39)
@Erich, what's the status on that?
I haven't had a chance to work on this, I've been busy trying to get the Netflix patches in (and now waiting for feature freeze to end) :/
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #41 from André H. nerv@dawncrow.de 2013-07-12 14:45:45 CDT --- (In reply to comment #40)
(In reply to comment #39)
@Erich, what's the status on that?
I haven't had a chance to work on this, I've been busy trying to get the Netflix patches in (and now waiting for feature freeze to end) :/
You could use the time to add tests :)
http://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #42 from Erich Hoover erich.e.hoover@gmail.com 2013-07-12 16:14:57 CDT --- (In reply to comment #41)
... You could use the time to add tests :)
I have (that and getting going with my new job), but unfortunately the tests I want to do at the moment require two network cards and therefore don't do anything on the TestBot :/
http://bugs.winehq.org/show_bug.cgi?id=12401
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |31781
--- Comment #43 from Austin English austinenglish@gmail.com 2013-07-23 15:27:42 CDT --- (In reply to comment #42)
(In reply to comment #41)
... You could use the time to add tests :)
I have (that and getting going with my new job), but unfortunately the tests I want to do at the moment require two network cards and therefore don't do anything on the TestBot :/
That's bug 31781.
http://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on|31781 |
--- Comment #44 from André H. nerv@dawncrow.de 2013-08-26 14:02:26 CDT --- (In reply to comment #43)
(In reply to comment #42)
(In reply to comment #41)
... You could use the time to add tests :)
I have (that and getting going with my new job), but unfortunately the tests I want to do at the moment require two network cards and therefore don't do anything on the TestBot :/
That's bug 31781.
He was referring to another bug, network cards have nothing to do with these file system things.
https://bugs.winehq.org/show_bug.cgi?id=12401
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #45 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 38757 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=12401
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/ntdll-Junction | |_Points
https://bugs.winehq.org/show_bug.cgi?id=12401
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jmdoles@digitaldeviation.co | |m
--- Comment #46 from Anastasius Focht focht@gmx.net --- *** Bug 10601 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=12401
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://download.lenovo.com/ | |ibmdl/pub/pc/pccbbs/thinkva | |ntage_en/dotnetfx.exe CC| |focht@gmx.net Component|-unknown |ntdll Hardware|Other |x86 Blocks|10601 | Summary|Support junction points, |NET Framework 2.0, 3.0, 4.0 |i.e. |installers and other apps |DeviceIoCtl(FSCTL_SET_REPAR |that make use of GAC API |SE_POINT/FSCTL_GET_REPARSE_ |for managed assembly |POINT) |installation need reparse | |point/junction API support, | |i.e. | |DeviceIoCtl(FSCTL_SET_REPAR | |SE_POINT/FSCTL_GET_REPARSE_ | |POINT) OS|other |Linux
https://bugs.winehq.org/show_bug.cgi?id=12401
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=12401
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|spetreolle@yahoo.fr |
https://bugs.winehq.org/show_bug.cgi?id=12401
Dany dany2112@netcourrier.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dany2112@netcourrier.com
https://bugs.winehq.org/show_bug.cgi?id=12401
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=12401
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/ntdll-Junction |er/patches/ntdll-Junction_P |_Points |oints
https://bugs.winehq.org/show_bug.cgi?id=12401
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #47 from Anastasius Focht focht@gmx.net --- Hello folks,
revisiting, obviously still present.
Also a blocker for Rust 1.3 Windows installer.
Download: https://static.rust-lang.org/rustup/dist/i686-pc-windows-gnu/rustup-init.exe
--- snip --- $ wine ./rustup-init.exe ... Current installation options:
default host triple: x86_64-pc-windows-msvc default toolchain: stable modify PATH variable: yes
1) Proceed with installation (default) 2) Customize installation 3) Cancel installation
1
0009:fixme:ntdll:server_ioctl_file Unsupported ioctl 900a4 (device=9 access=0 func=29 method=0) error: unable to symlink C:\users\focht.rustup from C:\users\focht.multirust info: caused by: Request not supported. (os error 50) --- snip ---
$ sha1sum rustup-init.exe 8f4a89444bd9e63a3a1c08543209e945fe204cc2 rustup-init.exe
$ du -sh rustup-init.exe 19M rustup-init.exe
$ wine --version wine-3.18-218-g13cdcdae1a
Regards
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #48 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Anastasius Focht from comment #47)
... 0009:fixme:ntdll:server_ioctl_file Unsupported ioctl 900a4 (device=9 access=0 func=29 method=0) error: unable to symlink C:\users\focht.rustup from C:\users\focht.multirust info: caused by: Request not supported. (os error 50) ...
I have been working on updating my patches for this and it does not appear that rust uses this feature. It looks like it uses hardlinks and this error only pops up every other run (when the file already exists).
https://bugs.winehq.org/show_bug.cgi?id=12401
Jacob Hrbek werifGX@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |werifGX@gmail.com
--- Comment #49 from Jacob Hrbek werifGX@gmail.com --- Requesting more info: Which wine versions are affected by this?
https://bugs.winehq.org/show_bug.cgi?id=12401
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|NET Framework 2.0, 3.0, 4.0 |NET Framework 2.0, 3.0, 4.0 |installers and other apps |installers and other apps |that make use of GAC API |that make use of GAC API |for managed assembly |for managed assembly |installation need reparse |installation on NTFS |point/junction API support, |filesystems need reparse |i.e. |point/junction API support |DeviceIoCtl(FSCTL_SET_REPAR |(FSCTL_SET_REPARSE_POINT/FS |SE_POINT/FSCTL_GET_REPARSE_ |CTL_GET_REPARSE_POINT) |POINT) |
--- Comment #50 from Anastasius Focht focht@gmx.net --- Hello Jacob,
--- quote --- Requesting more info: Which wine versions are affected by this? --- quote ---
you mean with regards to .NET Frameworks installations? Well, technically it's no longer a hard requirement/blocker for .NET installers since Mar 2009 (https://source.winehq.org/git/wine.git/commitdiff/8044c11ecfca09e2b643feccb9... -> Wine >= 1.1.18) *unless* your WINEPREFIX and/or installation target directory resides on NTFS partition which is unlikely the case for most users.
I thought people were aware of this fact. See also my comment from 2009 (https://bugs.winehq.org/show_bug.cgi?id=10601#c23):
--- quote --- this specific problem is worked around by commit 8044c11ecfca09e2b643feccb95a4d8f645ba656 by not defaulting to NTFS anymore, see comment #15 for analysis.
You might close this one but if the ongoing discussion results in current default FS type to be changed/reverted again you have to *reopen* this bug.
The implementation of NTFS junction point API is tracked separately by bug 12401 ... --- quote ---
Maybe we should have been more explicit in the summary line from start. I've refined it now.
Talking about .NET Framework installers in general: .NET Framework 2.0 (SP1, SP2), 3.0 (SP1), 3.5 (SP1), 4.x should be pretty ok. Only few permanent issues are present, such as need for native 'mscoree' override (if you use default Wine build, without '--disable-mscoree') and the delay on the .NET 3.x language packs (broken MS installer). You also need to ensure that any extra dependencies are installed in order (winetricks usually takes care of this).
I've recently installed all of them in the same 32-bit WINEPREFIX (WinVer = 'Windows XP') without any winetricks/dll overrides, starting from .NET 2.0 (SP1, SP2), through 3.0 (SP1) and 3.5 (SP1) up to late 4.7 (requires default 'Windows 7'). Aaron Stebner's .NET Framework setup verification tool successfully validated the WINEPREFIX (files and registry entries, running .NET 2.0 and 4.0 test apps). Quite an impressive feat.
Be aware there were a couple of broken Wine 4.x releases, where either regressions in MSI and/or other components prevent proper installation.
Regards
https://bugs.winehq.org/show_bug.cgi?id=12401
Joel Holdsworth joel@airwebreathe.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joel@airwebreathe.org.uk
https://bugs.winehq.org/show_bug.cgi?id=12401
pat.wine@tullmann.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pat.wine@tullmann.org
https://bugs.winehq.org/show_bug.cgi?id=12401
Indrek Ardel eniw@ardel.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eniw@ardel.eu
--- Comment #51 from Indrek Ardel eniw@ardel.eu --- While investigating bug 42004, I found that currently the patches available in staging do not always create certain symlinks properly. Unsure if it has something to do with the original bug or something has changed since it was once declared to be fixed in staging.
1. Due to an incorrect string length issue, garbage characters may be added to the end of linked path. 2. Outside of current working directory, creating "${WINEPREFIX}" link may silently fail.
I attached patches that fix both of the mentioned issues and would like someone to review and hopefully help getting them included into existing patches in staging.
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #52 from Indrek Ardel eniw@ardel.eu --- Created attachment 75959 --> https://bugs.winehq.org/attachment.cgi?id=75959 Fix for nt_full_target string length
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #53 from Indrek Ardel eniw@ardel.eu --- Created attachment 75960 --> https://bugs.winehq.org/attachment.cgi?id=75960 Patch to specify dirfd when creating ${WINEPREFIX} link
https://bugs.winehq.org/show_bug.cgi?id=12401
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #54 from Zeb Figura z.figura12@gmail.com --- Sorry for missing those patches...
(In reply to Indrek Ardel from comment #52)
Created attachment 75959 [details] Fix for nt_full_target string length
Hrm, that patch looks a bit suspicious. The only wcslen() removed is on a buffer that was just copied to with wcscpy(), so it should definitely be zero-terminated. Does the patch actually help?
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #55 from Indrek Ardel eniw@ardel.eu --- (In reply to Zeb Figura from comment #54)
Sorry for missing those patches...
(In reply to Indrek Ardel from comment #52)
Created attachment 75959 [details] Fix for nt_full_target string length
Hrm, that patch looks a bit suspicious. The only wcslen() removed is on a buffer that was just copied to with wcscpy(), so it should definitely be zero-terminated. Does the patch actually help?
nt_full_target is composed by concatenating two buffers: 1) nt_path is copied to beginning of nt_full_target.Buffer using wcscpy 2) nt_target.Buffer is copied to the position where nt_path's zero terminator would be using memcpy.
The second source string that is of type UNICODE_STRING, isn't guaranteed to end with a zero terminator itself. As it stands, the resulting nt_full_target.Buffer cannot be trusted to have a zero terminator either, which makes using wcslen on such a buffer include more characters when the uninitialized memory following it happens also to be containing non-zero characters. The patch avoids performing wcslen on the final buffer and the calculation is done by summing the two source string lengths together instead.
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #56 from Erich E. Hoover erich.e.hoover@gmail.com --- I'm sorry I have not been very responsive lately, things have been very busy.
1) it looks like the original allocated buffer was two bytes too short because there should be added room for two WCHARs (as opposed to two chars). this is probably the real source of the problem. 2) you are no longer copying the NULL WCHAR into the nt_full_target buffer, while not strictly necessary I've found that it is _much_ harder to debug strange issues when you do not NULL-terminate these strings.
The other patch is certainly correct, my apologies for missing that previously.
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #57 from Indrek Ardel eniw@ardel.eu --- (In reply to Erich E. Hoover from comment #56)
I'm sorry I have not been very responsive lately, things have been very busy.
- it looks like the original allocated buffer was two bytes too short
because there should be added room for two WCHARs (as opposed to two chars). this is probably the real source of the problem. 2) you are no longer copying the NULL WCHAR into the nt_full_target buffer, while not strictly necessary I've found that it is _much_ harder to debug strange issues when you do not NULL-terminate these strings.
The other patch is certainly correct, my apologies for missing that previously.
1) I do not quite follow, why two WCHAR-s? Isn't |A| + |B| + 1 WCHAR-s sufficient or are talking of different buffers?
2) This is valid criticism, you are correct that an extra WCHAR is now no longer copied from nt_target. However in that case it looks like nt_target is the buffer that is missing a NULL WCHAR as it should have been copied properly into nt_full_target by memcpy and wcslen should have subsequently recognized it, which in my case was not happening.
Having to manually account for an implicit NULL WCHAR in UNICODE_STRING-s when copying buffers directly seems very error prone if someone breaks that convention elsewhere. Perhaps there exists a utility function already in the project that could copy one UNICODE_STRING at the end of the other while taking care of the implicit NULL WCHAR regardless of whether the source string has one?
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #58 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Indrek Ardel from comment #57)
(In reply to Erich E. Hoover from comment #56) ,,,
- I do not quite follow, why two WCHAR-s? Isn't |A| + |B| + 1 WCHAR-s
sufficient or are talking of different buffers?
Ignore me, for some reason I got my wires crossed and thought that this was one of the places that combines two separate buffers in order to construct a [MountPoint|SymbolicLink]ReparseBuffer.
- This is valid criticism, you are correct that an extra WCHAR is now no
longer copied from nt_target.
I would recommend NULL-terminating the string manually then, as not all of the wide character functions deal with non-NULL-terminated strings very well. In particular, I've found that it can be challenging to FIXME debugging with the strings if you don't NULL-terminate them.
However in that case it looks like nt_target is the buffer that is missing a NULL WCHAR as it should have been copied properly into nt_full_target by memcpy and wcslen should have subsequently recognized it, which in my case was not happening.
That should not be happening, Windows requires that the strings for both Symbolic Links and Junction Points be NULL-terminated (note that this is not necessarily true of all reparse tags, since they all have their own quirks). It's been a while since I played with this, but I definitely remember that if you tried to "cheat" and not have a NULL character that it would reject the [MountPoint|SymbolicLink]ReparseBuffer. Do you know how the reparse point is being created? Maybe I have a mistake somewhere and it's creating and passing a non-NULL-terminated string to one of the lower level functions.
Having to manually account for an implicit NULL WCHAR in UNICODE_STRING-s when copying buffers directly seems very error prone if someone breaks that convention elsewhere.
Yeah, I have also struggled with this. I haven't looked into it too deeply, but I suspect that this is a "we need to be bug compatible" kind of thing.
Perhaps there exists a utility function already in the project that could copy one UNICODE_STRING at the end of the other while taking care of the implicit NULL WCHAR regardless of whether the source string has one?
I don't think that we have something that already does this, what I've seen wine do most places is something like (with the appropriate "len" for the WCHAR): buffer[len] = 0;
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #59 from Indrek Ardel eniw@ardel.eu --- Created attachment 76073 --> https://bugs.winehq.org/attachment.cgi?id=76073 create archeage working dir link trace
I added a snippet captured with WINEDEBUG=+all from the game I am experiencing this issue with (ArcheAge).
Intended behavior is that by the end of it "c:\ArcheAge\Working" should be pointing to "/home/indrek/aa-clean/game" directory.
Hopefully this covers how it's being created.
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #60 from Indrek Ardel eniw@ardel.eu --- After decoding the base64 buffer in the log, you can see that the MountPointReparseBuffer.PathBuffer ends in a backslash and then a NULL terminator. Interestingly SubstituteNameLength and PrintNameLength differ by 2, with latter taking into account the trailing backslash, while the former doesn't. I don't know enough about the struct at the moment to say what's the intended purpose for either.
Since nt_target.Buffer received from get_reparse_target() is just pointed to the MountPointReparseBuffer.PathBuffer with the length taken from MountPointReparseBuffer.SubstituteNameLength, then copying length+1 WCHAR-s from it leads to copying the trailing backslash, not the NULL that was likely originally intended.
I cannot comment if nt_target.Length set by get_reparse_target() is the correct one. If it is, then this would necessitate a new string buffer allocation and copy, such that a NULL terminator could be set without polluting the original buffer. Which then later needs to be freed by the caller.
---
While searching for an utlity function to concatenate strings, I ended up finding RtlAppendUnicodeStringToString which does exactly what I had in mind, but seems like Rtl functions aren't either usable or widely used. So I concur that changing the current patch to add a null terminator of its own after copy is probably easier way to meet the desired standard for now.
https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #61 from Indrek Ardel eniw@ardel.eu --- (In reply to Indrek Ardel from comment #60)
After decoding the base64 buffer in the log, you can see that the MountPointReparseBuffer.PathBuffer ends in a backslash and then a NULL terminator. Interestingly SubstituteNameLength and PrintNameLength differ by 2, with latter taking into account the trailing backslash, while the former doesn't. I don't know enough about the struct at the moment to say what's the intended purpose for either.
Correction. PrintNameLength is 0, I was unpacking the struct incorrectly. PrintNameOffset is 2 after SubstituteNameOffset + SubstituteNameLength, leading to the position where the NULL terminator is starting.
Why is the buffer then holding a backslash that is not being accounted for in either name string is beyond me. Safest would be then to just to perform a string copy before returning as described earlier.
I apologize for my rushed analysis from before and the spam.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla