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 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