[Bug 50804] LTSpice XVII will not start

[WineHQ Bugzilla]

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

--- Comment #36 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(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.

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

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.

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