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

[Brian Dessent <brian at dessent dot net>]

Corinna Vinschen wrote:

> Given that Cygwin changes to support long path names, I don't really
> like to see new code still using MAX_PATH and Win32 Ansi functions
> in the utils dir.

Regardless of this patch, path.cc:rel_vconcat() currently uses
GetCurrentDirectory() to resolve relative paths.  It would be nice if
rel_vconcat() (or really, cygpath()) had an interface that let the
caller supply a CWD instead, as that would bypass the whole issue of
length since what this patch is doing is simply setting CWD just so that
rel_vconcat() can then get it again.  I thought about doing it that way
but it seemed more invasive.

> I know that the Win32 cwd is always restricted to
> 259 chars.  However, there *is* a way to recognize the current working
> directory of the parent Cygwin application.
> 
> Bash as well as tcsh, as well as zsh (and probbaly pdksh, too) create an
> environment variable $PWD.  Maybe Cygwin should create $PWD for native
> apps if it's not already available through the parent shell.  I'd
> suggest that the Cygwin utils first try to fetch $PWD from the
> environment and use that as cwd.  Only if that fails, use
> GetCurrentDirectory.

I will work on a patch that both adds an interface to allow the caller
to supply a CWD as well as trying to use $PWD to get the value
otherwise.

> Never use SetCurrentDirectory, rather convert the path to an absolute
> path, prepend \\?\ and call the Win32 unicode functions (CreateFileW,
> etc).

Setting the CWD can be totally avoided I think, by the above replumbing.

> SYMLINK_MAX is PATH_MAX - 1 == 4095.
> 
> 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.

Brian