[Bug 50036] Remaining issues in Bugs in ntdll-Junction_Points in staging

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50036

--- Comment #5 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #4)
> (In reply to Rémi Bernon from comment #3)
> > > If I may ask, what are you using symlinks for?  (I want them to eventually reduce the space consumed by the prefix, but getting them upstream has been a challenge)
> > 
> > You should probably know that some game copy protections are pretty
> > sensitive regarding symlinks and system DLLs. I've found that the symlink
> > resolution that is already done in wineserver (calling realpath on file
> > objects to canonicalize their path) can cause trouble in some cases.
> 
> Yup.  What I'm planning to do, once I get all the reparse point support in
> place, is to create a custom Wine-specific reparse tag that follows the
> symlink for the content but does not reveal to Windows applications that it
> is a symlink.  I'm thinking tag 0x57494E45 ;)
> 
> > ...
> > I didn't try this patch series TBH, and perhaps it fixes the issue by
> > exposing the junction point nature of the links, but it's also possible that
> > it doesn't as I suspect the game doesn't handle that case.
> 
> I would really doubt that such applications allow system DLLs to be reparse
> points.  That said, making an additional patch to hide the realpath behavior
> (on top of these patches) would not be difficult.  I'll try again to get the
> mountmgr patches resent this week, since they're needed to fix reporting
> that the underlying filesystem supports reparse points now that some PE
> reorganization has occurred.

It seems a bit questionable to me, personally, since reparse point behaviour is
visible in a lot of ways and you'd basically need to hack all of them to avoid
letting the application know.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.