Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Thu, 15 Jun 2000 12:35:31 -0400
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Cygdrive Path Prefix Patch Issue
Message-ID: <20000615123531.F5388@cygnus.com>
Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com
Mail-Followup-To: cygwin-developers AT sourceware DOT cygnus DOT com
References: <20000615150243 DOT 27071 DOT qmail AT web116 DOT yahoomail DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20000615150243.27071.qmail@web116.yahoomail.com>; from earnie_boyd@yahoo.com on Thu, Jun 15, 2000 at 08:02:43AM -0700

On Thu, Jun 15, 2000 at 08:02:43AM -0700, Earnie Boyd wrote:
>--- Jason Tishler <Jason DOT Tishler AT dothill DOT com> wrote:
>-8<-
>> 
>> I looked into the df source -- specifically read_filesystem_list() in
>> fileutils/lib/mountlist.c.  The current implementation would attempt
>> to interpret the cygdrive prefixes as ordinary file systems.
>> 
>> > and if there is a way to work around it.
>> 
>> I can add Cygwin specific code to ignore the cygdrive prefixes.  But,
>> I'm concerned that all other code that uses getmntent() would need a
>> similar change.
>> 
>> DJ Delorie wrote:
>> > Could getmntent be extended to return, as one of the entries, the
>> > automount path?
>> 
>> Implementing the above is certainly doable but will be fairly ugly.
>> 
>> Do we really want to go with this approach?  If the consensus is yes,
>> then I will do so.  Are there any other, hopefully better, alternatives
>> before I dive in?
>
>This certainly sounds like we *don't* want to use this approach.  AFAICT a new
>function named something like getumntent() would be better suited.

Yeah, I guess I have to agree.  I don't like adding cygwin_foo stuff if I can
help it but if there is no other alternative, then I guess that's what we
should do.

Hmm.  I wonder if the 'sysconf' interface has anything like this.

cgf