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