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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
