Re: getcwd in kernel space

Hello

I am not actually replacing the mkdir instead I am trying to get the changes
happened in directories
such as FAM(Fiile Alteration Monitor), so you are right about the  of the
parent directory in which case it will be
cwd.

I have tried vn_fullpath() however it is not as reliable as it needs to be
since once an rmdir command executes
on the folder vn_fullpath() returns ENOTDIR.

So will a namei lookup get me the path name of the parent.  Basically I will
need to perform this in
open, link unlink also.  My understanding is that namei lookup will return a
vnode am I wrong ???

Thanks


On 7/2/07, Dag-Erling Smørgrav <des_at_des.no> wrote:
>
> "Eren Erdemli" <erenerdemli_at_gmail.com> writes:
> > I am new to freebsd programing and I am trying to get the current
> > working directory of the curthread.
>
> curthread->td_proc->p_fd->fd_cdir is a pointer to the directory's vnode.
>
> > I have hook on to the sys calls and redirected the mkdir
> >
> > my_mkdir(struct thread *p, (void*) uap)
> > {
> >   mkdir_args = .....................
> >   ........
> >  getCWD()???????????
> > }
> >
> > the given path in the args is relative to the current path if not
> supplied
> > fully.  So who would I get the path of file.
>
> Are you sure you need the path?  There is no unique mapping from vnode
> to path in FreeBSD (or in any Unix derivative for that matter); multiple
> paths can lead to the same vnode.  The kernel operates on vnodes, not
> paths (except for namei, which translates paths to vnodes) and the path
> to a vnode may change after a reference to the vnode is acquired (there
> is no prohibition against deleting, renaming or moving an open file or
> directory).  Path components are cached in the namei cache, so it may
> sometimes be possible to reconstruct the path by which a particular
> vnode was most recently reached (vn_fullpath() does this), but the
> information may also have been displaced from the cache since the last
> lookup.
>
> If you just need a reference to the specified path or its parent
> directory, a namei lookup of the path will do all the work for you.  See
> for instance kern_mkdir() in vfs_syscalls.c (which I assume you are
> already looking at, since you are writing a replacement for the mkdir(2)
> syscall)
>
> DES
> --
> Dag-Erling Smørgrav - des_at_des.no
>