Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Need name and functionality suggestions for a new utility X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 24 Oct 2001 15:33:15 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need name and functionality suggestions for a new utility Thread-Index: AcFcTEcpJx3J8MBjQ4GEhhmCF5SwWwAAAmHgAAA3nBA= From: "Robert Collins" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id f9O5PHv05833 > > I don't think I want to go that crazy. This is just for > > cygwin objects. > > Theoretically, the whole mount table will look different so mmap > > objects, at least, will refer to different paths anyway. > > Ahh, touch /t > run prog that mmaps to /t > will conflict unless the named objects are created using > win32 paths as > their basis. And for canonical behaviour using the unix path > makes sense > to me. > I should mention why I'm concerned: The first thing that will happen when this utility is available is that anyone having multiple-cygwin-cross-comple-vendor-tools-issues (remember the list recently) will try it. If it's suitable for running an isolated test suite, but not for production side by side use, I can just imagine the traffic volume. Rob