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:
- junction point
- absolute symlink
- 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.