Date: Wed, 11 Nov 2015 12:56:56 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ivan Radovanovic <radovanovic@gmail.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Detecting new file name after receiving kevent's NOTE_RENAME Message-ID: <20151111105656.GX2257@kib.kiev.ua> In-Reply-To: <56426054.2070007@gmail.com> References: <5641A2A5.7070909@gmail.com> <20151110081421.GL2257@kib.kiev.ua> <56426054.2070007@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 10, 2015 at 10:23:32PM +0100, Ivan Radovanovic wrote: > On 11/10/15 09:14, Konstantin Belousov napisa: > >> >I am wondering is there some more clever way to get this new name > >> >(kernel is obviously aware of it, otherwise it couldn't notify > >> >descriptor about rename)? > > > > The most correct way is to use sysctl kern.proc.filedesc and look > > for the path of the given file descriptor. This is inefficient since > > kern.proc.filedesc returns information about all opened files for the > > process. > > Unfortunately it seems that this method (at least using > kinfo_getfile(3)) doesn't work - as soon as file is renamed kf_path > returned contains only zeros. Shame, it sounded like perfect solution > for the problem... 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. OTOH, I do not see a reason why filesystems could not be changed to start caching the renamed file name consistently.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151111105656.GX2257>