Thanks all, let me summarize the situation:
cygwin has its own trick to make a symlnk where the native OS doesn't
cooperate, which is a simple file beginning with the char[11]='!<symlink>'
then 0xFF,0xFE, then wide-char name of where the link points.
In windows a symlink creator needs elevated privilege and so native
symlinks may not be sufficient.
cygwin lstat is trained to recognize this. The first clue is that it is
a system file - if the system attribute is erased, cygwin looks at a simple
file.
(It doesn't care that it is marked hidden or not). Then symlinks would have
'!<symlink>',0xff,0xfe as first 12 bytes;
incorporating winsymlinks:native invokes the cygwin "ln" command to
create native symlinks if the shell is run as administrator, cywin links if
not.
winsymlinks:nativestrict would break non-native symlink creation.
That's all very useful thanks for the help.
On Thu, Jan 15, 2015 at 12:23 AM, David Macek <david.mace...@gmail.com>
wrote:
> On 15. 1. 2015 4:11, Greg Jung wrote:
> > Yes I've seen that, if my second post appeared, the symlinks created
> with cygwin are the ones giving me trouble. These links are invisible to
> CMD.exe, by someone's
> > design:
> >
> > CYGWIN- created links in
> > Directory of e:\cygwin64\lib\nox
> >
> > 03/31/2014 09:39 AM <DIR> .
> > 03/31/2014 09:39 AM <DIR> ..
> > 07/01/2013 03:24 AM 336,710 libXpm-noX.a
> > 07/01/2013 03:24 AM 43,690 libXpm-noX.dll.a
> > 2 File(s) 380,400 bytes
> > 2 Dir(s) 85,657,726,976 bytes free
>
> I think these are cygwin emulated symlinks:
>
> They are visible, just not by default. I suspect they are marked with the
> system attribute. Use "dir /as" to show them. You should see a small size
> (in order of tens of bytes).
>
> You can instruct cygwin to create native NTFS symlinks, but due to a
> different design, there are some restrictions. See this: <
> https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks>
>
> > So the question becomes, "why do cygwin symlinks look different, and how
> can a user program detect this attribute?
>
> I assume you could detect them using cygwin *stat calls. Maybe by
> compiling against cygwin headers and cygwin1.dll, or maybe by extracting
> the relevant code from cygwin sources (you'd have to check the relevant
> licenses).
>
> --
> David Macek
>
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
