Re: Deep directory support

Re: Deep directory support

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 3883 bytes --]

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 names
> are not the issue here, so bare with my for a minute.  I'll get to the point
> shortly.
> 
> 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 directly
> 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.
> 
> 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 for
> arch repositories to have tar files that are deeper than this.  I have tried
> working around these issues in tla, but normalize_posix_path and other areas
> of Cygwin that return ENAMETOOLONG keep causing errors in tar when
> attempting to extract some of these files.
> 
> 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 arbitrarily
> increase MAX_PATH to 4096 and map most of the CreateFile calls to a function
> 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 before
> things blow up, so I am being conservative.
> 
> 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 creating
> an unacceptable solution.  Is this a desirable approach to the issue.
> 
> 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 issue
> 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.
> 
> 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 "
===
    * Use cygwin_CreateFile throughout. 
    * <x.cc> (cygwin_CreateFile): new method, thunks through to
      the windows Wide or ASCII  IO calls depending on long_pathnames.
===

Bundling up a large number of changes will lead to extra work, I assure
you.

Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]