Re: Current working directory (path string) of another process without triggering a getattr() on the inode
Re: Current working directory (path string) of another process without triggering a getattr() on the inode
- Subject: Re: Current working directory (path string) of another process without triggering a getattr() on the inode
- From: Jakob Blomer <email@hidden>
- Date: Sun, 24 Mar 2013 00:43:15 +0100
Hi Paul,
as far as I can see, lsof uses PROC_PIDVNODEPATHINFO and hence is also
affected by the deadlock.
Cheers,
Jakob
On 3/24/13 12:20 AM, Paul Nelson wrote:
You might look at the source code for lsof. It lists the current
working directories for processes:
sudo lsof | grep cwd
Paul
On Mar 23, 2013, at 6:03 PM, Jakob Blomer <email@hidden> wrote:
Hi,
I would like to figure out the current working directories of other
running processes. I have been looking at libproc, and
proc_pidinfo with PROC_PIDVNODEPATHINFO almost does what I need.
The problem is that it not only returns the path string but also a
struct stat of the corresponding file system entry.
In my use case this approach results in a dead lock. I run the
code from inside a fuse file system in order to figure out the
current working directories that reside on that very fuse
filesystem. In order to avoid a race with newly spawned processes
or processes changing their working directory, the fuse module
blocks all VFS callbacks prior to enumerating the current working
directories.
I was also hoping that sysctl with KERN_VNODE might help but this
functionally has been removed from newer XNU kernels. Would there
be another, block-free way of enumerating the paths of the current
working directories? Ideally, I'm looking for something that works
like a readlink on /proc/PID/cwd under Linux.
Cheers, Jakob _______________________________________________ Do
not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden