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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Jan  8 14:17, Jeffrey Altman via Cygwin wrote:
> 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.
> [...]
> 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

Thanks, Jeffrey.  I couldn't have expressed it so nicely.  Very well
summarized.


Corinna