RFC: Junction Point/NT Symlink Support

[Erich E. Hoover]

On Thu, Mar 28, 2019 at 10:38 AM Hans Leidekker <hans at codeweavers.com> wrote:
>
> On Thu, 2019-03-28 at 07:58 -0600, Erich E. Hoover wrote:
> > ...
> > How do you think we should handle "regular" symlinks that don't have
> > our magic string?  Conceivably we could use the magic string just for
> > junction points and auto-detect relative and absolute symlinks.
>
> One reason this can't work is that there are two types of symlinks on
> Windows: file symlinks and directory symlinks. You have to specify
> which type you want when you create them because the target doesn't
> have to exist.

We have to pick something for non-Wine symlinks, unless you want to
always treat them as regular (non-reparse point) files?  Treating
regular symlinks as NT Symlinks seem like the easiest choice, since
they support both file and directory symlinks.

> > ...
> > The way that I'm currently doing it is creating a temporary hidden
> > directory (.winelink.XXXXXX) and putting the symlink inside that
> > folder.
> > ...
>
> That temporary directory can still be seen, right?

Yes, though it wouldn't be too terrible to completely hide it (rather
than just "dot" hide it).

> My testing shows
> that creating a symlink fails when the link name exists, so I don't see
> why you need renameat2(RENAME_EXCHANGE) here.

Are you talking about kernel32:CreateSymbolicLink?  I'm working with
ntdll:DeviceIoControl(FSCTL_SET_REPARSE_POINT), which requires an
existing handle and is, presumably, used to implement
CreateSymbolicLink.

Best,
Erich