This is the mail archive of the
mailing list for the Cygwin project.
Re: large paths in cygwin.
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at cygwin dot com
- Date: Sat, 30 Jun 2007 10:38:23 -0700
- Subject: Re: large paths in cygwin.
- References: <firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
> When will Cygwin get the ability to use large paths?
> What are the roadblocks to Cygwin getting this feature?
The small limit comes from the ANSI version of the Win32 API. In order
to be free of the limit Cygwin would have to consistently use the
unicode versions of all Win32 API calls. And to do that right[*] means
converting Cygwin to store all paths as UCS-2 internally rather than
simple char arrays, which means updating/fixing any code that handles
paths, of which there is a lot (and some of it quite hairy.)
> I've been using rsync in Cygwin, and hit the limits of windows ASCII
> file names.
Yes, it sucks.
> I've seen some discussion about Cygwin getting 2^15 char long paths, but
> it doesn't appear to be present in current release Cygwin, or on CVS.
It's a lot of work.
> And yet for opening, and creating files and directories, NtCreateFile
> seems to be used.
> This seems to imply it should be possible to change the CYG_MAX_PATH
> variable to a larger value, and get large part support for free.
> Of course I get the feeling I've missed something ;)
That is just one place. There are still oodles of places where Cygwin
calls the ANSI version of various Windows APIs, all of which are limited
to PATH_MAX of 260, so just arbitrarily upping a define would cause a
lot of things to break.
[*] Where right is defined as not just doing the hacky thing of tacking
on a wide<->narrow conversion in front of any w32api call.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html