From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22723 invoked by alias); 24 Sep 2003 21:32:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 22709 invoked from network); 24 Sep 2003 21:32:18 -0000 Received: from unknown (HELO lifelesslap.robertcollins.net) (220.240.7.219) by sources.redhat.com with SMTP; 24 Sep 2003 21:32:18 -0000 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 1A2HF7-0000XQ-00; Thu, 25 Sep 2003 07:32:13 +1000 Subject: Re: Deep directory support From: Robert Collins To: "Parker, Ron" Cc: cygwin@cygwin.com In-Reply-To: <71A0F7B0F1F4F94F85F3D64C4BD0CCFE02BF2478@bmkc1svmail01.am.mfg> References: <71A0F7B0F1F4F94F85F3D64C4BD0CCFE02BF2478@bmkc1svmail01.am.mfg> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uJM9wSdnf8LZ9OfyWmtk" Message-Id: <1064439132.938.56.camel@localhost> Mime-Version: 1.0 Date: Wed, 24 Sep 2003 21:47:00 -0000 X-SW-Source: 2003-09/txt/msg01564.txt.bz2 --=-uJM9wSdnf8LZ9OfyWmtk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 3860 Quoting the full message as it was originally posted to a different list. On Thu, 2003-09-25 at 02:23, Parker, Ron wrote: > Please read beyond the next paragraph before hitting delete. Odd file na= mes > are not the issue here, so bare with my for a minute. I'll get to the po= int > shortly. >=20 > Once upon a time I messed with making changes to Cygwin to allow protected > file names like "aux" to work with Cygwin. At the time I was looking into > using the UNICODE file functions and prepending '\\?\' to the file's name= in > order to accomplish this. On NT-based systems this basically goes direct= ly > to the device namespace, bypassing a lot of the filtering and limitations= of > the Win32 subsystem. I never submitted this code, because it was ugly, > required touching Cygwin all over the place and I didn't have the time to > implement it cleanly. >=20 > However, of late I have been playing with arch (specifically tla) and have > run into an issue with Cygwin. Namely MAX_PATH is 260 and it is common f= or > arch repositories to have tar files that are deeper than this. I have tr= ied > working around these issues in tla, but normalize_posix_path and other ar= eas > of Cygwin that return ENAMETOOLONG keep causing errors in tar when > attempting to extract some of these files. >=20 > I am working on some Cygwin patches and would like input and some idea of > whether my idea has an ice cube's chance in hell of being accepted or not. > It basically boils down to doing something like what I originally thought= of > for files with protected device names. At this point my patches arbitrar= ily > increase MAX_PATH to 4096 and map most of the CreateFile calls to a funct= ion > provisionally called createfile. If is_winnt, this function prepends '\\= ?\' > to the absolute path name, converts that to UNICODE and calls CreateFileW, > otherwise it just passes through to CreateFile(A). The 4096 is just to > match Linux, the SDK is not specific on how close to 32Ki you can get bef= ore > things blow up, so I am being conservative. >=20 > I realize that CreateFile is not the only thing that I will have to deal > with for this to be a complete solution. I will need to do something > similar for other functions as well, but I wanted some input before creat= ing > an unacceptable solution. Is this a desirable approach to the issue. >=20 > One nasty side-effect of this is that Explorer will blow up drilling down > into a deep directory structure and it gets errors attempting to delete a > deep directory structure. Both are Explorer bugs, IMO. The deleting iss= ue > can be worked around in Explorer by moving subdirectories in the deep > structure to a higher level, say the drive's root directory, and deleting > them from there. >=20 > Any thoughts or input? Regarding the explorer issues, that doesn't bother me: we'd still be very much within the recommendations from MSDN. If MS can't do their programs well... so be it. You will *need* to track CVS, there are changes in the related mechanisms underway at the moment that will likely collide. Doing this makes a lot of sense to me, and I'll happily assist by reviewing any patches. Be sure not to break special use cases of CreateFile (i.e. memory mapping etc) which may still be that deep... Don't overload is_winnt for this, add a new capability - long_pathnames or something similar. Lastly, small patches are better than big ones - one patch, one concept. I.e. as a starting point " =3D=3D=3D * Use cygwin_CreateFile throughout.=20 * (cygwin_CreateFile): new method, thunks through to the windows Wide or ASCII IO calls depending on long_pathnames. =3D=3D=3D Bundling up a large number of changes will lead to extra work, I assure you. Rob --=20 GPG key available at: . --=-uJM9wSdnf8LZ9OfyWmtk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/cg1cI5+kQ8LJcoIRAhYqAKDLCehkMj2HIozIbjFBYKRzWJRDAwCfcDk6 FI1n5tO85i620dv9qLkJUc0= =IzHN -----END PGP SIGNATURE----- --=-uJM9wSdnf8LZ9OfyWmtk--