Problems w/cygsym links vs. winsymlnks: (was Re: Running a program using a DLL under Cygwin)

Linda Walsh
Sun Oct 11 22:38:00 GMT 2015

Andrey Repin wrote:
> Greetings, Linda Walsh!
>>>> I think symlink is a cygwin thing.  Windows won't find that DLL (just
>>>> like you won't find it using windows explorer.)
>>> Unless he have created a Windows symlink, that is correct.
>>> Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.
>> ----
>> Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native export'
>> in your 'CYGWIN' env var at startup -- preferably in your Win profile.
>> However, cygwin occasionally has some bugs in how it creates links:
>> /tmp> touch x
>> /tmp> ln -s x y    
>> /tmp> ll x y
>> -rw-rw-r--+ 1 0 Oct 10 22:27 x
>> lrwxrwxrwx  1 6 Oct 10 22:28 y -> /tmp/x
>> /tmp> cmd /c dir ?|grep '\s[xy]'
>> 10/10/2015  10:32 PM                 0 x
>> 10/10/2015  10:40 PM    <SYMLINK>      y [C:\tmp\x]
>> /tmp> rm y
>> /tmp> mklink x y
> Do note that native mklink has arguments in the opposite order. (Microsoft...)
	Yes... but notice I typed that at a bash prompt and that 
it did the same thing as 'ln -s' and worked with the same order
(mklink = bash-script that wraps around native mklink to make
it same order).  This also has mklink working but 'ln -s'
changing a relative link to a absolute link

	Another example of cygwin's 'ln -s' chainging the link:
/tmp> mkdir foo
/tmp> ln -s foo cygfoo
/tmp> mklink foo winfoo
symbolic link created for winfoo <<===>> foo
/tmp> cmd /c dir|grep  foo
10/11/2015  11:23 AM    <SYMLINKD>     cygfoo [C:\tmp\foo]
10/11/2015  11:22 AM    <DIR>          foo
10/11/2015  11:24 AM    <SYMLINKD>     winfoo [foo]
looks innocent enough until I mv them:
/tmp> mkdir links
/tmp> mv foo cygfoo winfoo links
/tmp> cd links
/tmp/links> ls
cygfoo@  foo/  winfoo@
/tmp/links> ll
total 0
lrwxrwxrwx  1 8 Oct 11 11:23 cygfoo -> /tmp/foo
drwxrwxr-x+ 1 0 Oct 11 11:22 foo/
lrwxrwxrwx  1 3 Oct 11 11:24 winfoo -> foo/
Notice the cygwin created symlink points to a
non-existing file /tmp/foo. 
A 3rd problem is trying to create the links 
before creating the dir.

Not a problem on linux, but on windows, notice above, the
symlinks to directories are a different type
than the ones to regular files.

So, currently the shell wrapper complains, but cygwin
creates a cygwin-only symlink: a hidden 'System' file that
windows can't use and normally doesn't see:

/tmp/links> ln -s foo2 cygfoo2
/tmp/links> mklink foo2 winfoo2
Source, "foo2", does not exist.
  ### uhoh, "forgot" to create foo2 1st, better create it now:
/tmp/links> mkdir foo2
/tmp/links> mklink foo2 winfoo2

/tmp/links> ls *?foo2
cygfoo2@  winfoo2@
/tmp/links> ll *?foo2
lrwxrwxrwx 1 4 Oct 11 12:31 cygfoo2 -> foo2/
lrwxrwxrwx 1 4 Oct 11 12:37 winfoo2 -> foo2/

  ### create files in cygfoo2 and winfoo2 from cygwin:
/tmp/links> touch {cyg,win}foo2/child_file
/tmp/links> ll {cyg,win}foo2/child_file   
-rw-rw-r-- 1 0 Oct 11 13:22 cygfoo2/child_file
-rw-rw-r-- 1 0 Oct 11 13:22 winfoo2/child_file

  ## so cygwin can create a child_file in each, but
  ## win's dir /a?

  ### looks like cygfoo2 is there, as seen on cygwin, above, but a 
  ### dir cmd from win doesn't see it:

/tmp/links> cmd /c dir|grep ' [AP]M'
10/11/2015  12:37 PM    <DIR>          .
10/11/2015  12:37 PM    <DIR>          ..
10/11/2015  11:23 AM    <SYMLINKD>     cygfoo [C:\tmp\foo]
10/11/2015  11:22 AM    <DIR>          foo
10/11/2015  12:35 PM    <DIR>          foo2
10/11/2015  11:24 AM    <SYMLINKD>     winfoo [foo]
10/11/2015  12:37 PM    <SYMLINKD>     winfoo2 [foo2]

  ### attrib/no args shows files with attrs set:

/tmp/links> attrib                     
   S         C:\tmp\links\cygfoo2

  ### dir /a will show also reveal hidden and system files:
  ### this shows diff of cygwin ln -s foo2 cygfoo2
  ###                 and the bash-shell wrapper calling mklink
  ###	              (after 'mkdir foo2')

/tmp/links> cmd /c dir /a *?foo2|grep ' [AP]M'
10/11/2015  12:31 PM                22 cygfoo2
10/11/2015  12:37 PM    <SYMLINKD>     winfoo2 [foo2]

 ## creating files in 'cygfoo2 and winfoo2

> For the purposes of DLL loading, hardlink is probably a good choice.
There is one drawback to hardlink usage (if softlink usage doesn't
matter, of course, that's irrelevant).  All copies of a hardlinked
file will be locked if any of them are.

Vs. if you use softlinks, -- the file they point to will
likely be locked, by the symlinks might not be... if that's
the case, symlinks could be repointed at new "dll"'s for
fixes without requiring requiring the current dll's not
be in use.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list