Re: [Gnu-arch-users] Arch On Cygwin(Win32)

[Michael Grubb]

At 10:12 AM 11/13/2003, Naushit Sakarvadia wrote:
> I also was working on Cygwin port.
> and ran into >256 byte path limit
>
> > - fix Cygwin to support longer paths
>
> So this 256 bye path limit is Cygwin Limitation or Win32 ?
> If its Cygwin problem. its serious and it should be fixed in Cygwin.
>
> So if we can get this fixed....Do you anybody know of any open issue?
>
> I dont understand why do you want to modify tar and gzip??
> I never saw any problem with tar and gzip on cygwin. Am I missing
> something??

At 10:12 AM 11/13/2003, you wrote:
> I also was working on Cygwin port.
> and ran into >256 byte path limit
>
> > - fix Cygwin to support longer paths
>
> So this 256 bye path limit is Cygwin Limitation or Win32 ?
> If its Cygwin problem. its serious and it should be fixed in Cygwin.
>
> So if we can get this fixed....Do you anybody know of any open issue?
>
> I dont understand why do you want to modify tar and gzip??
> I never saw any problem with tar and gzip on cygwin. Am I missing
> something??

        In short, yes.  You failed to read through the archives regarding
        this matter.  The limitation is in Cygwin.  Cygwin evidently uses
        an older Win32 API call which does not support the longer path names.
        Once Cygwin is fixed to use the new calling convention things should
        begin to work (this is how I understand the problem).  From what I've
        read in the API docs this is a trivial change.  However, I'm 
unfamiliar
        with Cygwin's code, (I'm not a C programmer), I've looked in the code
        for these system calls and can't find them anywhere (Old or new).  Of
        course this could be my ignorance getting in the way.  The solution
        proposed by Lode, is a work around for this limitation in cygwin.
        I am all for implementing a work around in arch for this cygwin
        limitation, because as I understand the situation the cygwin 
developers
        are unlikely to resolve this issue anytime in the near future.
        Though many on this list disagree with me, that platform proliferation
        should be a high priority.

<snip>

M Grubb