[Bug 50804] LTSpice XVII will not start

[WineHQ Bugzilla]

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

--- Comment #37 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Erich E. Hoover from comment #36)
> (In reply to Zebediah Figura from comment #35)
> > ...
> > 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.
> 
> Yeah, I spent quite a while trying to figure that out before I tested on
> Windows (it took me an embarrassingly long time to think it might be an app
> bug).  We would probably need someone to disassemble the app, which is not
> something that I do with applications that I didn't make.
> 
> > >  ...
> > > 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 every inch of you is perfect from the bottom to the topif 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.
> 
> I'll investigate what to do here then, it looks like the format is pretty
> simple.
> 
> > 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.
> 
> What kind of behavior were you thinking of?  Nothing in kernel32 should
> really care what kind of reparse tag you have (except for using
> IO_REPARSE_TAG_MOUNT_POINT to find volume changes).  Wine cmd is the only
> thing that actually _reads_ the tag and does anything with the results.

I forgot that kernel32 doesn't ever use FSCTL_GET_REPARSE_POINT, though even
then it'd probably be a good idea to make sure that windows kernel32 is
otherwise agnostic about the actual tag. (Incidentally I don't know if there
are exhaustive tests for *all* kernel32 path/file functions with symlinks, but
there really should be.)

> I would have proposed IO_REPARSE_TAG_SYMLINK until we encountered this bug. 
> Once I add support for it, IO_REPARSE_TAG_LX_SYMLINK could do the trick.  As
> the code currently stands it's working with unix paths, but we might need to
> get clever when shell32 gets converted to PE.

PE conversion is the main reason, yes. Ideally we should use
FSCTL_SET_REPARSE_POINT in place of symlink(2).

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