Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 2 May 2002 22:47:31 -0400
From: Christopher Faylor <cgf-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: New snapshot with significant new functionality
Message-ID: <20020503024731.GB17660@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20020502045844 DOT GA32468 AT redhat DOT com> <004201c1f248$91711940$0100a8c0 AT advent02>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004201c1f248$91711940$0100a8c0@advent02>
User-Agent: Mutt/1.3.23.1i

On Fri, May 03, 2002 at 03:16:43AM +0100, Chris January wrote:
>I see you have made the fhandler_virtual, etc.  functions use vanilla
>path_conv instead of normalized_path or whatever I called it
>originally.

Yes.  This is consistent with all of the other fhandler functions.

>This relies on path_conv::check returning the normalised posix path instead
>of the native path as it usually does. However this breaks stuff like mkdir
>/proc badly (in this case, a directory called 'proc' gets created in the
>root of C:\). The fix is to go back to using the normalised path explicitly
>(i.e. replacing pc with pc.normalized_path) in fhandler_virtual.cc, etc. and
>removing the strcpy (path, path_copy) line from path.cc.

The real fix is to use the get_name () method, which I'd started doing
when I realized that I'd reinvented the wheel in consolidating your
patch.  That seems to work fine.  I've finished converting everything (I
hope) to get_name() and checked things in.

I removed my strcpy kludge.

>I also need an opinion on how the directory /proc should be treated.
>Either:
>    i) a real directory called /proc hides the virtual directory /proc
>completely
>    ii) the virtual directory /proc hides the real directory /proc
>completely (other than showing up in a directory listing of /)
>    iii) the virtual directory /proc inherits the permissions and ownership
>of the real directory /proc if it exists
>    iv) the virtual directory /proc is only accessible if there exists a
>real directory /proc (combined with one of the above)

For now, I'd say that it should work just like /cygdrive.  You can
create it but ls /proc still shows the contents of the special directory
not an empty directory.  That's what I've implemented.  Removing your
zeroing of the buffer allowed that, just like it does for the cygdrive
case.

Long term, this kind of stuff should be somehow "mountable".  Corinna and
DJ had a plan for doing something like this at one time.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/