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
