[Bug 50804] LTSpice XVII will not start

[WineHQ Bugzilla]

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

--- Comment #32 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Hans Leidekker from comment #30)
> (In reply to Erich E. Hoover from comment #29)
> > ...
> > 3) we can hide unix symlinks from applications (will definitely work in
> > "all" situations, but harder to implement and has less functionality)
> 
> What functionality?

The ability to see the link target on the PE side of things, if we hide the
links then the only way to be able to interact with them is on the unix side
(stat, readlink).

(In reply to Chris Caudle from comment #31)
> (In reply to Erich E. Hoover from comment #29)
> > This particular application is broken under 
> > this situation on Windows as well ('My
> > Documents' symlink).
> 
> Should that be considered an application bug that needs to be reported to
> the developers?  Doesn't help the existing versions of the executable of
> course, but they may be interested to know if there is some mistake there.

If you are so motivated then it might be worth a try, it's an unusual situation
though so they are unlikely to care.

> Ignoring that for the moment, how did WINE present those symlinks before? 
> As far as I know the "My Documents" folder presented to Windows applications
> has been a linux filesystem symlink to ~/Documents for many years, so what
> changed in how the Windows applications access that directory in recent
> versions?  And why does it only seem to affect some applications?

In regular wine and wine-staging up until recently the symlinks were
essentially hidden, the issue that's cropping up is that we're now reporting
them in wine-staging as NT symlinks (this is more* appropriate, because if
those symlinks cross devices and they do not appear as reparse points then that
can cause issues).  Old applications that are completely unaware of reparse
points work just fine, but "new-ish" applications may support one type of
reparse points but not others.  It is very common for these applications that
are reparse-aware to behave as follows:
1) 0: normal file, don't do anything special
2) IO_REPARSE_TAG_MOUNT_POINT: read the junction point and (usually) get the
real path to the target
3) IO_REPARSE_TAG_SYMLINK: read the symlink and (usually) get the real path to
the target
4) other: either ignore or get the volume the target is on (unusual for this to
matter, really only affects applications that search disks by file id)

* It is conceivable to treat them as other types of reparse points, but each
type has pluses and minuses.

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