Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin-developers AT sources DOT redhat DOT com
Date:	Wed, 24 Oct 2001 01:41:42 -0400
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin-developers AT cygwin DOT com
Subject:	Re: Need name and functionality suggestions for a new utility
Message-ID:	<20011024014142.D14370@redhat.com>
Reply-To:	cygwin-developers AT cygwin DOT com
Mail-Followup-To:	cygwin-developers AT cygwin DOT com
References:	<EA18B9FA0FE4194AA2B4CDB91F73C0EF08F21B AT itdomain002 DOT itdomain DOT net DOT au>
Mime-Version:	1.0
In-Reply-To:	<EA18B9FA0FE4194AA2B4CDB91F73C0EF08F21B@itdomain002.itdomain.net.au>
User-Agent:	Mutt/1.3.21i

On Wed, Oct 24, 2001 at 03:33:15PM +1000, Robert Collins wrote:
>
>> > 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.

I still don't see the mmap issue but there may be some uses of naming
objects in cygwin that don't use shared_name().  I think I even
introduced one recently.  If so, they should be fixed.

You're right that I didn't think about the potential mailing list issues
surrounding this.  That's odd for me.  I guess I should go to bed.

If this isn't generally useful, then I can just make this Red
Hat-internal.  And, I'll send apologies to everyone for making you
think about this.  I think that it may have some general use, though.

For instance, I'm now testing a "GNUpro" release on my W2K system and
find that I can't track down bugs in the net release because it
conflicts with the running compilation.  This would alleviate that
problem.

So, this utility would be useful to cygwin developers at least.

However, I can see that people could try to use it to work around
release issues.  Brr...

"I upgraded to cygwin 1.5.1 and found that I couldn't rsync my system
anymore so I moved rsync into a directory with cygwin 1.1.4 and used
cygisolate to run it.  It works great except for the fact that I can't
find the files that rsync has copied to my system.  What gives?"

cgf

- Raw text -