Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Date: Mon, 13 Nov 2000 14:35:22 -0500 Message-Id: <200011131935.OAA26182@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj@envy.delorie.com using -f From: DJ Delorie To: earnie_boyd@yahoo.com CC: cygwin@sourceware.cygnus.com In-reply-to: <20001113193253.7701.qmail@web122.yahoomail.com> (message from Earnie Boyd on Mon, 13 Nov 2000 11:32:53 -0800 (PST)) Subject: Re: setup drops mount? References: <20001113193253.7701.qmail@web122.yahoomail.com> > Assuming what? That the bin directory isn't relative to the user selected root > mount path? Or that the mounted bin directory is actually not contained within > the d:\foo (where d:\foo is the user chosen root mount path) directory but is > mounted somewhere else? The way setup operates today, you're screwed if you > move the bin directory anyway and try to update. So, maybe if this is an > update the translation should happen anyway. But, ... Yes, this is what I was talking about. If you want to add code that retains existing mount points *if* they reflect the "usual" locations of those directories (i.e. they exist just to set flags), it's OK with me. That should be simpler than full support for arbitrary mount tables. -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com