Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Nov 2015 10:20:16 +0100
From:      Ivan Radovanovic <radovanovic@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: Detecting new file name after receiving kevent's NOTE_RENAME
Message-ID:  <5641B6D0.4070207@gmail.com>
In-Reply-To: <20151110081421.GL2257@kib.kiev.ua>
References:  <5641A2A5.7070909@gmail.com> <20151110081421.GL2257@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/10/15 09:14, Konstantin Belousov napisa:
> On Tue, Nov 10, 2015 at 08:54:13AM +0100, Ivan Radovanovic wrote:
>> What is the best practice for discovering new file name after receiving
>> kevent(2) NOTE_RENAME on its descriptor?
>>
>> At the moment I am storing fileno from dirent(5) structure together with
>> descriptor and name, and when I receive NOTE_RENAME I re-read directory
>> and use it (fileno) to discover new name, but this obviously requires
>> re-reading entire directory on each NOTE_RENAME.
> NOTE_RENAME means that the file backing the given file descriptor was
> renamed, not that some directory entry in the contained directory
> renamed. In particular, the new dirent for the file, for which you get
> the notification, may belong to some other directory.  As such, scanning
> the directory which contained the file before rename is useless.
>
>>
>> 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.
>
> If somebody cares about this, she should implement e.g. sysctl
> kern.proc.onefd which takes both pid and filedescriptor, to return
> single fileinfo structure for given file descriptor.
>

Thanks, kern.proc.filedesc is super-efficient compared to what I had in 
mind. I assume right way to use it would be through kinfo_getfile(3).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5641B6D0.4070207>