Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Nov 2015 10:14:21 +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:  <20151110081421.GL2257@kib.kiev.ua>
In-Reply-To: <5641A2A5.7070909@gmail.com>
References:  <5641A2A5.7070909@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



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