Rommel Dongre <rdongre@pillardata.com> wrote:
Hi:
Consider a process doing a chdir(“some/path/name”).
Only the file system knows about the existence of the path, or if it is
valid for this process (with some uid, gid) to change to it.
Yet, the call is going to the process-manager. So the process manager
must be talking to the file manager about the path, before returning
succes/failure to the process and updating it’s cwd structure.
Right?
The check is done in chdir(), look at the source 
http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c/1/chdir.c
So process A did chdir(“some/path/name”), the call first did
(effectively) a stat(“some/path/name”); And to find out who
is the manager taking care of “some/path/name”, this goes to
path manager, and the path manager contact process manager to find
out the $cwd, and make it $cwd/some/path/name, and find out
the real server (filesystem manager) and get info from there.
You can see “chdir()” also check things like if the destination
is a directory, and have the permision. If all satisfied, it
then told the path manager to CHDIR.
-xtang
Xiaodan Tang wrote:
Rommel Dongre <> rdongre@pillardata.com> > wrote:
Hi:
Calls to chdir() go to the Path Manager through the lib, while calls to
getcwd() go to the Process Manager. This leads me to believe that the
‘cwd’ is stored in proc-nto data structure.
Right.
My question is: How does a file-system resource manager ‘set’ the cwd in
the proc-nto data structure? Some kind of communication must be
happening between the file-system RM and proc-nto, to effect this; since
only the file-system RM knows about valid directories.
Why is a “filesystem resource manager” want to “set” the cwd?
And whose cwd it goint to set ?
cwd is a “process property”, which belongs to a process, inherit
from it’s parent…
If a process try to resolve things like “…/…/bin/ls”, then
the path will be resolved in procnto before it could reach
it’s server. In other words, “filesystem resource manager”
is not suppose to get a path have “.” or “…” in it …
-xtang