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
X-WM-Posted-At:	avacado.atomice.net; Fri, 3 May 02 11:22:38 +0100
Message-ID:	<003001c1f28c$73421b60$0100a8c0@advent02>
From:	"Chris January" <chris AT atomice DOT net>
To:	<cygwin AT cygwin DOT com>
References:	<20020502045844 DOT GA32468 AT redhat DOT com> <004201c1f248$91711940$0100a8c0 AT advent02> <20020503024731 DOT GB17660 AT redhat DOT com>
Subject:	Re: New snapshot with significant new functionality
Date:	Fri, 3 May 2002 11:22:38 +0100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000

> >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.
However it is my opinion that the directory /proc should inherit the
permissions of the real directory if it exists. i.e. ls -ld /proc shows the
real directory's permissions.  This is consistent with the semantics of file
system mounting on Unices. However since the permissions aren't checked at
the moment, this is purely academic.

Chris



--
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/

- Raw text -