[patch] cygcheck.cc update for cygpath()

[Brian Dessent]

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