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:

> > > 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


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