Re: Cygwin generates syscalls for *.lnk files on filesystems with native symlink support?

[Jeffrey Altman <jaltman@secure-endpoints.com>]

On 1/8/2024 1:44 PM, matthew patton via Cygwin wrote:
>> Cygwin does not create symlinks as junctions.  No idea where you got that idea.
> $ echo $CYGWINwinsymlinks:nativestrict
> $ /usr/bin/ln -s default.GGG6q test1
> 01/08/2024  01:24 PM    <JUNCTION>     test1 [...]Type=File
> $ (unset CYGWIN; /usr/bin/ln -s default.GGG6q test2.nocygwin)
> 01/08/2024  01:25 PM    <JUNCTION>     test2.nocygwin [...]Type=File

JUNCTIONS are a type of reparse point tag. Many tools report things as 
JUNCTIONS when they don't know what else to call it because JUNCTIONS 
were the only type of reparse tag commonly used.

This is the output of JP Software's Take Command for an AFS volume root 
directory

[\\afs\yfs]dir Directory of \\afs\yfs\* 5/26/2021 11:49 <DIR> . 
11/26/2019 14:25 <JUNCTION> amd64_linux26 
[your-file-system.com#amd64_linux26] 11/24/2019 20:29 <DIR> backups 
10/20/2022 10:43 <DIR> project 12/05/2011 10:14 <JUNCTION> public 
[#root.public] 9/06/2020 9:27 <DIR> service 7/26/2010 20:44 <JUNCTION> 
support [#root.support] 6/15/2011 11:40 <JUNCTION> test [#test.test] 
2/15/2012 8:49 <DIR> u 3/28/2023 12:50 <DIR> user 11/28/2011 17:01 
<SYMLINKD> usr [user] 12/10/2009 0:34 <JUNCTION> www [#root.www] 
12/13/2016 1:29 30 autorun.inf 6/07/2015 21:54 104 Desktop.ini 
11/26/2019 14:42 <SYMLINK> local [@sys\usr\local] 148 bytes in 3 files 
and 12 dirs 0 bytes free

The JUNCTIONS are AFS volume mount points using the Microsoft designated 
reparse point for OpenAFS. The SYMLINKD is a symlink reparse point to a 
directory using the NTFS symlink reparse point. The SYMLINK is a symlink 
reparse point to an object of unknown type (which Windows expects to be 
a file not a directory) using the NTFS symlink reparse point.

Here is the cygwin ls -l output

[\\afs\yfs]c:\tools\cygwin\bin\ls -l . total 38 -rw-r--r-- 1 jaltm 
mkpasswd 104 Jun 7 2015 Desktop.ini drwxr-xr-x 1 jaltm mkpasswd 0 Nov 26 
2019 amd64_linux26 -rw-r--r-- 1 jaltm mkpasswd 30 Dec 13 2016 
autorun.inf drwxr-xr-x 1 jaltm mkpasswd 0 Nov 24 2019 backups lrwxrwxrwx 
1 jaltm mkpasswd 14 Nov 26 2019 local -> @sys/usr/local drwxr-xr-x 1 
jaltm mkpasswd 0 Oct 20 2022 project drwxr-xr-x 1 jaltm mkpasswd 0 May 
21 2023 public drwxr-xr-x 1 jaltm mkpasswd 0 Sep 6 2020 service 
drwxr-xr-x 1 jaltm mkpasswd 0 Nov 17 2015 support drwxr-xr-x 1 jaltm 
mkpasswd 0 May 26 2019 test drwxr-xr-x 1 jaltm mkpasswd 0 Feb 15 2012 u 
drwxr-xr-x 1 jaltm mkpasswd 0 Mar 28 2023 user lrwxrwxrwx 1 jaltm 
mkpasswd 4 Nov 28 2011 usr -> user drwxr-xr-x 1 jaltm mkpasswd 0 Jul 10 
2017 www

As part of this reply I will note that the NTFS symlinks differ from 
POSIX symlinks in significant ways

 1. A pre-existing file system object is required in order to attach a
    reparse tag
 2. The type of the target must be known when the reparse tag is applied
    to a pre-existing file system object
 3. The reparse tag may be removed and replaced any number of times
    without deleting the pre-existing object to which it is attached.  
    Whereas a POSIX symlink inode target cannot be altered once
    created.  The inode must be deleted and replaced.
 4. The Windows file APIs do not behave as many applications expect them
    to when a symlink reparse tag is present.  For example, opening a
    file handle will traverse the reparse tag and open the target but
    the file info api when given the same path will return the
    information belonging to the object on which the reparse tag was
    applied.   This breaks many applications such as the java runtime
    among others.

Jeffrey Altman