This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] cygcheck.cc update for cygpath()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]