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

[Tom Lord]

    > From: Michael Grubb <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).  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?

Thank you for explaining the issue more clearly than I have heard it
explained in the past.  I was under the impression that the 280
character limit was a limit on the depth of file system in cygwin.

I think that there is a systematic way to solve 99% of the problem,
and that the rest will be straightforward but a special-case solution.

As you can see, tla source code does not call file system system calls
directly.   Instead, it use two families of functions from the
hackerlab library (src/hackerlab):  the `safe_*' functions and the
`vu_*' functions.   (E.g., `safe_open ()' or `vu_open ()' rather than
`open ()'.)

The `safe_*' functions are themselves a layer over he `vu_*'
functions.

The `vu_' stands for ``virtual unix''.  Those functions provide a
mechanism for programs to impose their own layer of code between the
system calls and the rest of the application.

When you call a `vu_*' function that takes a filename, a list of
regexps is compared to the filename.   A matching regexp corresponds
to a particular dispatch table, where the appropriate implementation
of that `vu_*' function can be found.   For example, you could give a
special meaning to filenames of the form ``ftp://HOST/path'' ...

When you call a `vu_*' function that takes a file descriptor, the
dispatch table for that descriptor is looked up in a table.   Usually,
that dispatch table is the same one that was found for the
corresponding file name when the file was opened.

It seems to me that you should be able to write a dispatch table just
for cygwin.   The regexp for filenames using this dispatch table can
be simply ".*".    That dispatch table can do the chdir/fchdir
operations and path splitting needed to handle long path names.

The files "src/hackerlab/vu/vu-dash.[ch]" illustrate the basic
mechanics of implementing a new dispatch table.

That will _almost_ entirely solve the long-path problem.

What it won't solve is the case of passing long paths to GNU `diff',
`patch', and `diff3' as command line arguments when running those
programs as subprocesses.  (`tar' and `ssh' are also called as
subprocesses, but they are not passed long paths.)  There are three
calls to fix, which I'm sure can be found easily using `grep'.

For those programs, assuming that they don't already have built-in
support for long paths on cygwin, probably the thing to do is to copy
some of the argument files to temporary files in the current
directory.  Possibly you can get away with passing them '-' as an
input file and opening (using `safe_open') a descriptor to serve as
the program's stdin, instead of copying files.

Both the registering of the vu file namespace handler and the changes
to calling subprocesses (if file copying is needed) should obviously
be conditionally-compiled code.  Yuck. :-)

-t