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

[Corinna Vinschen]

On Mon, Sep 24, 2001 at 01:01:26PM +0200, Ronald Landheer wrote:
> The only problem I see immediately is a small one: my C++ may be a bit 
> rusty, as I haven't made any code in C++ in at least two years - though 
> I'm quite familiar with the object-oriented model, most of the 
> expressions and I think I might still know how to put a class together.. 
> (but with your code to start out with, I should pick it up quickly 
> enough.. I have C++ on my CV as one of the languages I "speak", so I 
> might as well remember it ;)

Programming in a language is the best approach to get rid of the rust ;-)

> > I can extract the mount aspects of my current code tonight, and will
> > send to cygwin-patches (simply FYI). You can then choose whether to
> > build on that, or start from scratch.
> If you could Cc it to me: I'm not on the patches list (and seeing as 
> this is the first time I'm actually going to work on a patch for Cygwin, 
> I had no reason to be there before..)

It makes sense to subscribe to cygwin-patches, cygwin-cvs and
cygwin-developers when contributing to Cygwin internals.

However, Chris is a bit handicapped this week so it could take
a week before he can approve your subscription.

Another thing is, you will have to sign an assignment form as
it's described on http://cygwin.com/contrib.html .  Unfortunately
it has to be send using snail mail...

I hope that doesn't discourage you.  We would be very glad to have
another person on board who doesn't chicken out when looking into
the Cygwin sources ;-)

> Corrina wrote:

s/rrin/rinn/

> That would mean, though, that it would have to check for "magic" entries 
> in *every* call to readdir() - not just the ones that fail to find 
> "normal" stuff. Not too much of a problem, ofcourse, and quite feasible.

Since it would be inside of a special fhandler which encapsulates it,
it's indeed not that hard.

> > I think that you'll have some work to implement that due to a
> > design constraint inside of Cygwin.  In theory the functionality
> > of stat/readdir etc. has to be moved inside of the fhandlers
> > first.  While that already works for stat on disk files it's
> > currently not implemented for readdir at all.
> What design constraint is that? (What is being constrained, exactly?)

As I wrote, opendir/readdir/etc. are global implementations
which only work on disks.  No virtual filesystems (/dev or
/proc or *cough* /registry) are supported.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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