This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [patch] cygcheck.cc update for cygpath()
On Mar 10 15:08, Christopher Faylor wrote:
> However, I don't understand what a mingw app would see when it is started
> from Cygwin now. What would a standard windows app think that its cwd would
> be if it's cd'ed deep into a 32K long path.
Right now, Cygwin copies its CWD into the user parameter block, as long
as it is < 260 chars. When a Cygwin process cd's into a long path, this
copy just doesn't happen. So, the cwd of a MingW application started
from that Cygwin process would be the last Cygwin cwd path < 260
characters within this process tree.
This is what I started to discuss in
http://cygwin.com/ml/cygwin-developers/2007-10/msg00008.html
As a result of this discussion we had five options what to do when
spawning a native app from Cygwin, if the Cygwin process is in a long
cwd:
1. Return ENAMETOOLONG and don't start the native child.
2. CWD for the native child is set to $SYSTEMROOT.
3. CWD is set to the root of the current drive (either X:\ or
\\server\share).
4. CWD is set to the longest leading path component of CWD which still
fits into MAX_PATH.
5. Start the native app in the last CWD we were in which was < MAX_PATH.
Implemented right now is option 5 since that's the most easy to implement
because it practically didn't need any changes to the existing code.
The general consensus seemed to lean towards option 1 or 3, so maybe
this whole problem is going to be a non-issue...?
Sigh, somehow it would be a pity if our own tools suffer from that
restriction.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat