Mail Archives: cygwin/2003/11/15/16:10:33
--=-+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/--
- Raw text -