Date: Wed, 11 Nov 2015 21:36:12 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Conrad Meyer <cem@FreeBSD.org> Cc: Ivan Radovanovic <radovanovic@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Detecting new file name after receiving kevent's NOTE_RENAME Message-ID: <20151111193612.GG2257@kib.kiev.ua> In-Reply-To: <CAG6CVpUV4=6ZZnfXJnnkmFFV2gQrktxBUa73dK6EWrsYb6=V7w@mail.gmail.com> References: <5641A2A5.7070909@gmail.com> <20151110081421.GL2257@kib.kiev.ua> <56426054.2070007@gmail.com> <20151111105656.GX2257@kib.kiev.ua> <CAG6CVpUV4=6ZZnfXJnnkmFFV2gQrktxBUa73dK6EWrsYb6=V7w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 11, 2015 at 09:24:51AM -0800, Conrad Meyer wrote: > On Wed, Nov 11, 2015 at 2:56 AM, Konstantin Belousov > <kostikbel@gmail.com> wrote: > > It is up to filesystem to cache or not cache the file name entry. > > If filesystem does not insert the name entry into namecache on rename, > > there is nothing which could help vn_fullpath(9) to return a path. > > Besides vn_vptocnp? I thought vn_fullpath(9) should always succeed > since 10.0 if the vnode still exists. VOP_VPTOCNP() still must get the data somewhere. It is usually easy to provide the name for a synthetic file system, where the data is fully controlled by the filesystem. Also, it is always possible to provide the name for a directory on any unix-like filesystem, due to dotdot. Both cases are what handled by fs-specific implementations of VOP_VPTOCNP() and by the default code. For the rest, you e.g. must be able to answer with the name for regular inode on UFS, given the inode number. If you can provide such code, I will be quite amazed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151111193612.GG2257>