Enable native NTFS symbolic links for Cygwin

⸻⸻⸻  Short answer  ⸻⸻⸻

Define environment variable:

CYGWIN=winsymlinks:nativestrict

As pointed out by mwm you may also have to run as Administrator.

⸻⸻⸻  Long answer  ⸻⸻⸻

Default Cygwin symlinks are just regular files

By default Cygwin creates text files as workaround for Windows symlink flaw.
These files are not really symlinks.
Almost all Windows programs do not considers these files as symlinks.

Native symlinks are available on recent Windows versions

Recent NTFS and Windows implement symlinks:

  • NTFS junction point can be used as directory symlink
    since NTFS 3.0 (Windows 2000) using linkd or junction tools.
  • NTFS symbolic link can also be used as symlink
    (for both file and directory) since Windows Vista using mklink tool.

Cygwin can create native NTFS symlinks

Simplified extract of the Cygwin documentation:

Symbolic links

[…]

Cygwin creates symbolic links potentially in multiple different ways:

  • The default symlinks are plain files containing a magic cookie
    followed by the path to which the link points. […]

  • The shortcut style symlinks are Windows .lnk […] created
    if the environment variable CYGWIN […] is set to contain
    the string winsymlinks or winsymlinks:lnk. […]

  • Native Windows symlinks are only created on Windows Vista/2008 and later,
    and only on filesystems supporting reparse points.
    Due to to their weird restrictions and behaviour, they are only created
    if the user explicitely requests creating them.
    This is done by setting the environment variable CYGWIN
    to contain the string winsymlinks:native or winsymlinks:nativestrict.
    […]

  • On the NFS filesystem, Cygwin always creates real NFS symlinks.

Configuring Cygwin

Cygwin User’s Guide presents variable CYGWIN and option winsymlinks:

The CYGWIN environment variable is used to configure many global settings […].
It contains the options listed below, separated by blank characters. […]

  • […]
  • […]
  • […]
  • […]
  • winsymlinks:{lnk,native,nativestrict}
    if set to just winsymlinks or winsymlinks:lnk, Cygwin creates symlinks
    as Windows shortcuts with a special headerand the R/O attribute set.

    If set to winsymlinks:native or winsymlinks:nativestrict,
    Cygwin creates symlinks as native Windows symlinks on filesystems
    and OS versions supporting them. If the OS is known not to support
    native symlinks (Windows XP, Windows Server 2003), a warning message
    is produced once per session.

    The difference between winsymlinks:native and
    winsymlinks:nativestrict is this: If the filesystem supports native
    symlinks and Cygwin fails to create a native symlink for some reason,
    it will fall back to creating Cygwin default symlinks with
    winsymlinks:native, while with winsymlinks:nativestrict
    the symlink(2) system call will immediately fail.

CYGWIN=winsymlinks:native
always creates a link but uses a Cygwin fall-back when target does not exists

on Cygwin:

$ export CYGWIN="winsymlinks:native"
$ ln -s -v target mylink
`mylink' -> `target'
$ echo content > target

on MinGW:

$ cat mylink
content

People using both Windows and Cygwin programs may have issues when a symlink is created as a dummy file (Cygwin fallback when target is missing)…

CYGWIN=winsymlinks:nativestrict
always uses native-Windows symlink but fails when target does not exist

on Cygwin:

$ export CYGWIN="winsymlinks:nativestrict"
$ rm -f  a b
$ ln -sv a b
ln: failed to create symbolic link `b': No such file or directory
$ touch    b
$ ln -sv a b
ln: failed to create symbolic link `b': File exists
$ rm b
$ touch a
$ ln -sv a b
`b' -> `a'

Because nativestrict requires the target exists before the symlink creation, some commands/scripts may fail when creating a link.

Note: Only administrators have the ability to create native NT symlinks
so under Windows UAC, the Cygwin terminal emulator (mintty)
should be run with elevated privileges
(right-click the shortcut and choose Run as Administrator
or set the mintty shortcut property, Advanced → Run as Administrator).

Special thanks to Guria and Spooky for their contributions.

Leave a Comment