This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: CWD and long paths
- From: "Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>
- To: <cygwin-developers at cygwin dot com>
- Date: Fri, 12 Oct 2007 11:54:43 -0400
- Subject: Re: CWD and long paths
- References: <20071012113731.GG20400@calimero.vinschen.de>
----- Original Message -----
From: "Corinna Vinschen" <corinna-cygwin>
To: <cygwin-developers@>
Sent: Friday, October 12, 2007 7:37 AM
Subject: CWD and long paths
| Hi,
|
|
| as everybody is probably aware, NT can handle paths of up to 32K unicode
| characters length within the NT namespace. Many Win32 calls of the fooW
| family (taking utf-16 strings) can handle these long pathnames as well(*).
|
| The problem is, the SetCurrentDirectory function can *not* handle long
| path names and, generally spoken, Win32 can *not* handle current working
| directories of more than MAX_PATH (260) characters. The reason for this
| restriction is the fact that the per-process environment block (PEB),
| which is handled by the Win32 libraries, stores the CWD in a structure
| like this:
|
| struct {
| WCHAR path[MAX_PATH];
| HANDLE hdl;
| }
If the pathname is given in short form (8.3), does Window expand it before storing it in
cwd.path?
Another possibility is to do what we currently do if the cwd is a virtual cygwin directory, such
as /proc
At least that would be consistent and there have been no complaints AFAIK.
One is not supposed to launch Windows program from a directory that the program can't
understand.
Pierre