RFC: Junction Point/NT Symlink Support

[Hans Leidekker]

On Thu, 2019-03-28 at 13:30 -0600, Erich E. Hoover wrote:
> 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.

You wouldn't be able to report their type correctly if the target
doesn't exist.

> > > ...
> > > 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:?  I'm working with
> ntdll:DeviceIoControl(), which requires an
> existing handle and is, presumably, used to implement
> CreateSymbolicLink.

I see. So I guess CreateSymbolicLink would call CreateFile(linkname,
CREATE_NEW) and then call DeviceIoControl(FSCTL_SET_REPARSE_POINT) with
that handle.