[cgf@redhat.com: fhandler redesign]

Robert Collins robert.collins@itdomain.com.au
Thu May 17 15:23:00 GMT 2001

----- Original Message -----
From: "DJ Delorie" <dj@delorie.com>
To: <cygwin-developers@cygwin.com>
Sent: Friday, May 18, 2001 7:01 AM
Subject: Re: [cgf@redhat.com: fhandler redesign]

> There's actually four layers we should have:
> 1. The physical device/file.  Two programs could be writing to
>    different parts or instances of the device simultaneously.  I think
>    NT takes care of this for us, but virtual devices we create we'd
>    need to think about this.  I can't think of examples, though, so we
>    can probably leave it up to the #2 layer to figure out how/where to
>    deal with this, rather than have it as an explicit layer.

FIFO's come to mind. The clipboard is potentially in this case as well.

> 2. The "file".  This is where the file pointer and other state (baud
>    rate, foreground color, whatnot) are kept, for example.
> 3. The "file descriptor".  This is the int (and whatever state is
>    behind it) that open() returns.  There are a few things that are
>    descriptor-specific, like blocking or opened/closed.
> 4. The filesystem.  While independent of the other three, we should
>    consider how this fits into the system so that we can do things
>    like mounting EXT3 volumes, or NFS, or faking /dev, /proc, and
>    /proc/registry.

I'd like to suggest we implement ext3/nfs and other filesystems via real
win32 IFS handlers. It's a bit more effort, but we'll get the win32
process cleanup, and allow non-cygwin process's to access the fs.
(Imagine the complaints otherwise: I mounted my linux partition, but
when I use ActiveState Perl It cannot access the files....)


More information about the Cygwin-developers mailing list