RFC: Junction Point/NT Symlink Support

[Erich E. Hoover]

On Tue, Mar 26, 2019 at 1:45 PM Hans Leidekker <hans at codeweavers.com> wrote:
>
> On Tue, 2019-03-26 at 15:41 +0100, Jacek Caban wrote:
> > ...
> > I didn't look deep enough at those areas to comment on general idea, but
> > for an additional flag, you could also include a magic string in link
> > location itself, something like ".///.///actual_target". It would be
> > preserved by tar. A simple stat would not be enough to check the flag,
> > so I'm not sure how practical that would be.
>
> That looks attractive. If you need to set the link type with a separate
> operation creating a junction point is no longer atomic.

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.

> 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?

Best,
Erich