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

["Ronald Landheer" <info at rlsystems dot net>]

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/