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 -- 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