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
from mingw.org/msys bash:
greg@Homerw7 /f/git/bldgdl
$ ls -la /e/cygwin64/lib/nox
total 634
drwxr-xr-x 2 greg Administrators 4096 Mar 31 2014 .
drwxr-xr-x 77 greg Administrators 262144 Sep 25 21:36 ..
-rw-r--r-- 1 greg Administrators 336710 Jul 1 2013 libXpm-noX.a
-rw-r--r-- 1 greg Administrators 43690 Jul 1 2013 libXpm-noX.dll.a
-rw-r--r-- 1 greg Administrators 38 Mar 29 2014 libXpm.a
-rw-r--r-- 1 greg Administrators 46 Mar 29 2014 libXpm.dll.a
from cygwin/bash:
$ ls -la /e/cygwin64/lib/nox
total 638
drwxrwxrwx+ 1 greg None 0 Mar 31 2014 .
drwxrwxrwx+ 1 greg None 0 Sep 25 21:36 ..
lrwxrwxrwx 1 greg None 12 Mar 29 2014 libXpm.a -> libXpm-noX.a
lrwxrwxrwx 1 greg None 16 Mar 29 2014 libXpm.dll.a -> libXpm-noX.dll.a
-rwxrwxrwx+ 1 greg None 336710 Jul 1 2013 libXpm-noX.a
-rwxrwxrwx+ 1 greg None 43690 Jul 1 2013 libXpm-noX.dll.a
And the same result from msys2 bash.
The CMD.exe directory command of a native symlink looks like so:
Directory of c:\msys64\opt
01/14/2015 03:02 PM <DIR> .
01/14/2015 03:02 PM <DIR> ..
12/08/2014 09:40 PM <DIR> bin
11/08/2014 02:47 PM <DIR> doc
11/06/2014 01:29 AM <DIR> etc
11/17/2014 06:22 PM <DIR> include
11/04/2014 01:09 AM <DIR> info
12/08/2014 04:37 PM <DIR> lib
12/08/2014 09:39 PM <DIR> lib64
05/24/2014 09:11 AM <DIR> man
11/18/2014 04:23 PM <DIR> pkgconfig
11/05/2014 09:16 PM <DIR> share
11/04/2014 01:09 AM <DIR> var
01/14/2015 03:02 PM <SYMLINK> ww [yypkg.exe]
11/08/2014 08:57 AM <DIR> x86_64-w64-mingw32
01/14/2015 02:36 PM <SYMLINK> yy [yypkg.exe]
11/04/2014 01:04 AM 2,348,046 yypkg.exe
3 File(s) 2,348,046 bytes
14 Dir(s) 40,575,012,864 bytes free
on cygwin the native links ww,yy look just like cygwin symlinks:
$ls -la
total 2576
drwxrwxrwx+ 1 greg None 0 Jan 14 15:02 .
drwxrwxrwx+ 1 greg None 0 Nov 17 18:21 ..
drwxrwxrwx+ 1 greg None 0 Dec 8 21:40 bin
drwxrwxrwx+ 1 greg None 0 Nov 8 14:47 doc
drwxrwxrwx+ 1 greg None 0 Nov 6 01:29 etc
drwxrwxrwx+ 1 greg None 0 Nov 17 18:22 include
drwxrwxrwx+ 1 greg None 0 Nov 4 01:09 info
drwxrwxrwx+ 1 greg None 0 Dec 8 16:37 lib
drwxrwxrwx+ 1 greg None 0 Dec 8 21:39 lib64
drwxrwxrwx+ 1 greg None 0 May 24 2014 man
drwxrwxrwx+ 1 greg None 0 Nov 18 16:23 pkgconfig
drwxrwxrwx+ 1 greg None 0 Nov 5 21:16 share
drwxrwxrwx+ 1 greg None 0 Nov 4 01:09 var
lrwxrwxrwx 1 Administrators None 9 Jan 14 15:02 ww -> yypkg.exe
drwxrwxrwx+ 1 greg None 0 Nov 8 08:57 x86_64-w64-mingw32
lrwxrwxrwx 1 Administrators None 9 Jan 14 14:36 yy -> yypkg.exe
-rwxrwxrwx+ 1 greg None 2348046 Nov 4 01:04 yypkg.exe
On Wed, Jan 14, 2015 at 6:16 PM, dw <da...@limegreensocks.com> wrote:
> I'm not quite sure what you are looking for. However, maybe this will
> help:
>
> Data.raw does not have the FILE_ATTRIBUTE_REPARSE_POINT attribute set.
> Similarly, ffd.dwReserved0 is 0.
> Data2.raw DOES have the FILE_ATTRIBUTE_REPARSE_POINT attribute. And
> ffd.dwReserved0 shows IO_REPARSE_TAG_SYMLINK.
>
> FWIW.
>
> dw
>
For some reason my second post was bounced (maybe it didn't like a link I
referenced)
The links I couldn't detect earlier were created by cygwin install
> procedure, i.e. cygwin64/lib/noX has two files and
> two symlinks pointing to the files: fstat_win32 below didn't find a
> FILE_ATTRIBUTE_REPARSE_POINT in its mask.
>
> Nevertheless, cygwin and msys2 "ls -la" commands show a symlink. They
> work like a symlink should.
> So the question becomes, "why do cygwin symlinks look different, and how
> can a user program detect this attribute?
>
> On 1/14/2015 9:33 AM, Greg Jung wrote:
>
> Hi Folks,
> I've been trying to program a recognition of NTFS symbolic link files;
> What I;ve gleaned
> from MSDN procedures don't seem to work. Below are coded three methods
>
> 1) (untested) open file and call GetFileInformationByHandleEx. I can't
> get winbase.h header definitions recognized
> 2) GetFileAttributes() works ok for Junctions doesn't recognize symlink
> files
> 3) FindFirstEx . same result as 2)
>
>
------------------------------------------------------------------------------
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
