Re: Current Directory of a Process
Re: Current Directory of a Process
- Subject: Re: Current Directory of a Process
- From: Robert Sandilands <email@hidden>
- Date: Thu, 10 Jul 2003 09:58:35 -0400
I have seen that basically all file access does provide the full path
except the Terminal. To keep track of the current directory you just
have to keep track of all SYS_chdir calls... But it is really ugly, but
not as ugly as the solutions you mention.
If I could add a feature request wish for a future version of the
kernel, I would like to see a variable somewhere that stores the
current working directory on a per process basis. If you think about
it, 1024 bytes extra per process is not that much of a performance
penalty in a modern world? On my machine as it is running now, with
about 10 applications open, it means 68kB more memory used by the
kernel. I know I am simplifying it quite a bit. The path does not have
to be unique or even correct, it just needs to be one path that does
work. I think there are a significant number of applications that will
suffer performance penalties because it is so slow/difficult to get to
the current working directory.
I have seen at least one complaint of the slow performance of darwin
because of this. Look at an email "Performance of realpath" on the
darwin-development mailing list about slow performance of PHP.
Thank you
Robert Sandilands
On Thursday, July 10, 2003, at 05:03 AM, Quinn wrote:
At 12:17 -0400 11/6/03, Robert Sandilands wrote:
I am open to any suggestions.
Lots of folks ask for this (vnode to path), but it's just not possible
in the general case within the current architecture. As Jim said,
there may not be a path, or there may be more than one.
There are two really ugly options.
1. If the vnode is a directory, you can follow up the .. chain until
you hit the root, at each stage iterating through the directory
looking for your vnode. This is exactly the algorithm used by
getcwd_physical in Libc.
2. If the vnode is a file, there's no general solution. The only
feasible approach that I've seen is to get the CNID for the file and
its parent, and then use volfs to look up the file and find its
parent. This approach will only work on file systems that support
volfs (HFS [Plus], AppleShare).
You really have to stand back and look at the overall problem. How
are you tapping into the kernel to generate your log points? Can you
use that same mechanism to keep track of this information on a
pre-process basis?
Regardless, it's very likely that any approach you take will result in
*serious* binary compatibility problems as we evolve the Mac OS X
kernel. The kernel architecture just isn't set up to do this.
---------------------------------------------------------------------
#include
http://robert.rsa3.com/disclaimer.html
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.