On Mar 10 21:10, Corinna Vinschen wrote: > 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.
I applied a patch which enables option 1 for all long and virtual paths. So, for now, we don't have to take paths > MAX_PATH into account for any MingW utility. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat