Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Subject: RE: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Date: Mon, 24 Sep 2001 13:13:15 +1000
content-class: urn:content-classes:message
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A32@itdomain002.itdomain.net.au>
Thread-Topic: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)
Thread-Index: AcFEljSHUNuetShjSPmRghVy6zR7ggADomVQ
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Ronald Landheer" <info AT rlsystems DOT net>
Cc: <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: Ronald Landheer [mailto:info AT rlsystems DOT net]
> Sent: Monday, September 24, 2001 11:05 AM
> To: Charles Wilson
> Cc: Robert Collins; cygwin AT cygwin DOT 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/