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

[John Kinson]

I'd been spending some time making the same changes to Cygwin, but gave 
up when the scale of the task became apparent.  Cygwin uses both 
PATH_MAX and MAX_PATH literals, and the side effects from changing these 
caused core dumps in other areas.  This is a high-risk change to Cygwin, 
which has already been pointed out.

Having looked at the POSIX spec though, I'm not sure Cygwin should be 
changed at all.  The spec states (see 
http://www.opengroup.org/onlinepubs/007904975/basedefs/limits.h.html) 
that PATH_MAX should have a Minimum Acceptable Value of _POSIX_PATH_MAX. 
 _POSIX_PATH_MAX is defined by POSIX to be 256.

POSIX also states the following:

    Implementations may choose any appropriate value for each
    limit, provided it is not more restrictive than the Minimum
    Acceptable Values listed below.  Symbolic constant names
    beginning with _POSIX may be found in <unistd.h>.

    Applications should not assume any particular value for a
    limit. To achieve maximum portability, an application should
    not require more resource than the Minimum Acceptable Value
    quantity. However, an application wishing to avail itself
    of the full amount of a resource available on an
    implementation may make use of the value given in
    <limits.h> on that particular implementation, by using the
    symbolic names listed below.

    ...

My interpretation of the above is that Cygwin and Windows are perfectly 
POSIX-compliant in meeting the 256 byte MAV value.  In relying on the 
Linux implementation of PATH_MAX (set in /usr/include/linux/limits.h to 
4096, although tla just has 4096 hard coded as a magic value), Tom 
compromised the portability of arch.  I would argue that the correct 
change is to rework arch to confine itself to the POSIX minimum value.

Even changing the category/branch/version replication would probably not 
be enough to guarantee that the 256 character limit was not exceeded.  A 
more fundamental restructuring is needed.  This is obviously a large 
change, with backwards compatibility issues, so I wouldn't expect Tom to 
be willing to do this.

Having said that, if an arch redesign does not occur, then wouldn't it 
be far safer to implement the hackerlab vu_ calls to use the "W" Win32 
directory calls directly, rather than change Cygwin?  I just hacked 
successfully safe_mkdir to call CreateDirectoryW as a proof of concept, 
and this would seem *much* easier than the Cygwin patch...  Any 
drawbacks to this approach?

JK

Parker, Ron wrote:
>  > -----Original Message-----
>  > From: Robert Collins [mailto:address@hidden
>
>  > Well, I'm happy for you to shoot over the patches to me as they are.
>  > I'll see what they do for me :).
>
> You asked for it.  Here are 5 patches against cygwin 1.5.5-1:
>
> 01-add-cygwin-create-file.diff.gz
>         Adds cygwin_create_file and changes all CreateFile references to 
> use
> it.
>
> 02-add-cygwin-create-directory.diff.gz
>         Ditto for cygwin_create_directory.
>
> 03-use-unicode.diff.gz
>         Implement calling CreateFileW and CreateDirectoryW for all local
> file system files using the "\\?\" prefix.
>
> 04-maxpath.diff.gz
>         Raise MAXPATH from 260 to 4096.
>
> xx-diagnostics.diff.gz
>         Diagnostic code for createfile.cc that I used when necessary.  
> It is
> even commented out in the diff.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/


--
http://www.yellowradio.com/
What if the Hokey Cokey really _is_ what it's all about?