[Bug 50804] LTSpice XVII will not start

[WineHQ Bugzilla]

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

--- Comment #35 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #34)
> (In reply to Zebediah Figura from comment #33)
> > Do you know exactly what this application is trying to do with the symlink?
> > I.e. it's explicitly reading the target, but what for, what is it trying to
> > do with it?
> 
> Nope, the application doesn't try to read the symlink.  It uses
> FindFirstFileEx on it and sees that Reserved0 == IO_REPARSE_TAG_SYMLINK,
> once it detects that it calls GetFileInformationByHandle and then appears to
> fail in some way in the application logic (but not due to anything I can see
> in GetFileInformationByHandle).

It'd be nice to know what it's trying to do, just to make sure it's not our
bug, but I can also accept that applications are thrown off by trying to handle
symlinks and doing it wrong somehow.

> 
> > The idea of hiding unix symlinks completely still makes me nervous. Like I
> > said in bug 50586, it doesn't "definitely work in "all" situations", it
> > breaks GetVolumePathName() which will now always report the symlink, and
> > then subsequent calls to e.g. GetVolumeNameForVolumeMountPoint() will fail.
> 
> Right.
> 
> > I don't know, maybe this doesn't affect anything; maybe we can try it in
> > wine-staging for a while. But it feels easier to justify breaking the
> > applications that are actually broken.
> 
> I'd say before we move to hiding them that IO_REPARSE_TAG_LX_SYMLINK might
> be something to try first, that way we still have the ability to read/write
> them on the PE side if we want/need to.

Yes, I'd be inclined to agree. Having seen multiple applications break because
they try to handle symlinks and do it wrong, I'm increasingly inclined to
advocate for using IO_REPARSE_TAG_LX_SYMLINK or a custom tag.

That said, do we know whether kernel32 handles arbitrary reparse tags
transparently? I don't see tests for that in the wine-staging patch set,
although I may just be overlooking them.

> 
> > It would also be nice to have a way to actually create usable symlinks for
> > "My Documents" etc. from shell32.
> 
> Nothing prohibits us from doing this once the reparse point support is in
> place.  In this particular case, if we were to do so and create the link
> with IO_REPARSE_TAG_MOUNT_POINT then it would make this application happy. 
> If you like then I could probably add that without too much trouble and we
> can ignore user-created unix symlinks for now.

I don't think we should use IO_REPARSE_TAG_MOUNT_POINT; that has special
meaning to volume functions.

-- 
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.