Mail Archives: cygwin/2001/09/24/07:02:26
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/
- Raw text -