Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Subject: Re: Mysterious gdb behavior.
From: Robert Collins <rbcollins AT cygwin DOT com>
To: derbyshire AT globalserve DOT net
Cc: cygwin AT cygwin DOT com
In-Reply-To: <3D446034.7038.56AD94A7@localhost>
References: <1027903418 DOT 7873 DOT 12 DOT camel AT lifelesswks> 
	<3D446034 DOT 7038 DOT 56AD94A7 AT localhost>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-MGwO2npI6dfupeUORVaN"
Date: 29 Jul 2002 12:02:36 +1000
Message-Id: <1027908156.7877.16.camel@lifelesswks>
Mime-Version: 1.0

--=-MGwO2npI6dfupeUORVaN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-07-29 at 11:20, Paul Derbyshire wrote:
> When I'm not given adequate information I'm forced to guess the rest,=20
> unlike you telepaths who can pluck the missing information out of a=20
> passing bystander's mind. :P Or, at least, pluck the *fact* that you=20
> need more information and some idea of what it is out of someone's=20
> mind and then formulate a Google search query.

Against my better judgement I'm getting pulled back into this thread.
However, I'm now addressing your assertion about inadequate information,
and hopefully showing you why I've bowed out of the main thread. The
example laid out below is not the only example of baseless assertions
that could be demonstrated, it is just (IMO) the clearest.

You seem like an intelligent articulate guy, so I hope you will learn
from the below.

Please follow the following references:
1) You suggest using short file names under certain circumstances.
Specifically you claim "windows has handily provided these for ALL such
path names" (emphasis mine).
http://cygwin.com/ml/cygwin/2002-07/msg02207.html

2) I assert that that those short names DO NOT ALWAYS exist. I don't
provide a reference, because I am assuming ignorance on your part, and
that you will either assume I have reason to assert differently on this
topic, or will *research* to prove your point.=20
http://cygwin.com/ml/cygwin/2002-07/msg02208.html

3) You assert "They do. Windows ALWAYS assigns an 8.3 version of a
filename that has a long name, a long extension, multiple extensions
(foo.tar.gz, etc.), or an unusual character in the name such as a
space." Again, emphasis is mine. We are now both asserting different
things.=20
http://cygwin.com/ml/cygwin/2002-07/msg02242.html

4) I provide a reference to a web page that is a technical document from
Microsoft that demonstrates how to disable the automatic creation of
short file names in some circumstances. This disproves your assertions
in 1) and 3), and proves 2). It also demonstrates that you have not
followed up the reference provided, and are wasting my time. At this
point in the conversation I assume that you made assertions from a
position of ignorance, with no research made (into either FAT32 file
system layout, or NTFS file system layout, or NT kernel behaviour with
respect to long file names). Generalising this I conclude that
attempting to correct the other assertions you are making about the
potential solutions will be met unresearched incorrect statements, which
you will refuse to believe the correctness of, and will not follow
provided links that would correct your information.
http://cygwin.com/ml/cygwin/2002-07/msg02243.html

5) You claim that a Long filename without a short file name will cause
all sorts of trouble, even though you have been provided with
documentation from Microsoft about a supported method for creating just
such a situation.=20
http://cygwin.com/ml/cygwin/2002-07/msg02247.html

In summary:
1) Always makes SFN (short file names)
2) Not always.
3) does too.
4) doesn't. See here.
5) Oh, well no one would do such a thing it would break many
applications.

Sorry Paul, I've used NT systems with 8.3 filename generation disabled,
and it works *just fine*.

You were provided with an external link to authoritative documentation
about the topic. No guessing was needed about whether SFN are *always*
created or not. No guessing was needed about compatability issues and
kernel support.

In the light of this, I assume that you have not attempted the archival
search for topic relating to home directories with spaces in them, which
was the first thing I suggested. Or that if you have done such a search,
and found the relevant post, you've happily ignored it because 'you
imagine it will cause problems'.

Rob

--=-MGwO2npI6dfupeUORVaN
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEABECAAYFAj1EojsACgkQI5+kQ8LJcoKG6QCZATGhDRkO6JLYzlLSyqsqy32/
wQwAoIll9F6PzQPsk75YZSStYFxGXjt+
=SWyQ
-----END PGP SIGNATURE-----

--=-MGwO2npI6dfupeUORVaN--