RFC: Reparse Point/NT Symlink Support [3]

[Erich E. Hoover]

On Sat, Aug 28, 2021 at 6:14 AM Alexandre Julliard <julliard at winehq.org> wrote:
>
> "Erich E. Hoover" <erich.e.hoover at gmail.com> writes:
>
> > I would love any and all feedback on updated versions of my "Reparse
> > Point" patches, which are now available in staging:
> > https://github.com/wine-staging/wine-staging/tree/master/patches/ntdll-Junction_Points
>
> My general impression is that both the design and the implementation are
> trying to be too clever for their own good.

Well, that's obviously not what I was hoping to hear.  I proposed an
alternative approach a couple years ago (
https://www.winehq.org/pipermail/wine-devel/2019-March/142536.html )
that stored the reparse tag in the symlink's access time, which is
obviously a lot simpler than encoding the tag in the filename, but
that approach has some downsides and Jacek suggested this approach as
a way to work around them.

> I would first question the assumption that these have to be actual,
> resolvable symlinks. What if they weren't?

Funny you ask, at one point I actually put together an attempt at this
and it became pretty messy very quickly.  It's not difficult for
symlinks that are files, but directory symlinks mean that we
essentially need to replace path resolution at every single place
where we want to work with a unix path.  For example, let's say that
we have a symlink at C:\test that points to C:\windows.  An attempt to
access C:\test\system32 would nominally be converted to
${WINEPREFIX}/drive_c/test/system32 and we would pass this path down
to the OS.  If we have a "custom" symlink implementation then we need
to parse the path and resolve each element in order to get the real
path to the file on the system, whereas the OS takes care of this for
us if we use "proper" symlinks.  Where this gets really nasty when you
start trying to deal with the parent directory ("..").  Parent
directory handling actually has different meaning depending on the
context, most of the time it means wrt. the target (which makes
resolving each element important) but in the context of commands that
operate on the working directory you need to work with the "original"
path.  This is all _possible_ to take care of, but at that point we're
implementing so much custom path handling that you're talking about a
substantial undertaking (that needs to be called everywhere there's a
unix path that we pass down to the OS).  But maybe there's a solution
you're seeing here that I'm not?

Best,
Erich