Re: /proc and /proc/registry

["Chris January" <chris at atomice dot net>]

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