[patch] cygcheck.cc update for cygpath()
Brian Dessent
brian@dessent.net
Sun Mar 9 12:02:00 GMT 2008
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
More information about the Cygwin-patches
mailing list