On Thu, Jan 15, 2015, Greg Jung wrote: > Thanks all, let me summarize the situation: > > cygwin has its own trick to make a symlnk where the native OS doesn't > cooperate, which is a simple file beginning with the char[11]='!<symlink>' > then 0xFF,0xFE, then wide-char name of where the link points. > In windows a symlink creator needs elevated privilege and so native > symlinks may not be sufficient. > > cygwin lstat is trained to recognize this. The first clue is that it is > a system file - if the system attribute is erased, cygwin looks at a simple > file. > (It doesn't care that it is marked hidden or not). Then symlinks would have > '!<symlink>',0xff,0xfe as first 12 bytes; > > incorporating winsymlinks:native invokes the cygwin "ln" command to > create native symlinks if the shell is run as administrator, cywin links if > not. > winsymlinks:nativestrict would break non-native symlink creation. > > That's all very useful thanks for the help.
In a few words: cygwin, and therefore msys*, are additional layers which provide almost posix on top of win32 and do their very own stuff. Win32 and POSIX symlinks have little in common besides the name and you shouldn't have to take special care for files which are created by either since they're emulating the functionality, even on systems without reparse points, junctions and win32 symlinks (i.e. they use dirty tricks to do it). (and actually I think msys doesn't symlink but copies) -- Adrien Nader ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
