X-Spam-Check-By: sourceware.org Message-ID: <4686950F.E3D9ED56@dessent.net> Date: Sat, 30 Jun 2007 10:38:23 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: large paths in cygwin. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com btd6wi702 AT sneakemail DOT com wrote: > 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. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/