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 #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 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 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 #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 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 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 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 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 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 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 #12 from Erich Hoover <ehoover(a)mines.edu> 2012-04-11 21:03:10 CDT --- (In reply to comment #11) 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 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 #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 #17 from André H. <nerv(a)dawncrow.de> 2012-06-18 15:19:01 CDT --- (In reply to comment #16) yes, that's better i think therefor the tests if the rest of lst.st_mode can differ, then yes, otherwise it should be fine. 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 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 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) 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. 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). Please see if this version looks more acceptable. 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 #22 from André H. <nerv(a)dawncrow.de> 2012-06-20 13:03:39 CDT --- (In reply to comment #20) OK 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 Yes (In reply to comment #21) 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 #24 from Austin English <austinenglish(a)gmail.com> 2012-06-20 13:20:00 CDT --- (In reply to comment #21) 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 -- 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) 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 #28 from André H. <nerv(a)dawncrow.de> 2012-06-20 13:57:36 CDT --- (In reply to comment #26) 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 #30 from Erich Hoover <ehoover(a)mines.edu> 2012-06-21 12:13:12 CDT --- (In reply to comment #29) A comment from Hans Leidekker on wine-devel: 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 #32 from Hans Leidekker <hans(a)meelstraat.net> 2012-06-22 02:57:26 CDT --- (In reply to comment #31) 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 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 --- Comment #34 from Erich Hoover <ehoover(a)mines.edu> 2012-07-03 11:52:29 CDT --- (In reply to comment #33) 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 #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 #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| |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 #40 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-07-12 14:21:14 CDT --- (In reply to comment #39) 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 #42 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-07-12 16:14:57 CDT --- (In reply to comment #41) 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 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) 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 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 ---------------------------------------------------------------------------- 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 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 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 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 #48 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Anastasius Focht from comment #47) 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 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/8044c11ecfca09e2b643feccb… -> 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 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 --- 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 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) 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 #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 #58 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Indrek Ardel from comment #57) 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. 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. 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. 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. 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 #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.