Corinna Vinschen wrote: > Now that you mention it... did you see the comment in path.cc, line 3112ff? > There's a good chance that Windows shortcuts are not capable of long path > names. I didn't test it so far, but it would be certainly better for > readlink to use the POSIX path in the symlink either way.
Check this out. I modified cygcheck to have a command line option to dump out whatever readlink() returns. $ cd /tmp $ echo "fileone" >fileone $ ln -s fileone linkone $ ln -s filetwo linktwo # filetwo doesn't exist yet $ echo "filetwo" >filetwo $ cat linkone fileone $ cat linktwo filetwo $ ./cygcheck -x linkone linktwo linkone -> fileone linktwo -> c:\tmp\filetwo $ ls -l linkone linktwo lrwxrwxrwx 1 brian None 7 Mar 9 04:56 linkone -> fileone lrwxrwxrwx 1 brian None 7 Mar 9 04:56 linktwo -> filetwo So, the fact that the link was dangling at the time it was created caused readlink to read it as a Win32 path -- which also causes it to now be an absolute target instead of a relative target. Apparently this is due to the fact that if the target doesn't exist at creation time the ParseDisplayName thing fails which results in a different structure for the .lnk file, which confuses readlink()'s puny little brain which only knows how to look at a fixed offset in the file, which results in it reading a different slot. Sigh. Brian