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

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

[Ronald Landheer]

Hi Liu,

I've directed the mail back to the list - it seems to belong there.

>>> 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.
> fhandlers only handle files, but they don't handle directories. 
> directory enumeration is hard coded in the opendir/readdir calls in 
> path.cc ...
I know - after all, that's what they're named for :). Would you rather 
I'd call them dhandlers? I don't see much of a difference, and I think 
the intentions - i.e. what we were saying - was clear anyway.
Though, ofcourse, clarity is something that should not be lacking when 
talking about technical details of an upcoming implementation.. (point 
taken)

> perhaps we should abstract the implementation of those two calls the 
> same way as we abstracted fhandlers. say, we'll call it either
> dhandlers (directory handlers) or mhandlers (mount handlers). in this
> setup, the mount table (in registry) would specify the type of mount
> (eg, the handler). i would advocate having dhandlers/mhandlers
> borrowing the same design as fhandlers.
As would I - which is why (I think) we've been calling them fhandlers :)

> first of all, do you people like calling it dhandlers better or 
> mhandlers better?
What's in a name? I have no problem with just keeping the "fhandlers" as 
it's still the file system we're handling - be it virtual, magic or 
otherwise. I see no reason to complicate matters with naming conventions 
for obscure reasons. Anyone who takes a look at the source code and/or 
the docs will know how it works, and whatever I implement will be 
commented in the code, and will probably be accompanied by a file "How 
do magic dirs work?". Other than that, this thread documents the design 
in detail, and if there's a lot of questions about it - which I highly 
doubt, because it's a Cygwin internal matter we're talking about - there 
can always be an FAQ entry. We'd need one if we'd call it dhandlers or 
mhandlers too, if we'd need one at all.

The key to clear programming is not in changing a letter of a name: it's 
in the documentation of both the source code and its functionality. 
Whether you call it fhandlers or dhandlers (or mhandlers) is, IMHO, a 
non-issue.

Ofcourse, I'm speaking for myself here, if the others (Chris, Corinna, 
Robert, Chuck) think it's better to give the beast a new name, by all 
means. Personally, I'm more interested in how it should work than what 
it should be called.

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/

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

[Li-Kai Liu]

Ronald Landheer wrote:

>What's in a name? I have no problem with just keeping the "fhandlers" as 
>it's still the file system we're handling - be it virtual, magic or 
>otherwise. I see no reason to complicate matters with naming conventions 
>for obscure reasons. Anyone who takes a look at the source code and/or 
>the docs will know how it works, and whatever I implement will be 
>commented in the code, and will probably be accompanied by a file "How 
>do magic dirs work?". Other than that, this thread documents the design 
>in detail, and if there's a lot of questions about it - which I highly 
>doubt, because it's a Cygwin internal matter we're talking about - there 
>can always be an FAQ entry. We'd need one if we'd call it dhandlers or 
>mhandlers too, if we'd need one at all.
>
>The key to clear programming is not in changing a letter of a name: it's 
>in the documentation of both the source code and its functionality. 
>Whether you call it fhandlers or dhandlers (or mhandlers) is, IMHO, a 
>non-issue.
>
the way fhandler reflect to me is that it handles specific files in the 
filesystem. and fhandler classes often have basic file operations (open, 
read, write, seek, even ioctl) in mind. the point is, fhandler seems to 
me more like a device driver than file system. true, it doesn't matter 
whether we debate over names like dhandler or mhandler, even fshandler 
is a good name. clarity is not what i stress here, by the way.

however, files and file systems are two different concepts! fhandler 
takes care of device files, and fshandler takes care of file system, 
visibility, and traversal. of course you could make fhandler take care 
of file system's work, but i can tell you, by confusing over the two 
different concepts and merge them to one, you'll end up having a really 
messy ugly thing. now, talk about programming, i think organization and 
architectural design is above all things. of course, organization 
implies clarity ... well, if you do want to rant about my obsession with 
clarity ... ~_~

maybe i didn't say it in a recognizable fashion last time, but i do hope 
to separate *file* handling with *file system* handling.

if cygwin's goal is to implement a unix system on windows, then why 
don't we do what unix does? in my opinion, a file object should not need 
to worry about its location/path/attribute. all it needs to care is 
input and output. in turn, an inode (file system object) should not 
worry about input and output. it just takes care of where the file 
object is, the file type, and its attribute.

apparently it is not the way it is right now in cygwin. :(

i know that this might sound overly complicated to people. besides, it 
sounds more like we're implementing an entire operating system. in some 
sense, it is true. whoever decided to have a separate file system in 
cygwin then in win32 in the first place should also know where this 
ends. you don't do things half-way done. i mean, i'm not forcing anybody 
to code the way i want them to. i'll genuinely code this thing if I know 
that people like my idea and so it won't end up being hated and discarded.

liulk



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

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

[Robert Collins]

----- Original Message -----
From: "Li-Kai Liu" <news@likai.net>

> however, files and file systems are two different concepts! fhandler

Corinna has already indicated that this is the desired end direction,
with one class hierarchy for fs's and one for files.

> apparently it is not the way it is right now in cygwin. :(

Exactly. However making the readdir and opendir calls use objects and
stop being hardcoded to win32 is a good step in the right direction.

> to code the way i want them to. i'll genuinely code this thing if I
know
> that people like my idea and so it won't end up being hated and
discarded.

It won't end up being hated and discarded :]. I strongly suggest a
one-step-at-a-time approach though: a series of small patches that make
specific changes to get from here to there. Biting off too much is a
common reason for architectural changes to fail.

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/

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

[Li-Kai Liu]

Robert Collins wrote:

>----- Original Message -----
>From: "Li-Kai Liu" <news@likai.net>
>
>>however, files and file systems are two different concepts! fhandler
>>
>
>Corinna has already indicated that this is the desired end direction,
>with one class hierarchy for fs's and one for files.
>
>>apparently it is not the way it is right now in cygwin. :(
>>
>
>Exactly. However making the readdir and opendir calls use objects and
>stop being hardcoded to win32 is a good step in the right direction.
>
>>to code the way i want them to. i'll genuinely code this thing if I
>>
>know
>
>>that people like my idea and so it won't end up being hated and
>>
>discarded.
>
>It won't end up being hated and discarded :]. I strongly suggest a
>one-step-at-a-time approach though: a series of small patches that make
>specific changes to get from here to there. Biting off too much is a
>common reason for architectural changes to fail.
>
>Rob
>
however i am eager, i must agree with you on "one-step-at-a-time" 
approach. i know i have a tendency to get greedy and slurp a big chunk 
at once, but at the same time i also fear that any addition to (or more 
reliance on) the current unorthodox way fhandler works would also make 
the transition more difficult.

liulk



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

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

[Christopher Faylor]

On Tue, Sep 25, 2001 at 09:22:08AM +1000, Robert Collins wrote:
>----- Original Message -----
>From: "Li-Kai Liu" <news@likai.net>
>
>> however, files and file systems are two different concepts! fhandler
>
>Corinna has already indicated that this is the desired end direction,
>with one class hierarchy for fs's and one for files.
>
>> apparently it is not the way it is right now in cygwin. :(
>
>Exactly. However making the readdir and opendir calls use objects and
>stop being hardcoded to win32 is a good step in the right direction.
>
>> to code the way i want them to. i'll genuinely code this thing if I
>know
>> that people like my idea and so it won't end up being hated and
>discarded.
>
>It won't end up being hated and discarded :]. I strongly suggest a
>one-step-at-a-time approach though: a series of small patches that make
>specific changes to get from here to there. Biting off too much is a
>common reason for architectural changes to fail.

Yes, what he said.

With any free software project, small incremental changes are the
best way to get things done.

One other thing to point out is that if your patches involve
gratuitous changes to other parts of the code, if they are
formatted "incorrectly", if they don't include a ChangeLog
entry (not a *patch* of a ChangeLog entry), if the ChangeLog
entry is formatted incorrectly or has odd wording, then these
are also obstacles to getting a patch included.

Basically, you want to make the patch easy to read and problem-free.
Then people are apt to read them and comment on them.

cgf

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

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

[Li-Kai Liu]

 >
 >
 >>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.
 >
fhandlers only handle files, but they don't handle directories.
directory enumeration is hard coded in the opendir/readdir calls in
path.cc ...

perhaps we should abstract the implementation of those two calls the
same way as we abstracted fhandlers. say, we'll call it either dhandlers
(directory handlers) or mhandlers (mount handlers). in this setup, the
mount table (in registry) would specify the type of mount (eg, the
handler). i would advocate having dhandlers/mhandlers borrowing the same
design as fhandlers.

first of all, do you people like calling it dhandlers better or
mhandlers better?

liulk




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

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

[Robert Collins]

> -----Original Message-----
> From: Ronald Landheer [ mailto:info@rlsystems.net ]
> Sent: Monday, September 24, 2001 11:05 AM
> To: Charles Wilson
> Cc: Robert Collins; cygwin@cygwin.com
> Subject: RE: [PATCH] ls & "magic" cygdrive dir (was: RE: 
> cygdrive stuff)
> 
> 
> Hi Chuck,
> 
> > None of these are correct.  You should be looking in 
> > /cygwin/winsup/cygwin/*.cc, not /newlib/*.  You probably 
> want to take 
> > a look at syscalls.cc or fhandler_*.cc or path.cc.
> Found stat_worker() in syscalls.cc (which is called by _stat()).
> opendir() and readdir() are both in dir.cc
> 
> I'll have a good look tomorow. What I'm thinking of doing for 
> stat() is 
> this: I let the stat() call run until the end (there's a done 
> flag there 
> that it jumps to, and there's only one other return, which is 
> succesful). If it's not successful, I take a look whether the 
> stat()-ed 
> path is actually a magic dir, and if so, I report it as a dir. Like 
> that, I don't do anything if stat() would figure it out by 
> himself, and 
> I can only report a magic dir as a directory.

I have some code in my sandbox to allow mounting of aribtrary
filesystems, that I put together for UMSDOS support. Unfortuneately I
hit a serious time constraint, as this was working.

I mention this because supporting stat() and readdir() is obviously
_part_ of that. The way I tackled it was to have the handler of the
mount point listed as well as the mount point in the registry. This then
was automatically transferred to the correct code in cygwin when a
non-win32 backed filesystem was encountered. By pulling in that code
base, the magic dir stuff will become a normal case, rather than a
special case. (I.E. we mount a cygdrive fhandler at /cygdrive, a devlist
fhandler at /dev (equivalent to the linux devfs), and we're done.

There will still be _one_ _optional_ special case, and that is adding a
mounted directory to the directory listing returned from the level
above. (ie to get cygdrive included in the listing for /).

I'm not adamant that this is the right approach, but I thought that you
might like to review it as an alternative (that also adds neat
capabilities, like mounting a registry filesystem without special case
code).

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.

The TODO on my list to have a minimum production patch would be
something like:
* copy the linux semantics for the mount userspace calls (I rolled my
own variation to which cgf said "if you must change this, copy linux" :]
).
* create the cygdrive fhandler class.
* create the devfs fhandler class.
* Alter setup.exe to add the new default mount point registry entries
(for /cygdrive and /dev).

In a nutshell the code I'll send in handles the detection and
redirection of the io call to the correct arbitrary fhandler type, and
then they have to implement the logic for opendir/readdir/stat as
appropriate.

This is very low on my list of things to do, which is why I haven't
progressed it.

If you choose to take this approach, I offer to do the setup.exe change
once the rest is ready, to save you learning the setup.exe codebase -
which I already know quite well :].

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/

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

[Corinna Vinschen]

On Mon, Sep 24, 2001 at 01:13:15PM +1000, Robert Collins wrote:
> * create the cygdrive fhandler class.
> * create the devfs fhandler class.
> * Alter setup.exe to add the new default mount point registry entries
> (for /cygdrive and /dev).

I think it's a bit more tricky.  /dev is a wonderful example.
By default it contains only device entries:

	/dev/tty
	/dev/st0
	...

which you could nicely support by a dev fhandler.  The problem
is that I wouldn't like to disallow to create symlinks inside of
/dev:

	ln -s /dev/st0 /dev/tape

So /dev is kinda `bastard' containing virtual device entries
but also real symlinks.

In that case it would make sense to support reading the real
/dev in the Cygwin tree on disk plus listing all virtual
device entries.  Sure, you could manage that in the dev fhandler...

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.


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/

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

[Robert Collins]

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


> On Mon, Sep 24, 2001 at 01:13:15PM +1000, Robert Collins wrote:
> > * create the cygdrive fhandler class.
> > * create the devfs fhandler class.
> > * Alter setup.exe to add the new default mount point registry
entries
> > (for /cygdrive and /dev).
>
> I think it's a bit more tricky.  /dev is a wonderful example.
> By default it contains only device entries:
>
> /dev/tty
> /dev/st0
> ...
>
> which you could nicely support by a dev fhandler.  The problem
> is that I wouldn't like to disallow to create symlinks inside of
> /dev:
>
> ln -s /dev/st0 /dev/tape
>
> So /dev is kinda `bastard' containing virtual device entries
> but also real symlinks.

Ahh, well, there are two approaches there. 1 is what I described. A
second one is to mount each device separately at it's appropiate point,
and have a real /dev directory.

IMO if you want full fs at /dev, then you should create it. AFAIK the
linux devfs is readonly, with the exception of adding nodes when devices
are detected at runtime.

> In that case it would make sense to support reading the real
> /dev in the Cygwin tree on disk plus listing all virtual
> device entries.  Sure, you could manage that in the dev fhandler...
>
> 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.

Ok, well that makes sense. Any objection to it being done :}?

(It should be a matter of moving the existing code to fhandler_disk,
with a copy to _raw and creating a couple of wrapper calls similar to
stat(), followed up with a virtual method in fhandler_base shouldn't
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/

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

[Corinna Vinschen]

On Mon, Sep 24, 2001 at 07:36:07PM +1000, Robert Collins wrote:
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> > So /dev is kinda `bastard' containing virtual device entries
> > but also real symlinks.
> 
> Ahh, well, there are two approaches there. 1 is what I described. A
> second one is to mount each device separately at it's appropiate point,
> and have a real /dev directory.
> 
> IMO if you want full fs at /dev, then you should create it. AFAIK the
> linux devfs is readonly, with the exception of adding nodes when devices
> are detected at runtime.

We could simulate /dev through the fhandler, though.  Assuming
we already have a fhandler_devfs, its opendir()/readdir() could
begin with listing the real /dev directory if and as it exists.
When finished, it could go ahead with listing the internal
Cygwin devices.  The `stat' call itself isn't concerned at all
by this approach.  It would work as before.  A good idea would
just be to create a /dev by setup to have the real directory
node to be able to list . and .. w/o handstands.  And we don't
have to worry about the order since that's done by ls.

> > 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.
> 
> Ok, well that makes sense. Any objection to it being done :}?

Yes and no.

- Yes, this is a `not in 1.3.4' kinda thing since 1.3.4 should
  be a bug fix release as you know.

- No for 1.3.5.
  
- Another yes due to our long term devlopment target to substitute
  the fhandler classes by device and file system classes.  But that
  will take much time so we can neglect that for now.

> (It should be a matter of moving the existing code to fhandler_disk,
> with a copy to _raw and creating a couple of wrapper calls similar to
> stat(), followed up with a virtual method in fhandler_base shouldn't
> it?)

Yup, more or less,  but with a copy to _base.

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/

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

[Robert Collins]

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


> On Mon, Sep 24, 2001 at 07:36:07PM +1000, Robert Collins wrote:
> > From: "Corinna Vinschen" <cygwin@cygwin.com>
> > > So /dev is kinda `bastard' containing virtual device entries
> > > but also real symlinks.
> >
> > Ahh, well, there are two approaches there. 1 is what I described. A
> > second one is to mount each device separately at it's appropiate
point,
> > and have a real /dev directory.
> >
> > IMO if you want full fs at /dev, then you should create it. AFAIK
the
> > linux devfs is readonly, with the exception of adding nodes when
devices
> > are detected at runtime.
>
> We could simulate /dev through the fhandler, though.  Assuming
> we already have a fhandler_devfs, its opendir()/readdir() could
> begin with listing the real /dev directory if and as it exists.
> When finished, it could go ahead with listing the internal
> Cygwin devices.  The `stat' call itself isn't concerned at all
> by this approach.  It would work as before.  A good idea would
> just be to create a /dev by setup to have the real directory
> node to be able to list . and .. w/o handstands.  And we don't
> have to worry about the order since that's done by ls.

Sure. All I meant to say is that we shouldn't design this behaviour in.
Allow it - yes; require it - no. Quite obviously any fhandler can do
what it wants - merge network, win32, and virtual data. As long as they
don't _have to_ I'm happy :].

> >
> > Ok, well that makes sense. Any objection to it being done :}?
>
> Yes and no.
>
> - Another yes due to our long term devlopment target to substitute
>   the fhandler classes by device and file system classes.  But that
>   will take much time so we can neglect that for now.

Ah, didn't know about that. Still, IMO this is actually helpful for
that, as it starts the process of making all fs calls into the fhandler
class and out of syscalls.cc.

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/

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

[Robert Collins]

My umsdos stuff is in my unix fs, and I have some tasks runing in
win32 - I cannot reboot tonight. Tomorrow morning - I hope - I will get
into that and pull the sources for this.

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/

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

[Corinna Vinschen]

On Mon, Sep 24, 2001 at 10:12:59PM +1000, Robert Collins wrote:
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> > We could simulate /dev through the fhandler, though.  Assuming
> > we already have a fhandler_devfs, its opendir()/readdir() could
> > begin with listing the real /dev directory if and as it exists.
> > When finished, it could go ahead with listing the internal
> > Cygwin devices.  The `stat' call itself isn't concerned at all
> > by this approach.  It would work as before.  A good idea would
> > just be to create a /dev by setup to have the real directory
> > node to be able to list . and .. w/o handstands.  And we don't
> > have to worry about the order since that's done by ls.
> 
> Sure. All I meant to say is that we shouldn't design this behaviour in.
> Allow it - yes; require it - no. Quite obviously any fhandler can do
> what it wants - merge network, win32, and virtual data. As long as they
> don't _have to_ I'm happy :].

You mean the existence of the real directory?

> > - Another yes due to our long term devlopment target to substitute
> >   the fhandler classes by device and file system classes.  But that
> >   will take much time so we can neglect that for now.
> 
> Ah, didn't know about that. Still, IMO this is actually helpful for
> that, as it starts the process of making all fs calls into the fhandler
> class and out of syscalls.cc.

I second that.

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/

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

[Robert Collins]

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


> On Mon, Sep 24, 2001 at 10:12:59PM +1000, Robert Collins wrote:
> > From: "Corinna Vinschen" <cygwin@cygwin.com>
> > > We could simulate /dev through the fhandler, though.  Assuming
> > > we already have a fhandler_devfs, its opendir()/readdir() could
> > > begin with listing the real /dev directory if and as it exists.
> > > When finished, it could go ahead with listing the internal
> > > Cygwin devices.  The `stat' call itself isn't concerned at all
> > > by this approach.  It would work as before.  A good idea would
> > > just be to create a /dev by setup to have the real directory
> > > node to be able to list . and .. w/o handstands.  And we don't
> > > have to worry about the order since that's done by ls.
> >
> > Sure. All I meant to say is that we shouldn't design this behaviour
in.
> > Allow it - yes; require it - no. Quite obviously any fhandler can do
> > what it wants - merge network, win32, and virtual data. As long as
they
> > don't _have to_ I'm happy :].
>
> 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.

Is that more or less clear?

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/

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

[Corinna Vinschen]

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 hope we are not just busy to talk at cross-purposes :-)
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/

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

[Ronald Landheer]

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/

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

[Corinna Vinschen]

On Mon, Sep 24, 2001 at 09:24:23PM +0200, Ronald Landheer wrote:
> 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.

Nope.  Even if the file exists, opening and writing will ever
end up in the device.  That's not a problem even right now.

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

IMO it doesn't matter.  Files are listed as files, symlinks as
symlinks.  If somebody creates a file called like a device
(which is only possible outside of Cygwin processes) it will
exist but has no further influence except, perhaps, that the
corresponding device will be listed twice.

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

Yep, that's it.  You can't prevent it.  The question is just if
the fhandler has to list it or not.

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/

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

[Ronald Landheer]

Hello Corinna /et al/,

Corinna wrote:
> On Mon, Sep 24, 2001 at 09:24:23PM +0200, Ronald Landheer wrote:
>> 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.
> Nope.  Even if the file exists, opening and writing will ever
> end up in the device.  That's not a problem even right now.
OK, let's keep it that way ;)

>> 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..
> IMO it doesn't matter.  Files are listed as files, symlinks as
> symlinks.  If somebody creates a file called like a device
> (which is only possible outside of Cygwin processes) it will
> exist but has no further influence except, perhaps, that the
> corresponding device will be listed twice.
I didn't know Cygwin was that safe :)
So, if I understand correctly, devices *always* take precedence over 
files? Conflicts between them are *absolutely* impossible?
Just making sure - seems too good to be true :)

>> 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.
> Yep, that's it.  You can't prevent it.  The question is just if
> the fhandler has to list it or not.
In the case of real file where they're not supposed to be, I'd say not: 
make them completely invisible. They're not supposed to be there - 
ignore them. No stat(), no listing, nothing.
People will probably whine about it though.. (Q: "I put a file in 
/registry but I can't fopen() it!" A: " http://www.tuxedo.org/~esr/faqs/smart-questions.html" ;) 

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/

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

[Corinna Vinschen]

On Mon, Sep 24, 2001 at 11:17:59PM +0200, Ronald Landheer wrote:
> So, if I understand correctly, devices *always* take precedence over 
> files? Conflicts between them are *absolutely* impossible?
> Just making sure - seems too good to be true :)

But it is true.  The reason is that a path is always translated
by calling a `look for device' function very early in the path
translation (path.cc).

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/

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

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
>
> > 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.
>
> Yep, that's it.  You can't prevent it.  The question is just if
> the fhandler has to list it or not.

Yup, up to the fhandler, just like in linux (mount over a dir with
curent content, it's contents are not visible while the mount is
present). An individual can write a fs driver that merges the existing
dir in, IF they want to.

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/

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

[Robert Collins]

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@rlsystems.net>
To: "Corinna Vinschen" <cygwin@cygwin.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/

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

[Robert Collins]

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

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

[Corinna Vinschen]

On Tue, Sep 25, 2001 at 08:19:19AM +1000, Robert Collins wrote:
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> > 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.

Isn't that what I said above?

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/

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

[Robert Collins]

On Tue, 2001-09-25 at 08:22, Corinna Vinschen wrote:
> On Tue, Sep 25, 2001 at 08:19:19AM +1000, Robert Collins wrote:
> > From: "Corinna Vinschen" <cygwin@cygwin.com>
> > > 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.
> 
> Isn't that what I said above?

Yes, I am trying to be ironclad to prevent confusion though. I wasn't
100% clear whether you meant that the core code should have any interest
in the backing store, and also what the default beahviour would be. I
find putting things into a general specfication with _no_ examples is
the easiest way prevent confusion. 

Sorry if it was redundant.

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/

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

[Ronald Landheer]

Hello Robert

You (Robert) wrote:
> I (Ronald) wrote:
>> Chuck wrote:
>>> None of these are correct.  You should be looking in 
>>> /cygwin/winsup/cygwin/*.cc, not /newlib/*.  You probably 
>>> want to take a look at syscalls.cc or fhandler_*.cc or path.cc.
>> Found stat_worker() in syscalls.cc (which is called by _stat()).
>> opendir() and readdir() are both in dir.cc
>> I'll have a good look tomorow. What I'm thinking of doing for 
>> stat() is this: I let the stat() call run until the end (there's a
>> done flag there that it jumps to, and there's only one other return,
>> which is succesful). If it's not successful, I take a look whether
>> the stat()-ed path is actually a magic dir, and if so, I report it as
>> a dir. Like that, I don't do anything if stat() would figure it out
>> by himself, and I can only report a magic dir as a directory.
> I have some code in my sandbox to allow mounting of aribtrary
> filesystems, that I put together for UMSDOS support. Unfortuneately I
> hit a serious time constraint, as this was working.
> I mention this because supporting stat() and readdir() is obviously
> _part_ of that. The way I tackled it was to have the handler of the
> mount point listed as well as the mount point in the registry. This
> then was automatically transferred to the correct code in cygwin when
> a non-win32 backed filesystem was encountered. By pulling in that code
> base, the magic dir stuff will become a normal case, rather than a
> special case. (I.E. we mount a cygdrive fhandler at /cygdrive, a
> devlist fhandler at /dev (equivalent to the linux devfs), and we're
> done.
> There will still be _one_ _optional_ special case, and that is adding
> a mounted directory to the directory listing returned from the level
> above. (ie to get cygdrive included in the listing for /).
> I'm not adamant that this is the right approach, but I thought that
> you might like to review it as an alternative (that also adds neat
> capabilities, like mounting a registry filesystem without special case
> code).
I think this might very well be the right approach: it gets the problem 
at the core, and fixes it by adding real functionality, which, IMHO, is 
better than the kinda workaround error-trap approach I had in mind :)
Additionally, this would provide the basis of adding more functionality, 
like directly mounting tar-disks/tapes, Macintosh floppies, etc.

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 ;)

> 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..)

Corrina wrote:
> I think it's a bit more tricky.  /dev is a wonderful example.
> By default it contains only device entries:
>	/dev/tty
>	/dev/st0
>	...
> which you could nicely support by a dev fhandler.  The problem
> is that I wouldn't like to disallow to create symlinks inside of
> /dev:
>	ln -s /dev/st0 /dev/tape
> So /dev is kinda `bastard' containing virtual device entries
> but also real symlinks.
> In that case it would make sense to support reading the real
> /dev in the Cygwin tree on disk plus listing all virtual
> device entries.  Sure, you could manage that in the dev fhandler...
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.

> 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?)

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/

Re: [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/

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

[Ronald Landheer]

Corrina said:
> 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
> ;-)
In deed it is, and as I just accepted a job as a programmer/developer this afternoon (which kinda ends my freelancing days, I guess), which will require me to put a nice new coat of paint on my C++, I'll get the sandpaper out of the toolbox and start :)

>>> 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 ;-)
Whenever I wet my pants, I'll take a shower and put new pants on - but 
chickening out is not my style :)
I assume that subscribing is a matter of sending some E-mails (to 
cygwin-*-subscribe@cygwin.com), so I'll do that.

>>> 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.
Ah, but that's not a design constraint (at least: I wouldn't call it 
that) - that's an unimplemented feature. I thought you meant something 
that couldn't be implemented because Cygwin would croak.. (like using an 
umbrella like a parachute - due to some design constrains on the 
umbrella, that just doesn't work).
Missing features can be added - turning an umbrella into a parachute is 
just not possible, if you want to keep the umbrella-functionality.

Hope I'm not being too cryptic here ;)

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/

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

[Robert Collins]

> ----- Original Message -----
> From: "Ronald Landheer" <info@rlsystems.net>
> To: <cygwin@cygwin.com>
> Sent: Monday, September 24, 2001 7:04 AM
> Subject: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)
>
>
> Hello all,
>
> After the overwhelming display of interest for my last mail on this
> subject (which had gone completely unnoticed as far as I can tell), I

I missed it - cannot even recall it :].

> have patched up the patch I sent earlier to take care of a lacking
> feature.
> Much of my original mail is still valid, so I'm re-posting:
>
> -- BEGIN RE-POST --
> > On Wed, Sep 19, 2001 at 04:11:52PM -0300, salvador wrote:
> >> 1) "ls -la /" doesn't show any cygdrive directory. Note it could
> >> be solved in the same way UNIX solves the /proc stuff, just
mounting
> >> over an existent directory a fake one.
> >> 2) "ls -la /cygdrive" doesn't work.
> > Correct.
> > If you'd like to correct this, patches will be, as always,
> > gratefully accepted.
> I saw this, it itched me, so I'm attaching a patch :)
>
> The patch I'm attaching is against the source 'ls.c' as found in
> fileutils-4.1-1. It introduces three methods, of which one is called:
> ls-cygwin-loop(). It is called whenever needed.

...

> Note it only shows you that cygdrive exists. As there is no "magic
dir"
> filetype, and it's not a real directory, I'm not showing it as one. My
> patch only does anything when there *is* no real directory - if it
comes
> through a stat() call, it is not handled.

You've hit it on the button. stat() is what you need to patch, not ls.

I stopped reading here... but if you patch stat() I promise to read
further.

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/

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

[Robert Collins]

----- Original Message -----
From: "Robert Collins" <robert.collins@itdomain.com.au>


>
> > ----- Original Message -----
> > From: "Ronald Landheer" <info@rlsystems.net>
> > To: <cygwin@cygwin.com>
> > Sent: Monday, September 24, 2001 7:04 AM
> > Subject: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)
> >
> >
> > Hello all,
> >
> > After the overwhelming display of interest for my last mail on this
> > subject (which had gone completely unnoticed as far as I can tell),
I
>
> I missed it - cannot even recall it :].
>
> > have patched up the patch I sent earlier to take care of a lacking
> > feature.
> > Much of my original mail is still valid, so I'm re-posting:
> >
> > -- BEGIN RE-POST --
> > > On Wed, Sep 19, 2001 at 04:11:52PM -0300, salvador wrote:
> > >> 1) "ls -la /" doesn't show any cygdrive directory. Note it could
> > >> be solved in the same way UNIX solves the /proc stuff, just
> mounting
> > >> over an existent directory a fake one.
> > >> 2) "ls -la /cygdrive" doesn't work.
> > > Correct.
> > > If you'd like to correct this, patches will be, as always,
> > > gratefully accepted.
> > I saw this, it itched me, so I'm attaching a patch :)
> >
> > The patch I'm attaching is against the source 'ls.c' as found in
> > fileutils-4.1-1. It introduces three methods, of which one is
called:
> > ls-cygwin-loop(). It is called whenever needed.
>
> ...
>
> > Note it only shows you that cygdrive exists. As there is no "magic
> dir"
> > filetype, and it's not a real directory, I'm not showing it as one.
My
> > patch only does anything when there *is* no real directory - if it
> comes
> > through a stat() call, it is not handled.
>
> You've hit it on the button. stat() is what you need to patch, not ls.
>
> I stopped reading here... but if you patch stat() I promise to read
> further.
>

Sorry, a little more detail is needed, it's stat() + opendir() +
readdir() IIRC that need altering.

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/

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

[Ronald Landheer]

Hello Rober /et al/

>> After the overwhelming display of interest for my last mail on this
>> subject (which had gone completely unnoticed as far as I can tell), I
> I missed it - cannot even recall it :].
As did the rest of the world, I guess.. ;)

>> The patch I'm attaching is against the source 'ls.c' as found in
>> fileutils-4.1-1. It introduces three methods, of which one is called:
>> ls-cygwin-loop(). It is called whenever needed.
>> Note it only shows you that cygdrive exists. As there is no "magic
>> dir" filetype, and it's not a real directory, I'm not showing it as
>> one. My patch only does anything when there *is* no real directory -
>> if it comes through a stat() call, it is not handled.
> You've hit it on the button. stat() is what you need to patch, not ls.

(other mail)
> Sorry, a little more detail is needed, it's stat() + opendir() +
> readdir() IIRC that need altering.
You do recall correctly :)
In fact, you're right: the only thing is I was patching ls, but come to 
think of it, the cygdrive magic dir (and any other magic dir) should 
just come through a stat() call correctly, and opendir() and readdir() 
should handle it correctly.

As it's better to grab a bug by the guts than just pull its antenna's 
off, I'm back to the bug hunt (got the hat, the net and everything :)

I just have a question about the stat() implementation: there seem to be 
a lot of them (different ones for different systems, ofcourse). I should 
probably take the one from go32? (looks very DJGPP-ish to me, but that 
could just be me).

Same question (and same assumed probable answer) for opendir() and 
readdir()?

The implementations I'm referring to here are in newlib/libc/sys/go32
The reason I think it might be these is because they seem to be DOS 
implementations, and the cygwin directory (meaning 
newlib/libc/sys/cygwin) doesn't contain any implementations.
Building and examining the makefiles takes a rather long time, and as 
you - or other people on the list - probably know where these functions 
live by heart, it's a lot easier to just ask..

Greetz & Thanx!

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/

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

[Charles Wilson]

Ronald Landheer wrote:

> Hello Rober /et al/
> 
> 
>>>After the overwhelming display of interest for my last mail on this
>>>subject (which had gone completely unnoticed as far as I can tell), I
>>>
>>I missed it - cannot even recall it :].
>>
> As did the rest of the world, I guess.. ;)
> 
> 
>>>The patch I'm attaching is against the source 'ls.c' as found in
>>>fileutils-4.1-1. It introduces three methods, of which one is called:
>>>ls-cygwin-loop(). It is called whenever needed.
>>>Note it only shows you that cygdrive exists. As there is no "magic
>>>dir" filetype, and it's not a real directory, I'm not showing it as
>>>one. My patch only does anything when there *is* no real directory -
>>>if it comes through a stat() call, it is not handled.
>>>
>>You've hit it on the button. stat() is what you need to patch, not ls.
>>
> 
> (other mail)
> 
>>Sorry, a little more detail is needed, it's stat() + opendir() +
>>readdir() IIRC that need altering.
>>
> You do recall correctly :)
> In fact, you're right: the only thing is I was patching ls, but come to 
> think of it, the cygdrive magic dir (and any other magic dir) should 
> just come through a stat() call correctly, and opendir() and readdir() 
> should handle it correctly.
> 
> As it's better to grab a bug by the guts than just pull its antenna's 
> off, I'm back to the bug hunt (got the hat, the net and everything :)
> 
> I just have a question about the stat() implementation: there seem to be 
> a lot of them (different ones for different systems, ofcourse). I should 
> probably take the one from go32? (looks very DJGPP-ish to me, but that 
> could just be me).
> 
> Same question (and same assumed probable answer) for opendir() and 
> readdir()?
> 
> The implementations I'm referring to here are in newlib/libc/sys/go32
> The reason I think it might be these is because they seem to be DOS 
> implementations, and the cygwin directory (meaning 
> newlib/libc/sys/cygwin) doesn't contain any implementations.
> Building and examining the makefiles takes a rather long time, and as 
> you - or other people on the list - probably know where these functions 
> live by heart, it's a lot easier to just ask..


None of these are correct.  You should be looking in 
/cygwin/winsup/cygwin/*.cc, not /newlib/*.  You probably want to take a 
look at syscalls.cc or fhandler_*.cc or path.cc.

--Chuck






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

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

[Ronald Landheer]

Hi Chuck,

> None of these are correct.  You should be looking in 
> /cygwin/winsup/cygwin/*.cc, not /newlib/*.  You probably want to take 
> a look at syscalls.cc or fhandler_*.cc or path.cc.
Found stat_worker() in syscalls.cc (which is called by _stat()).
opendir() and readdir() are both in dir.cc

I'll have a good look tomorow. What I'm thinking of doing for stat() is 
this: I let the stat() call run until the end (there's a done flag there 
that it jumps to, and there's only one other return, which is 
succesful). If it's not successful, I take a look whether the stat()-ed 
path is actually a magic dir, and if so, I report it as a dir. Like 
that, I don't do anything if stat() would figure it out by himself, and 
I can only report a magic dir as a directory.
There's some details I have to figure out before I actually do anything 
(like what the MALLOC_CHECK macro does, for example) but I think this 
should work.

As for opendir() and readdir(), I don't know what the problem is yet - 
opendir() calls stat() to see if it's a directory, so after fixing 
stat() it should think it's looking at a directory. As it's not real, it 
will fail when it starts requesting information to win32, and/or tries 
to open it with open(), so I'll probably have to hook in after that's 
failed (so I know it would fail), fill in the dirent structure. It looks 
like the cookie field (__d_cookie) is a nice place to hide that we're 
looking at the magic dir, but I'd have to make sure it's not used by 
anyone else first. As is, readdir() expects it to be __DIRENT_COOKIE and 
nothing else, but I'll be working on readdir() anyway. I don't expect 
anything else to use this field, but I have all the sources anyway, so 
I'll do a grep search to make sure. (If that's the case, I can make a 
__DIRENT_COOKIE and a __DIRENT_MAGICDIR_COOKIE, and have readdir() 
handle it accordingly.

Now it's three AM. I have a call to put in to Canada (where it's 9 PM) 
and a nap to take (tomorow, it'll be 7 AM again..)

If you have any thoughts about the above, feel free to share them :)

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/

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

[Ronald Landheer]

[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]

Hello all,

After the overwhelming display of interest for my last mail on this subject (which had gone completely unnoticed as far as I can tell), I have patched up the patch I sent earlier to take care of a lacking feature.
Much of my original mail is still valid, so I'm re-posting:

-- BEGIN RE-POST --
> On Wed, Sep 19, 2001 at 04:11:52PM -0300, salvador wrote:
>> 1) "ls -la /" doesn't show any cygdrive directory. Note it could 
>> be solved in the same way UNIX solves the /proc stuff, just mounting
>> over an existent directory a fake one.
>> 2) "ls -la /cygdrive" doesn't work.
> Correct.
> If you'd like to correct this, patches will be, as always, 
> gratefully accepted.
I saw this, it itched me, so I'm attaching a patch :)

The patch I'm attaching is against the source 'ls.c' as found in 
fileutils-4.1-1. It introduces three methods, of which one is called: 
ls-cygwin-loop(). It is called whenever needed.

I've *only* tested this on a Win98 platform, but I don't think NT 
changes anything in this case (I don't have any NT platforms here, so I 
can't test them).

Here's how it works:

$ ls -la /
(..)
?---------    0 0        Sigma           0 Jan  1  1970 cygdrive
(..)

Note it only shows you that cygdrive exists. As there is no "magic dir" 
filetype, and it's not a real directory, I'm not showing it as one. My 
patch only does anything when there *is* no real directory - if it comes 
through a stat() call, it is not handled.

$ ls -la /cygdrive/
?---------    0 0        Sigma           0 Jan  1  1970 c
?---------    0 0        Sigma           0 Jan  1  1970 d
?---------    0 0        Sigma           0 Jan  1  1970 p
?---------    0 0        Sigma           0 Jan  1  1970 u

Note that 'ls -la /cygdrive' *only* shows:
?---------    0 0        Sigma           0 Jan  1  1970 cygdrive

The patch works regardless of the cygdrive setting, but does 
(regrettably) not show the mounted drives if the cygdrive setting is 
'/' and -an 'ls -la /' is done. I guess I should fix this, but the 
problem is that the mounted drives come through a stat() call as a 
directory, so I don't know whether or not they're really there - 
ideas would help.

Everything where displaying etc. is concerned is handled by the old code 
- my code only adds stuff to the list and does so conservatively (so it 
does not, for example, show the /usr/bin mount when an ls -la /usr is 
done, unless the directory is really there, in which case ls would show 
it anyway. (This is to avoid duplicates in the file list).

I lifted some code from mount - code used to see what mounts exist, and 
what the cygdrive prefix is.. I've surrounded those by copyright notices 
attributing it to mount & Cygnus. The rest is my own (but I'm quite 
willing to sign it over, if it's significant enough for any signatures: 
I'm no lawyer, so I'm being conservative - this, ofcourse, only if it 
proves useful enough to apply to ls..).

All code is surrounded by the magic __CYGWIN__ ifdefs - so no other 
platforms should be affected at all. (However, I don't know how MinGW32 
handles this, or how this goes along with the -mno-cygwin flag)
--- END RE-POST ---
In addition to this, my former patch didn't handle relative directories 
(at all). I.e. running "ls ../../../.." from the "/usr/src/fileutils-
4.1-1/src" directory didn't show the /cygdrive magic dir, while "ls /" 
did. This has been fixed by expanding the path as handled by the patch 
to the full POSIX path.

Once again: this patch has *only* been tested on my development machine, 
because I do not have any other configurations available here. Please, 
if you have other configurations, feel free to test it - it's only 
prudent.

I hope this will be helpful (and won't go unnoticed this time) :)

Greetz!

Ronald

[-- Attachment #2: ls.c.diff.gz --]
[-- Type: application/x-gzip, Size: 3349 bytes --]