Re: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
To: "cygwin" <cygwin@cygwin.com>
Sent: Monday, September 24, 2001 11:01 PM
Subject: Re: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)


> On Mon, Sep 24, 2001 at 10:44:08PM +1000, Robert Collins wrote:
> > From: "Corinna Vinschen" <cygwin@cygwin.com>
> > > You mean the existence of the real directory?
> >
> > Sort of. I mean the requirement that to achieve a mixture of real
and
> > mounted entries, the fhandler class has to do it. Simply mounting
all
> > the virtual entries into a real directory should automagically
result in
> > them showing up in that parent dir's readdir() and being statable.
>
> That's already the case.
>
> > 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.
>
> 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.

I think that this behaviour is fhandler dependant. I.e.

I write a /registry fhandler. It _completely ignores_ any win32 fs
backing from the mount point. In this example, such merging of filenames
_will not_.

You write a /dev fhandler. It _chooses to_ merge in any win32 fs backing
from the mount point down. In this example the user creating /dev/tty
will result in showing the file.

The syscall core code, and the fhandler_base code _should not_ deal with
the special case that /dev is _choosing_ to allow.

So as a spec:
* no merging of win32 backed paths/files into the fhandler's namespace
will occur _by default_.
* If a fhandler chooses to merge win32 backed paths/files into the
fhandlers namespace, that fhandler will be responsible for removing any
duplicate information.
* If there are win32 backed files in a given the fhandlers namespace,
system calls will go to the fhandler for resolution (ie as it does now).

How does that sound? It allows your user to create files in /dev, if
/dev is written to allow that, and it does not require it.

Rob


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