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@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.