Re: cygpath -w converts relative paths to absolute windows paths

[Thomas Wolff <towo at towo dot net>]

Am 13.02.2017 um 16:16 schrieb Corinna Vinschen:
> On Feb 12 18:38, Thomas Wolff wrote:
> > Am 12.02.2017 um 12:23 schrieb Corinna Vinschen:
> > > On Feb  7 14:35, Roger Qiu wrote:
> > > > Hi,
> > > >
> > > > I've found that `cygpath --windows '../` will give back an absolute windows
> > > > path.
> > > >
> > > > I thought this would only happen if you provide the `--absolute` flag, or
> > > > when the path is a special cygwin path.
> > > >
> > > > But this occurs just for normal directories.
> > > >
> > > > I have come across a situation where I need to convert ntfs symlinks to unix
> > > > symlinks and back. Sometimes these symlinks have relative paths them. Now by
> > > > using cygpath --windows, I get back absolute paths, which means the
> > > > integrity of the symlink isn't preserved.
> > > >
> > > > Can `cygpath --windows '../directory'` give back `..\directory` for paths
> > > > aren't special cygwin paths? These relative backslashes are supported in
> > > > Windows right now.
> > > Not easily.  All paths are evaluated as absolute paths inside Cygwin.
> > > The result of the path conversion is always an absolute path. A relative
> > > path is generated from there by checking if the path prefix in POSIX
> > > notation is identical to the current working directory.  If not, the
> > > path stays absolute.  Naturally, if you use a "..", the resulting path
> > > does not match the CWD anymore, so you're out.
> > How about converting getcwd(), too, and comparing that?
> Converting to what?  And how's that different from what I describe above?
I was looking at path.cc, function mkrelpath, and (without tracing 
anything) assumed this would be the relevant function and had the 
impression that, when comparing path_prefix_p (cwd_win32, path, ...), 
path might be "normalized" (resolving links and folding ".." components) 
while cwd_win32 might not. If that's the case, it might be sufficient to 
"normalize" cwd_win32 as well.

> Btw., did you see https://cygwin.com/ml/cygwin/2017-01/msg00404.html?
No, I hadn't, sorry. Will respond there.
------
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple