RFC: Reparse Point/NT Symlink Support [3]

[Zebediah Figura (she/her)]

On 8/31/21 11:25 AM, Erich E. Hoover wrote:
> 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.

Wait, but by the time we do path resolution, aren't we guaranteed to 
have an absolute path that's free of . or ..? I thought that 
RtlDosPathNameToNtPathName() got rid of all of those for us.