Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <0f9801c14549$1ea8e980$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Ronald Landheer" <info AT rlsystems DOT net>,
   "Corinna Vinschen" <cygwin AT cygwin DOT com>
References: <NFBBLOMHALONCDMPGBLFKEELCCAA DOT info AT rlsystems DOT net>
Subject: Re: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)
Date: Tue, 25 Sep 2001 08:34:48 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 24 Sep 2001 22:42:41.0990 (UTC) FILETIME=[3870D660:01C1454A]

Precedence is a good point: here's what I suggest:

mount points have top precedence -
if we mount fhandler_devfs at /dev then
* stat() /dev goes to fhandler_devfs.
* opendir and readdir() in / show data from fhandler_devfs for the dev
entry. (whether it exists in the / fhandlers namespace or not).

or more generally:
each mount point is the top of a namespace. The root of the cygwin
namespace is '/'.
each mount point has an associated fhandler class.

For a given mount point m, and fhandler class f,
* open()/stat()/write() of m always goes to f.
* readdir() of the namespace level above m, always includes m, with stat
data from f.

Rob

----- Original Message -----
From: "Ronald Landheer" <info AT rlsystems DOT net>
To: "Corinna Vinschen" <cygwin AT cygwin DOT com>
Sent: Tuesday, September 25, 2001 5:24 AM
Subject: RE: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)


Corinna wrote:

>> Is that more or less clear?
> More or less.  How shall that work correctly?  Assume a user
> creates a /dev/tty file.  ls -l /dev/tty results in
>
> crw-rw-rw-    1 root     root       5,   1 Sep 24 14:54 /dev/tty
>
> and the listing of the directory shows that entry, too.  Then the
> fhandler wants to list the devices.  It would list tty again unless
> it would check the listing of the real device for legal device
> entries and marks tty as already listed or so.
It would have to do that anyway (IMHO): as ye never know what a user
might be up to, it would have to check whether actual files &
directories exist before listing the magic ones. The only problem I
forsee is that they might start conflicting with eachother - i.e. if I
make a *file* called /dev/tty and I write stuff to it, it might end up
in the file in stead of the device.

I wouldn't mind having the fhandler just not allow actual file vs.
device conflicts - let the "magic" one override the actual one, and
remove the actual one if it's offensive. /dev is no place for files
anyway - it's like storing data in a void, storing icecream in a
volcano: it doesn't last, it's not a good idea, and noone in his/her
right mind would do it.. Symlinks are another matter, but the same
precedence would apply: symlinks are meant to make life a bit easier,
but don't contain any actual data, so if an magic dir would conflict
with a symlink, the symlink would have to go..

Perhaps a force option/flag would be nice for this, though - so as to
protect the unwitting (non-reading; documentation-illiterate) user a
bit..

> I don't want to define special requirements here.  I'm just thinking
> that a file system fhandler like /dev should list the real files
> (if they exist) _and_ the virtual devices.  I don't think that's
> a requirement for a /cygdrive fhandler or a /registry fhandler.
> They could but they don't have to.
In the case of both /cygdrive and /registry, I simply wouldn't allow the
existance of real files - though Win32 will mess that up, ofcourse.

Greetz!

Ronald


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




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