From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id EA1123858C62; Mon,  8 Jan 2024 19:21:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EA1123858C62
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1704741719;
	bh=b7mYST0iQsP5uqOQjoF1vGh3GVBVZZiMnEklOw3QE2U=;
	h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From;
	b=A50et0O52hHckAjyCCE1Dct01qCqC76d0HH8aB/cLAEfXNHyPakmkQXImUvRmwTXd
	 2XZecWksb1S0a893Ax2ZSx0TP7e/4LSLM3rNHtnw3fXGcotTnI5PjP/zzi+OvDfAk7
	 +W99Gc4zJjvG4KLlhh7szk2huKwKxlIolARxPq9c=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id 15D22A806FF; Mon,  8 Jan 2024 20:21:58 +0100 (CET)
Date: Mon, 8 Jan 2024 20:21:58 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin generates syscalls for *.lnk files on filesystems with
 native symlink support?
Message-ID: <ZZxLVnNZJP7jOo7Z@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <CALXu0UfRxk5G=3OjbwoNFW7xSj1rHTNw5giS6YZb9p1gF5ceTA@mail.gmail.com>
 <ZPHDrz7VedOBROtT@calimero.vinschen.de>
 <CALXu0Ue9SyJod+0k24pQzs3KPg1RPquRfhN3tw3GYG-qMt_+DQ@mail.gmail.com>
 <ZZv_K1NyxE-btqQt@calimero.vinschen.de>
 <266017637.5531727.1704733902023@mail.yahoo.com>
 <ZZw65R578QtNO_4E@calimero.vinschen.de>
 <487617694.5562874.1704739459687@mail.yahoo.com>
 <2f4c9914-1285-42f0-b841-69335687713a@secure-endpoints.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2f4c9914-1285-42f0-b841-69335687713a@secure-endpoints.com>
List-Id: <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