[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Grubb
Subject: Re: [Gnu-arch-users] Cross Platform Path issues
Date: Tue, 23 Sep 2003 16:21:05 -0500

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.

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.

GPG key available at: <>.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]