Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 22 Mar 2013 15:59:04 -0500
From: "jfoug" <>
To: <>
Subject: RE: makefile, build (cygwin)

> From: magnum [] 
> On 22 Mar, 2013, at 18:45 , "jfoug" <> wrote:
>> One note, changes like this would only build useable exe files, that run
using the cygwin shell.  The symlinks would not work properly under a plain
Win32 cmd.   However, the unix symlink model is far from correct on win32 as
it is. There are some environmental, and stdin/stdout strangeness from using
the symlink.c method.   I personally copy john.exe to whatever name I need
(such as copy john.exe unique.exe).  If done that way, all of the strange
behaviors go away.

> Does "ln -s" not produce absolutely normal symlinks?

Nope.  Here is a good article explaining Win32 'links/shortcuts' (.lnk
files)  and also Vista or later symlinks from the mklink shell builtin
(inside cmd).

The mklink or mklink /d (the /d needed to link to a directory), does work,
and does work in cygwin (since the underlying OS of windows treats it as a
link, similar to unix).  However, building them is a builtin function of
cmd.exe, is only available in Vista or later OS's, AND is problematic, since
the UAC will complain about it, unless running the cmd as Administrator.  So
it is not a real solution either, and even if it was, it would be different
than ln -s, but I guess that could be hidden (if it worked better) in macro
magic in the make file.

> IIRC Windows and NTFS has handled symlinks and hard links ever since the
first NT version 20 years ago. I thought the only thing missing in the
Windows world was userland tools.

They do have links, but it is a 'metadata' file.  Thus if moved, or
tarred/untarred, they become worthless.

Also, cygwin's ln -s does not create them.   It creates a magic file, that
is:   <!symlink>Xname   X is some 2 byte binary value, likely a time stamp,
execution bits of original file, etc, I really do not know).  name is simply
a unicode string, that is the 2nd param of the ln command (the name of the
target file), but in unicode, or apparent unicode.  Windows knows nothing
about this file type, and will not execute it, either from within CMD shell,
or from explorer.  However, the cygwin shell knows that file type.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.