RFC: Junction Point/NT Symlink Support

[Hans Leidekker]

On Thu, 2019-03-28 at 07:58 -0600, Erich E. Hoover wrote:
> So, instead of using the access/modification time we write a magic
> string.  I can get behind that.  There are other reparse tags we won't
> be able to represent, but I don't think that's worth worrying about.
> If we do it like this then presumably we want to write a magic string
> for three cases:
> 1) junction point
> 2) absolute symlink
> 3) relative symlink
> 
> > It may also allow you to keep using regular symlinks inside
> > prefixes, transparent to Windows applications.
> 
> 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.

> > An issue I see with renameat2(RENAME_EXCHANGE) is that it needs two
> > files, which shouldn't be visible to applications at the same time.
> 
> The way that I'm currently doing it is creating a temporary hidden
> directory (.winelink.XXXXXX) and putting the symlink inside that
> folder.  RENAME_EXCHANGE requires that both the directory and the
> symlink be on the same filesystem, so I'm creating this temporary
> folder in the same directory as the Junction Point/NT Symlink.  Do you
> have a better suggestion?

That temporary directory can still be seen, right? 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.