[Bug 50804] LTSpice XVII will not start

[WineHQ Bugzilla]

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

--- Comment #38 from Erich E. Hoover <erich.e.hoover at gmail.com> ---
(In reply to Zebediah Figura from comment #37)
> ...
> 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.)

Yeah, it has CreateSymbolicLink for FSCTL_SET_REPARSE_POINT - but I am not
aware of any routines that actually _read_ them without going into ntdll. 
FindNextFileW does so currently, but it can be implemented without that because
it only looks at the tag (on my list to simplify).

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

Yup, that's what I'll do - the thing that will get tricky is that when shell32
gets converted to PE that we'll need a way to properly convey the paths. 
IO_REPARSE_TAG_LX_SYMLINK works with straight-up unix paths (what we use right
now), I assume that when this is converted to PE that we'll want to work with
NT paths (though maybe we work with the "\\??\\unix" prefix when that
happens?).

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