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.
But on Cygwin 1.7 (installed on Windows 7), ln -s
creates a text file.
on Cygwin:
$ ln -s -v target mylink
`mylink' -> `target'
on MinGW (or your favorite editor):
$ cat mylink
!<symlink>ÿþt a r g e t
Is it possible to tell Cygwing to use NTFS junction point or NTFS symbolic link?
other question: Is this available on MinGW?
⸻⸻⸻ Short answer ⸻⸻⸻
Define environment variable:
CYGWIN=winsymlinks:nativestrict
As pointed out by mwm you may also have to run bash 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.
The accepted answer is right, two little side notes.
If you only care about the symlinks you create yourself on the command line, install cygutils-extra
package, it includes a winln
command, which has the same syntax as ln
, but creates native Windows links. Create an alias: alias ln=winln
(only works in interactive shell), or even replace the ln
file with winln
(works in shell scripts as well) - but it might get overwritten the next time coreutils
package is updated.
I've only found out it's possible to use native symlinks when I already had Cygwin installed, and added some symlinks by myself as well. So after I set CYGWIN=winsymlinks:native
as my system environment variable, I wanted to convert all the existing non-native links to native. Here's what I did.
Just in case, back up your entire Cygwin directory first.
Find all symlinks and save the list to /links
file:
cd /; find . -regextype egrep -regex './(dev|proc|mnt|cygdrive)' -prune -o -type l -print >links
Review links
.
Create a tar
archive with all the links: tar c --files-from=links >links.tar
Extract the tar
archive: tar x --files-from=links <links.tar
Since native symlinks are now enabled, tar will overwrite the old Cygwin's symlinks with native symlinks.
Clean up: rm -f links links.tar
P.S. At first I used CYGWIN=winsymlinks:nativestrict
, but then I found out that in this mode, ln -s target link
fails if target
doesn't exist. By contrast, native
will create a Cygwin (non-native) symlink link
pointing to the nonexistent target
- this matches the behavior of ln
on UNIX systems. In rare cases, nativestrict
can break some programs or scripts, for example Gentoo run-crons
script uses a lockfile which is a symlink pointing to the PID of the running process. In nativestrict
mode the script stopped working, because it could no longer create the lockfile. Note: run-crons
is a crontab helper script on Gentoo Linux, adding support for cron.{hourly,daily,weekly,monthly}/
dirs, it works very well with Cygwin.
Since @olibre answer didn't work for me. I just created a shell function.
: '
mklink - Create NTFS (Windows) links that is usable by Windows and Cygwin
Usage: mklink [/D | /H | /J] <link-path> <target-path>
Options:
/D Directory Symbolic Link
/H Hardlink
/J Directory Junction (you should prefer /D)
With no options, it creates a NTFS file symlink.
'
mklink () {
if [ "$#" -ge "3" ]; then
cmd /c mklink "$1" "$(cygpath --windows --absolute "$2")" "$(cygpath --windows --absolute "$3")"
else
cmd /c mklink "$(cygpath --windows --absolute "$1")" "$(cygpath --windows --absolute "$2")"
fi
}
Do note you need administrator permissions (for Cygwin) to run the above without problems.
Note that I am unaware whether there's any difference between symlinking to an absolute path versus symlinking to a relative path using CMD's mklink
. On Linux, those 2 have different behaviours if you ever decide to move the symlink or move the target file, or move both.
I guess the easiest way is to
grant SeCreateSymbolicLinkPrivilege from Local Group Policy editor (gpedit.msc, on path by default, non-home versions)
create script named ln
on path (batch or bash), implementation
similar to above described shell function
profit
You were probably looking for a way to get to another destination in catalogue tree using MSYS. There is a way. You should create a shell script ("*.sh" file) which contains line:
cd "/drive_letter/SubCatalogue/SubFolder/..."