Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: Re: For masochists: the leap o faith
From: Robert Collins <rbcollins AT cygwin DOT com>
To: Brian Ford <ford AT vss DOT fsi DOT com>
Cc: cygwin AT cygwin DOT com
In-Reply-To: <Pine.GSO.4.56.0311151259270.922@eos>
References: <3FB4D81C DOT 6010808 AT cygwin DOT com> <3FB53BAE DOT 3000803 AT cygwin DOT com>
	 <20031114220708 DOT GA26100 AT redhat DOT com> <3FB55BCE DOT 8030304 AT cygwin DOT com>
	 <20031115044347 DOT GA29583 AT redhat DOT com> <1068883645 DOT 1109 DOT 122 DOT camel AT localhost>
	 <20031115164534 DOT GB3039 AT redhat DOT com> <20031115165229 DOT GA3296 AT redhat DOT com>
	 <Pine DOT GSO DOT 4 DOT 56 DOT 0311151259270 DOT 922 AT eos>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+uv2VT/yswJPlbEhugi/"
Message-Id: <1068930608.1109.172.camel@localhost>
Mime-Version: 1.0
Date: Sun, 16 Nov 2003 08:10:08 +1100

--=-+uv2VT/yswJPlbEhugi/
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2003-11-16 at 06:09, Brian Ford wrote:
> On Sat, 15 Nov 2003, Christopher Faylor wrote:
>=20
> > Btw, I've moved this discussion here from cygwin-patches because we are
> > talking about a change which could impact a number of people.  Robert i=
s
> > submitting patches which increase the maximum path length for NT-class
> > systems.
> >
> > My concern is that PATH_MAX will be increased for this change.  It will
> > no longer reflect the win32 api MAX_PATH value and I was wondering if
> > that would cause problems for existing applications.
> >
> >
> Well, since your soliciting opinions...
>=20
> I don't have much of one other than I'd really prefer to keep
> PATH_MAX/MAX_PATH and define them to the largest allowable path so they
> can still be used for sizing arrays.  I don't really care if that lenght
> is not always supported.

MAX_PATH -will not- change. It's a win32 define, not a cygwin or posix
define.

If you want to use static arrays, and don't care about supporting the
full system facilities: just use an arbitrary figure that is big enough
for your users. Remember: 640K is all you need.

> I would assume that any application that goes to the trouble of doing
> something other than bailing with an error in that case should actually
> use pathconf.

Right. The posix specs (a couple of links to opengroup are in the thread
in cygwin-patches) place the following limits:
1) if defined PATH_MAX must be the largest value [f]pathconf will
return.
2) if PATH_MAX isn't defined, and [f]pathconf doesn't have an arbitrary
limit, then calling pathconf on _PC_PATH_MAX where no limit exists can
return -1 and clear errno. For us calling pathconf _PC_PATH_MAX on / ,
we can return the current global maximum. (Note that the global maximum
we can support is actually the DOS maximum path length + the path from
the cygwin mount table. I.e. if you mount d:\XXXX[250 times]\YYYY[250
times]\ZZZZ[250 time] at /foo, the max path from /foo is -NOT-
CYG_MAX_PATH (the new internal buffer size), but is rather:
CYG_MAX_PATH=20
  - 4 (the \\?\ prefix)
  - 1 (NULL)
  - len (d:\XXXX[250 times]\YYYY[250 times]\ZZZZ[250 times]
 =3D=3D=3D=3D=3D
  ~=3D CYG_MAX_PATH - 760.

encouraging the use of MAX_PATH when we have this underlying variability
is not a good thing IMO.

Chris has noted that posixly correct behaviour and common practice may
diverge. I think for this scenario, that posix behaviour allows the most
accurate representation of the variety programs may encounter on cygwin
at runtime. Therefore we'll get the best results (and perhaps uncover a
few portability bugs) going that way.

We have two choices (no particular order of preference):
a) make MAX_PATH and posix friends the maximum length path cygwin will
accept/return. Return ENAMETOOLONG on path calls on win9x, or winnt
FAT[32] calls. Update pathconf to return appropriate values.
b) blow away MAX_PATH and MAXPATHLEN so that programs using cygwin
fallback to pathconf, or 'good enough for me' static arrays.  Update
pathconf to return appropriate values.

I've no particular preference: either will support the change reasonably
well. I'm mainly keen to see the thing inside cygwin, able to be used
and understood.

Rob
--=20
GPG key available at: <http://www.robertcollins.net/keys.txt>.

--=-+uv2VT/yswJPlbEhugi/
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/tpYvI5+kQ8LJcoIRAnSBAJ9ptcR+P5ScXo3WpiBcbxaf/mZcfgCgu2tG
oAwECDSAwu+YyogMUO4NVy0=
=UHHb
-----END PGP SIGNATURE-----

--=-+uv2VT/yswJPlbEhugi/--