Corinna Vinschen wrote: > > > I'm wondering if you would like to tweak the readlink functions, too. > > > Cygwin shortcuts can now have the path name appended to the actual > > > shortcut data. This hack was necessary to support pathnames longer than > > > 2000 chars. See the comment and code in cygwin/path.cc, line 3139ff. > > > > Oh, I didn't know that. I'll add that to the list. > > Thanks again. I'm finally seeing light at the end of the long path > name tunnel :)
Actually I'm a little confused now. It seems like the code in utils/path.cc:readlink() reads the Win32 path out of shortcut symlinks but the POSIX path out of old-style symlinks -- not that it has any choice since they don't contain the win32 path. If that is the case (and assuming I'm reading the new long filename symlink code correctly) then it doesn't need any chaging since the [path too long] workaround only applies to the POSIX link target stored in the 'description' field, right? But the semantics of "sometimes you get an absolute Win32 path, sometimes you get a relative POSIX path" that readlink() seems to provide baffles my mind. More and more it seems that a lot of how these non-Cygwin tools successfully process paths happens seemingly out of luck. I'll have to go and research the callers of readlink() but it seems like it should be always returning the POSIX target, since that's the only sane behavior in the face of old and new styles. Brian
