cjs
cjs

Reputation: 27271

Why does MINGW MSYS2 `ln` not create directory junctions?

Background: I have a good understanding of UNIX filesystems, POSIX filesystem semantics and the POSIX file-related APIs, but little understanding of NTFS and the Windows file-related APIs. I expect that answers to this question will increase my understanding of the latter.

I am using the MSYS2 installation that came with Git for Windows version 2.32.0.windows.2.

Earlier versions of Windows do not support symbolic links, and even later versions of Windows do not allow regular users to create symbolic links by default. (There are no doubt reasons for this; one I have heard is that Windows programs do not properly "understand" symbolic links.)

Windows does provide a similar (though less capable) facility called "junction points" which, like symbolic links, are a type of "reparse point" in NTFS. My understanding is that these can be used only for directories, can only be created on local filesystems, and the target of the link must always be an absolute path.

MSYS2 ls will display these directory junctions as symbolic links, and programs seem to follow them just like they follow symbolic links in POSIX:

$ mkdir target
$ cmd //c mklink //j link target
Junction created for link <<===>> target
$ ls -l
total 0
lrwxrwxrwx 1 cjs 197121 23 Apr 23 09:09 link -> /c/Users/cjs/tmp/target/
drwxr-x--- 1 cjs 197121  0 Apr 23 09:08 target/
$

The default behaviour of MSYS2 ln -s is to copy the target file or directory and its files to the link name. This can be changed to create symbolic links, though this of course won't work if you're not an admin and haven't configured Windows to allow non-admins to create symbolic links.

Though there's nothing to be done about this for files, it seems to me that ln -s could reasonably create a junction instead of a symbolic link in two cases:

  1. Where the link is on a local filesystem, the target is a directory, and the target is an absolute path, as in the example above. This appears to me as if it would show no change in behaviour from POSIX.

  2. As above, but where the target is not an absolute path, if ln calculated an absolute path for the target and used that instead of the relative path it was given. This would produce different behaviour from a POSIX symbolic link, but it would at least be less different than copying all the files. (For example, given /foo/1/t, /foo/2/t and a link /foo/1/p -> t, mv /foo/1/t /foo/2/t would point to a different set of files in POSIX, but would reference the copy of the original set of files in MINGW2's "copy" system.)

So why does MINGW2 ln -s not do one or both of these? Is this likely to cause confusion in other ways? Is it likely to break certain uses of the file APIs by MINGW or Windows programs?

Upvotes: 0

Views: 168

Answers (0)

Related Questions