This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: /proc and /proc/registry
> >> 1) The copyrights still need to be changed.
> >Done.
> >> 2) The code formatting still is not correct.
> >Now piped through indent with a few touch-ups.
> >> 3) You have a lot of calls to normalize_posix_path. Is that really
> >> necessary? It seems to be called a lot. If it is really necessary,
> >> I'd prefer that it just be called in dtable::build_fhandler and made
> >> the standard "unix_path_name".
> >Done.
> >> 4) Could you generate the diff using 'cvs diff -up"
> >Done. The new files are diff'ed against /dev/null and are appended to the
> >output of cvs diff.
<--snip-->
> >+ if (*path == 0)
> >+ return FH_PROC;
>
> How could this happen?
This occurs when the path is actually just /proc. Compare with
fhandler_proc::exists which does the same thing.
> >+ int pid = atoi (path);
> >+ winpids pids;
> >+ for (unsigned i = 0; i < pids.npids; i++)
> >+ {
> >+ _pinfo *p = pids[i];
> >+
> >+ if (!proc_exists (p))
> >+ continue;
> >+
> >+ if (p->pid == pid)
> >+ return FH_PROCESS;
> >+ }
> >+ return FH_PROC;
> >+}
>
> Is this right? If I type /proc/qwerty this returns FH_PROC?
Yes, this is by design. Any path in /proc should be handled by a sub-class
of fhandler_virtual. This way path.cc (chdir/path_conv::check) can call
fhandler_virtual::exists on the path to check whether it actually exists or
not. Arguably FH_BAD could be returned here instead. It's an arbitary
decision so I accept anyone else's opinion.
> >--- /dev/null Tue Feb 26 12:31:06 2002
> >+++ fhandler_virtual.cc Tue Feb 26 11:14:04 2002
> >@@ -0,0 +1,228 @@
> >+DIR *
> >+fhandler_virtual::opendir (path_conv & real_name)
> >+{
> >+ return opendir (get_name());
> >+}
>
> I don't see how this can be right. Won't this induce infinite recursion?
No - opendir is overloaded in fhandler_virtual. The idea is that virtual
fhandler (i.e. classes that derive from fhandler_virtual) methods
consistently get passed a unix path instead of a reference to a path_conv
instance.
Regards
Chris