RE: [Gnu-arch-users] Cross Platform Path issues

[Parker, Ron]

This goes along with the "TLA on Cygwin" thread from a few days ago,
http://mail.gnu.org/archive/html/gnu-arch-users/2003-09/threads.html#01107.

> -----Original Message-----
> From: Michael Grubb [mailto:address@hidden

> There is a discrepancy of allowed path lengths between the 
> cygwin mkdir and 
> the native linux mkdir command.  The linux command will take 
> 4105 character 
> path names, the windows and cygwin will only take around 280 
> characters.
> This is not to say that paths may not be deeper than what is 
> allowed on a 
> single command only commands that must create very deep trees 
> should do so 
> with this limit in mind (via chdir).  

This isn't strictly an accurate characterization.  The limit is MAX_PATH,
which currently is 260 on Cygwin.  There are numerous places in the Cygwin
"kernel" where the full-normalized path is checked against MAX_PATH and
ENAMETOOLONG is returned if that limit is exceeded.  See
normalize_posix_path in path.cc at line 199,
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc?annot
ate=1.269&cvsroot=src.  This function gets the cwd, line 217, concatenates
the supplied file name onto it, while loop at line 251, and then proceeds to
normalize the path and check its entire length against MAX_PATH, line 294.

> The problem is the same 
> for both 
> platforms it is just highly unlikely one will experience this 
> behavior on a 
> UNIX machine.  I'm not entirely sure as to the best way to 
> fix this, I 
> would be happy to give it a try though I'm little more than a 
> hacker when 
> it comes to C.  Ideas, anyone ... anyone?

After trading email on the list with -t about this, I made some local
changes to the TLA source in an attempt to work around this issue.  These
changes were specifically related to using chdir and shortening the path to
files that were only used locally.  I made pretty good headway, but it
becomes nasty when 'what-changed' and 'commit' extract TAR files of patches.
Tar itself will hit the ENAMETOOLONG issue as well, causing it to return
errors to TLA.  This is not just a TLA issue.  It affects most of the
programs that run on Cygwin.  TLA just happens to expose these Cygwin
specific problems through tar and company due to its use of long-nested
directory names.

So ideas?  After pestering Chris Faylor and others for years over the
handling of long paths on Cygwin, I am working on a set of patches to Cygwin
that will resolve this issue for all NT-based operating systems at least on
NTFS file systems.  I have attempted this in the past, but the problem was
that there was no discrete place to make the change and I was touching code
all over Cygwin adding and removing '\\?\' from the beginning of file names
and converting them back and forth between wchar_t and char.  It does look
like Cygwin has been cleaned up greatly over the last few years, so
hopefully I can make fairly surgical changes this time without too much
pain.

What little information exists on handling long path names may be found
scattered throughout the MSDN library.  It is alluded to by
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base
/naming_a_file.asp  and talked about a little more in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base
/createfile.asp and other locations.

I have submitted code to Cygwin in the ancient past, so there is some chance
of having my new code accepted as well.  But don't hold your breath on the
time frame.  In order for my changes to have an impact on tar, patch, etc.
it may be necessary to rebuild those tools as well.  If this is the case I
would expect that it will be much more difficult to get CGF to accept the
patches.  At the very least I am hoping that I can get him to accept them
and then petition the maintainers of the various tools which TLA depends
upon to update their released binaries as well.

Also at issue is that Windows Explorer blows up attempting to access these
deep paths.  That may also lessen the chances that my patches will be
accepted as many associated with Cygwin desire as much interoperability
between Cygwin and Win32 applications as possible.

Anyway, that is what I am working on in my limited spare time.  I hope to
have something soon.  I think this is the solution most acceptable to -t and
most like to produce the desired results in a short amount of time.