This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [patch] cygcheck.cc update for cygpath()
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