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

[Michael Grubb]

At 04:03 PM 9/23/2003, you wrote:
> On Wed, 2003-09-24 at 01:51, Tom Lord wrote:
> >     > 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.
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createdirectory.asp
>
> Cygwin uses the A variation - the win9x compatible call.
>
> MAX_PATH is used throughout the cygwin source code. Even if chaining
> through with shorter relative paths 'work's' (which I doubt), the file
> name canonicalisation process used in mount table resolution and symlink
> processing will still fail.
>
> Your impression that 280 characters is the limit, is correct.
>
> And for the Nth time: this can be solved, and the best place is almost
> certainly in cygwin itself.

But the problem is not an inherent Cygwin problem. (It's not an arch 
problem, come to that.)
It is a limitation of the underlying platform.  No matter how cygwin does 
what it does, it can never
overcome this problem, until Microsoft fixes this limitation.  I've run my 
tests using both cygwin tools and the windows command line tools, and 
(painfully enough) the windows explorer, all three gave me the same results.
Even if there is a cygwin work around, it is pointless, as the cygwin tools 
would be the only ones that could look at /manipulate files in such a 
tree.  My thought is that instead of trying to go about effecting changes 
in two very large pieces of software(Windows,Cygwin) (one which we have 
much more influence over than the other (i.i.e.. we have 000000 control 
over Microsoft, and (0 > control < 1) over cygwin) we can try to get arch 
to work on both systems.
Which in my opinion is a much more attainable goal.  Not to mention that 
even if we were to effect a change the provides a cygwin work around to 
this path length problem, we could wait weeks, months, or years to see the 
benefits.
But I seriously doubt we would see any motion in days.

I know that Tom is reluctant to give up his 
cat/cat--branch/cat--branch--ver  directory structure (I really don't know 
why, I'm sure he has his reasons, none of which require that I 
understand)  but realistically that syntax is redundant, unneeded and far 
easier to change than any of the other pieces of software mentioned previously.

At any rate I guess we need to see what his final thoughts on the subject are.

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