[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(a)winehq.org ReportedBy: dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |10601 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #1 from Austin English <austinenglish(a)gmail.com> 2008-10-17 14:42:26 --- Still present in git. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #2 from Austin English <austinenglish(a)gmail.com> 2009-01-03 13:17:44 --- *** Bug 12787 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified --- Comment #3 from Austin English <austinenglish(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com --- Comment #4 from Paul "TBBle" Hampson <Paul.Hampson(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Saulius K. <saulius2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Aric Stewart <aric(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aric(a)codeweavers.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #5 from Aric Stewart <aric(a)codeweavers.com> 2010-11-03 07:46:47 CDT --- Created an attachment (id=31702) --> (http://bugs.winehq.org/attachment.cgi?id=31702) remove asserts -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #6 from Aric Stewart <aric(a)codeweavers.com> 2010-11-03 07:48:37 CDT --- Apologies, that attachment is for a different unrelated bug. Please disregard. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Aric Stewart <aric(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #31702|0 |1 is obsolete| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |25535 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |27108 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 wineatic <test051102(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |test051102(a)hotmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv(a)dawncrow.de Version|unspecified |20040615 OS/Version|other |All -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |-unknown Version|20040615 |unspecified OS/Version|All |other --- Comment #7 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.59. --- Comment #8 from André H. <nerv(a)dawncrow.de> 2011-12-28 08:01:02 CST --- Filling Version by reporting date... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Chris Boyle <winehq(a)chris.boyle.name> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq(a)chris.boyle.name -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 David <davidsboogs(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |davidsboogs(a)gmail.com --- Comment #9 from David <davidsboogs(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Luke Bratch <l_bratch(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch(a)yahoo.co.uk -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Erich Hoover <ehoover(a)mines.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover(a)mines.edu --- Comment #10 from Erich Hoover <ehoover(a)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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|27108 | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #11 from Dan Kegel <dank(a)kegel.com> 2012-04-11 20:27:53 CDT --- winetricks uses several workarounds to get dotnet40 installed. That doesn't quite count as fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #12 from Erich Hoover <ehoover(a)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()? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #13 from Austin English <austinenglish(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 runetmember(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |runetmember(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #14 from Erich Hoover <ehoover(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #15 from André H. <nerv(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #16 from Erich Hoover <ehoover(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #17 from André H. <nerv(a)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
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer CC| |austinenglish(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Erich Hoover <ehoover(a)mines.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40594|0 |1 is obsolete| | --- Comment #18 from Erich Hoover <ehoover(a)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 ... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #19 from André H. <nerv(a)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) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Erich Hoover <ehoover(a)mines.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #40600|0 |1 is obsolete| | --- Comment #20 from Erich Hoover <ehoover(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #21 from Erich Hoover <ehoover(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #22 from André H. <nerv(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #23 from Erich Hoover <ehoover(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #24 from Austin English <austinenglish(a)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(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #25 from André H. <nerv(a)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
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #26 from Erich Hoover <ehoover(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #27 from Erich Hoover <ehoover(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #28 from André H. <nerv(a)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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #29 from Erich Hoover <ehoover(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #30 from Erich Hoover <ehoover(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #31 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #32 from Hans Leidekker <hans(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #33 from Erich Hoover <ehoover(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle(a)yahoo.fr -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #34 from Erich Hoover <ehoover(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #35 from Dan Kegel <dank(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #36 from André H. <nerv(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #37 from Erich Hoover <ehoover(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #38 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |32523 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33997 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #39 from André H. <nerv(a)dawncrow.de> 2013-07-12 14:12:24 CDT --- @Erich, what's the status on that? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #40 from Erich Hoover <erich.e.hoover(a)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) :/ -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #41 from André H. <nerv(a)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 :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 --- Comment #42 from Erich Hoover <erich.e.hoover(a)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 :/ -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |31781 --- Comment #43 from Austin English <austinenglish(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|31781 | --- Comment #44 from André H. <nerv(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=12401 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl(a)bk.ru --- Comment #45 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- *** Bug 38757 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=12401 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael(a)fds-team.de, | |sebastian(a)fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/ntdll-Junction | |_Points -- 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=12401 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmdoles(a)digitaldeviation.co | |m --- Comment #46 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 10601 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=12401 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |http://download.lenovo.com/ | |ibmdl/pub/pc/pccbbs/thinkva | |ntage_en/dotnetfx.exe CC| |focht(a)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 -- 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=12401 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- 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=12401 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|spetreolle(a)yahoo.fr | -- 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=12401 Dany <dany2112(a)netcourrier.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dany2112(a)netcourrier.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=12401 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- 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=12401 André H. <nerv(a)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 -- 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=12401 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch -- 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=12401 --- Comment #47 from Anastasius Focht <focht(a)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 -- 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=12401 --- Comment #48 from Erich E. Hoover <erich.e.hoover(a)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). -- 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=12401 Jacob Hrbek <werifGX(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |werifGX(a)gmail.com --- Comment #49 from Jacob Hrbek <werifGX(a)gmail.com> --- Requesting more info: Which wine versions are affected by this? -- 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=12401 Anastasius Focht <focht(a)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(a)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 -- 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=12401 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joel(a)airwebreathe.org.uk -- 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=12401 pat.wine(a)tullmann.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pat.wine(a)tullmann.org -- 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=12401 Indrek Ardel <eniw(a)ardel.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eniw(a)ardel.eu --- Comment #51 from Indrek Ardel <eniw(a)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. -- 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=12401 --- Comment #52 from Indrek Ardel <eniw(a)ardel.eu> --- Created attachment 75959 --> https://bugs.winehq.org/attachment.cgi?id=75959 Fix for nt_full_target string length -- 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=12401 --- Comment #53 from Indrek Ardel <eniw(a)ardel.eu> --- Created attachment 75960 --> https://bugs.winehq.org/attachment.cgi?id=75960 Patch to specify dirfd when creating ${WINEPREFIX} link -- 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=12401 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #54 from Zeb Figura <z.figura12(a)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? -- 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=12401 --- Comment #55 from Indrek Ardel <eniw(a)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. -- 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=12401 --- Comment #56 from Erich E. Hoover <erich.e.hoover(a)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. -- 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=12401 --- Comment #57 from Indrek Ardel <eniw(a)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.
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.
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? -- 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=12401 --- Comment #58 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Indrek Ardel from comment #57)
(In reply to Erich E. Hoover from comment #56) ,,, 1) 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.
2) 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; -- 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=12401 --- Comment #59 from Indrek Ardel <eniw(a)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. -- 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=12401 --- Comment #60 from Indrek Ardel <eniw(a)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. -- 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=12401 --- Comment #61 from Indrek Ardel <eniw(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12401 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |66cd41d5801d2efa359cdfad4f6 | |12c5fab902a68 Status|STAGED |RESOLVED Resolution|--- |FIXED --- Comment #62 from Zeb Figura <z.figura12(a)gmail.com> --- We have reparse point support now, after a series ending in 66cd41d5801d2efa359cdfad4f612c5fab902a68. I can see the linked .NET installer working (after I use a 32-bit prefix and remove Mono), but it doesn't actually create any reparse points. However, the Rust installer from comment 47 does work now, and successfully create reparse points for e.g. rustc.exe, which can be successfully run. (Note that the Unix file is named rustc.exe?, with a ? character on the end, but you still want to run `wine rustc.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.
http://bugs.winehq.org/show_bug.cgi?id=12401 russianneuromancer(a)ya.ru changed: What |Removed |Added ---------------------------------------------------------------------------- CC|russianneuromancer(a)ya.ru | -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla