RFC: Reparse Point/NT Symlink Support [3]

[Erich E. Hoover]

On Tue, Aug 31, 2021 at 4:14 AM Alexandre Julliard <julliard at winehq.org> wrote:
>
> "Erich E. Hoover" <erich.e.hoover at gmail.com> writes:
> ...
> We are already resolving the path element by element because of case
> insensitivity, it seems to me that reparse point resolving would fit
> right in there. All you need is to make sure the initial stat() shortcut
> fails, which you can do by creating a dangling symlink for instance.
> Though my feeling is that using a normal file would make things easier,
> say by appending some magic filename suffix.

The difficulty isn't resolving element by element, it's doing that in
two different ways depending upon the context.  The parent directory
inside a symlink works differently depending on the context, where
that's not true for files with a different case ( chdir("..") behaves
the same no matter what case the directory is ).  A Linux example
(Windows works the same way):
===
~/tmplnk$ mkdir -p test/target
~/tmplnk$ ln -s test/target link
~/tmplnk$ cd link/
~/tmplnk/link$ ls ..
target
~/tmplnk/link$ cd ..
~/tmplnk$ ls
link  test
===
The problem I ran into is that if you treat this incorrectly then it
will cause subtle breakages all over the place.  How I attempted to
solve this was to keep the "original" path around and resolve it
locally everywhere that it needs to be resolved, this approach proved
to be very messy due to the large number of ways that we use unix
paths.  I believe that it's also possible to instead immediately
resolve the path and pass the "resolved" path around, but then we
would need to change the working directory handling to _not_ use the
normal path processing ( otherwise you will break
SetCurrentDirectory("..") ).  I say "believe" because, to my
knowledge, the working directory handling is the only special case
that requires the "original" path.  This approach might be more
viable, but I didn't get around to trying it.  I mostly did this for
fun, but either way I didn't think you would be a fan of these
approaches due to the unnecessary duplication of the OS path
resolution behavior of symlinks.

Best,
Erich