This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Deep directory support


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]